微服務(wù)開發(fā)時(shí)，接口不能對外暴露怎么辦？
在業(yè)務(wù)開發(fā)的時(shí)候，經(jīng)常會遇到某一個(gè)接口不能對外暴露，只能內(nèi)網(wǎng)服務(wù)間調(diào)用的實(shí)際需求。面對這樣的情況，我們該如何實(shí)現(xiàn)呢？
今天，我就來說一下碼猿慢病云管理系統(tǒng)中是如何實(shí)現(xiàn)的？
常用方案
在介紹碼猿慢病云管理系統(tǒng)中的實(shí)現(xiàn)方式，先來介紹常用的兩種方案。
1. 網(wǎng)關(guān)+白名單
此方案需要在緩存中維護(hù)一套接口白名單，請求到達(dá)網(wǎng)關(guān)處，先判斷白名單緩存中是否存在，存在則放行，反之則攔截。
網(wǎng)關(guān)+白名單
該方案的好處是，對業(yè)務(wù)代碼零侵入，只需要維護(hù)好白名單列表即可；
不足之處在于，白名單的維護(hù)是一個(gè)持續(xù)性投入的工作，在很多公司，業(yè)務(wù)開發(fā)無法直接觸及到 redis，只能提工單申請，增加了開發(fā)成本；
另外，每次請求進(jìn)來，都需要判斷白名單，增加了系統(tǒng)響應(yīng)耗時(shí)，考慮到正常情況下外部進(jìn)來的請求大部分都是在白名單內(nèi)的，只有極少數(shù)惡意請求才會被白名單機(jī)制所攔截，所以該方案的性價(jià)比很低。
2. 網(wǎng)關(guān)+AOP
相比于方案一對接口進(jìn)行白名單判斷而言，方案二是對請求來源進(jìn)行判斷，并將該判斷下沉到業(yè)務(wù)側(cè)。避免了網(wǎng)關(guān)側(cè)的邏輯判斷，從而提升系統(tǒng)響應(yīng)速度。
我們可以在所有內(nèi)部的調(diào)用請求頭中增加一個(gè)header標(biāo)志這是一個(gè)內(nèi)部請求，比如加個(gè)請求頭：from=Y
只要在業(yè)務(wù)接口處通過AOP的方式判斷一下請求頭中是否含有from=Y，如果有，則是內(nèi)部請求，反之則是外部請求
網(wǎng)關(guān)+AOP
實(shí)現(xiàn)
碼猿慢病云管理系統(tǒng)中采用的是第二種方案：網(wǎng)關(guān)+AOP ，下面來介紹一下具體的代碼實(shí)現(xiàn)。
1. 定義注解
這里AOP在碼猿慢病云管理系統(tǒng)中采用的是注解的方式，注解如下：
@Target({ ElementType.METHOD, ElementType.TYPE })
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface Inner {
/**
* 是否AOP統(tǒng)一處理
*/
boolean value() default true;
}2. 網(wǎng)關(guān)處理
在網(wǎng)關(guān)處需要對請求頭中的from進(jìn)行清洗，避免有意之人偽裝內(nèi)部請求，這里需要做的就是對每個(gè)請求直接移除from這個(gè)請求頭，直接使用全局過濾器即可完成，代碼如下：
/**
* {@link com.code.ape.codeape.gateway.filter.CodeapeRequestGlobalFilter#filter}
* @author 公眾號：碼猿技術(shù)專欄
* @url: www.java-family.cn
*/
public class CodeapeRequestGlobalFilter implements GlobalFilter, Ordered {
@Override
public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
// 1. 清洗請求頭中from 參數(shù)
ServerHttpRequest request = exchange.getRequest().mutate().headers(httpHeaders -> {
httpHeaders.remove(SecurityConstants.FROM);
// 設(shè)置請求時(shí)間
httpHeaders.put(CommonConstants.REQUEST_START_TIME,
Collections.singletonList(String.valueOf(System.currentTimeMillis())));
}).build();
.......
.......
}3. feign接口處理
既然是內(nèi)部調(diào)用，按照之前的約定是要在請求頭中添加一個(gè)from=Y，因此在feign接口中需要新增這個(gè)請求頭，方式很簡單，比如設(shè)備feign接口，如下：
/**
* @author 公眾號：碼猿技術(shù)專欄
* @url: www.java-family.cn
* @description 設(shè)備的feign接口
*/
@FeignClient(contextId = "remoteDeviceService", value = ServiceNameConstants.DEVICE_SERVICE)
public interface RemoteDeviceService {
/**
* 通過Sn查詢
* @param sn 設(shè)備SN號
* @return 設(shè)備詳細(xì)信息
*/
@GetMapping(value = "/device/sn/{sn}",headers = "from=Y")
R<DeviceInfoVO> getBySn(@PathVariable("sn" ) String sn);
}@GetMapping中的headers屬性即可完成新增請求頭，同樣的比如@RequestMapping、@PostMapping等也是支持的。
這樣的話在feign接口發(fā)出請求時(shí)則會自動在請求頭中新增from=Y了。
4. AOP處理
在第1步中定義了@Inner這個(gè)注解，標(biāo)注在controller方法上表示這個(gè)接口只允許內(nèi)部調(diào)用，代碼如下：
圖片
@IngoreAuth這個(gè)注解是繞過鑒權(quán)的作用，前面文章中也有分享。
那么這個(gè)注解內(nèi)部的實(shí)現(xiàn)原理是什么呢？代碼如下：
//com.code.ape.codeape.common.security.component.CodeapeSecurityInnerAspect
@Slf4j
@Aspect
@RequiredArgsConstructor
public class CodeapeSecurityInnerAspect implements Ordered {
private final HttpServletRequest request;
@SneakyThrows
@Around("@within(inner) || @annotation(inner)")
public Object around(ProceedingJoinPoint point, Inner inner) {
//取出請求頭中的from屬性
String header = request.getHeader("from");
//判斷from===Y
if (inner.value() && !"Y".equals(header)) {
//不符合規(guī)則，直接拋出異常，返回給客戶端無權(quán)限
log.warn("訪問接口 {} 沒有權(quán)限", point.getSignature().getName());
throw new AccessDeniedException("Access is denied");
}
return point.proceed();
}
.......
}如果請求頭中的from屬性不匹配，則拋出AccessDeniedException異常，會被全局異常捕獲，返回403的狀態(tài)碼，代碼如下：
圖片
總結(jié)
本節(jié)內(nèi)容介紹了微服務(wù)中接口不對外暴露的兩種方案：
- 網(wǎng)關(guān)+白名單
- 網(wǎng)關(guān)+AOP
當(dāng)然還有其他的實(shí)現(xiàn)方式，生產(chǎn)中根據(jù)項(xiàng)目需要選擇合適的方案為最佳。
