【原】微服務開發(fā)時,，接口不能對外暴露怎么辦？

woh5r1ofyffxnh 2023-07-11 發(fā)布于浙江

展開全文

大家好,，我是不才陳某~

在業(yè)務開發(fā)的時候,，經常會遇到某一個接口不能對外暴露，只能內網服務間調用的實際需求,。面對這樣的情況,，我們該如何實現(xiàn)呢？

今天,，我就來說一下碼猿慢病云管理系統(tǒng)中是如何實現(xiàn)的,？

碼猿慢病云管理系統(tǒng)企業(yè)級醫(yī)療項目正在持續(xù)更新，需要訂閱的小伙伴可以點鏈接聯(lián)系陳某

往期文章如下：

企業(yè)級醫(yī)療項目：碼猿慢病云管理系統(tǒng)來了,！
醫(yī)療系統(tǒng)的權限就該這樣設計,，穩(wěn)！
決定放棄 JWT 了,！

常用方案

在介紹碼猿慢病云管理系統(tǒng)中的實現(xiàn)方式,，先來介紹常用的兩種方案。

1. 網關+白名單

此方案需要在緩存中維護一套接口白名單,，請求到達網關處,，先判斷白名單緩存中是否存在，存在則放行,，反之則攔截,。

該方案的好處是，對業(yè)務代碼零侵入,，只需要維護好白名單列表即可,；

不足之處在于，白名單的維護是一個持續(xù)性投入的工作,，在很多公司,，業(yè)務開發(fā)無法直接觸及到 redis，只能提工單申請,，增加了開發(fā)成本,；

另外，每次請求進來,，都需要判斷白名單，增加了系統(tǒng)響應耗時,，考慮到正常情況下外部進來的請求大部分都是在白名單內的,，只有極少數(shù)惡意請求才會被白名單機制所攔截,，所以該方案的性價比很低。

2. 網關+AOP

相比于方案一對接口進行白名單判斷而言,，方案二是對請求來源進行判斷,，并將該判斷下沉到業(yè)務側。避免了網關側的邏輯判斷,，從而提升系統(tǒng)響應速度,。

我們可以在所有內部的調用請求頭中增加一個header標志這是一個內部請求，比如加個請求頭：from=Y

只要在業(yè)務接口處通過AOP的方式判斷一下請求頭中是否含有from=Y,，如果有,，則是內部請求，反之則是外部請求

實現(xiàn)

碼猿慢病云管理系統(tǒng)中采用的是第二種方案：網關+AOP ,，下面來介紹一下具體的代碼實現(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. 網關處理

在網關處需要對請求頭中的from進行清洗,，避免有意之人偽裝內部請求,，這里需要做的就是對每個請求直接移除from這個請求頭，直接使用全局過濾器即可完成,，代碼如下：

/**
 * {@link com.code.ape.codeape.gateway.filter.CodeapeRequestGlobalFilter#filter}
 * @author 公眾號：碼猿技術專欄
 * @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);
   // 設置請求時間
   httpHeaders.put(CommonConstants.REQUEST_START_TIME,
     Collections.singletonList(String.valueOf(System.currentTimeMillis())));
  }).build();
        .......
        .......
    }

3. feign接口處理

既然是內部調用,，按照之前的約定是要在請求頭中添加一個from=Y，因此在feign接口中需要新增這個請求頭,，方式很簡單,，比如設備feign接口，如下：

/**
 * @author 公眾號：碼猿技術專欄
 * @url: www.java-family.cn
 * @description 設備的feign接口
 */
@FeignClient(contextId = "remoteDeviceService", value = ServiceNameConstants.DEVICE_SERVICE)
public interface RemoteDeviceService {

 /**
  * 通過Sn查詢
  * @param sn 設備SN號
  * @return 設備詳細信息
  */
 @GetMapping(value = "/device/sn/{sn}",headers = "from=Y")
 R<DeviceInfoVO> getBySn(@PathVariable("sn" ) String sn);
}

@GetMapping中的headers屬性即可完成新增請求頭,，同樣的比如@RequestMapping,、@PostMapping等也是支持的。

這樣的話在feign接口發(fā)出請求時則會自動在請求頭中新增from=Y了,。

4. AOP處理

在第1步中定義了@Inner這個注解,，標注在controller方法上表示這個接口只允許內部調用，代碼如下：

@IngoreAuth這個注解是繞過鑒權的作用,，前面文章中也有分享,。

那么這個注解內部的實現(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ī)則,，直接拋出異常,，返回給客戶端無權限
   log.warn("訪問接口 {} 沒有權限", point.getSignature().getName());
   throw new AccessDeniedException("Access is denied");
  }
  return point.proceed();
 }
    .......
}