建站
咨詢
售后
建站咨詢
新聞中心
在業(yè)務(wù)開發(fā)的時候，經(jīng)常會遇到某一個接口不能對外暴露，只能內(nèi)網(wǎng)服務(wù)間調(diào)用的實際需求。面對這樣的情況，我們該如何實現(xiàn)呢？
為欽北等地區(qū)用戶提供了全套網(wǎng)頁設(shè)計制作服務(wù)，及欽北網(wǎng)站建設(shè)行業(yè)解決方案。主營業(yè)務(wù)為成都網(wǎng)站設(shè)計、網(wǎng)站制作、外貿(mào)營銷網(wǎng)站建設(shè)、欽北網(wǎng)站設(shè)計，以傳統(tǒng)方式定制建設(shè)網(wǎng)站，并提供域名空間備案等一條龍服務(wù)，秉承以專業(yè)、用心的態(tài)度為用戶提供真誠的服務(wù)。我們深信只要達到每一位用戶的要求，就會得到認可，從而選擇與我們長期合作。這樣，我們也可以走得更遠！
今天，我就來說一下碼猿慢病云管理系統(tǒng)中是如何實現(xiàn)的？
常用方案
在介紹碼猿慢病云管理系統(tǒng)中的實現(xiàn)方式，先來介紹常用的兩種方案。
1. 網(wǎng)關(guān)+白名單
此方案需要在緩存中維護一套接口白名單，請求到達網(wǎng)關(guān)處，先判斷白名單緩存中是否存在，存在則放行，反之則攔截。
網(wǎng)關(guān)+白名單
該方案的好處是，對業(yè)務(wù)代碼零侵入，只需要維護好白名單列表即可；
不足之處在于，白名單的維護是一個持續(xù)性投入的工作，在很多公司，業(yè)務(wù)開發(fā)無法直接觸及到 redis，只能提工單申請，增加了開發(fā)成本；
另外，每次請求進來，都需要判斷白名單，增加了系統(tǒng)響應(yīng)耗時，考慮到正常情況下外部進來的請求大部分都是在白名單內(nèi)的，只有極少數(shù)惡意請求才會被白名單機制所攔截，所以該方案的性價比很低。
2. 網(wǎng)關(guān)+AOP
相比于方案一對接口進行白名單判斷而言，方案二是對請求來源進行判斷，并將該判斷下沉到業(yè)務(wù)側(cè)。避免了網(wǎng)關(guān)側(cè)的邏輯判斷，從而提升系統(tǒng)響應(yīng)速度。
我們可以在所有內(nèi)部的調(diào)用請求頭中增加一個header標(biāo)志這是一個內(nèi)部請求，比如加個請求頭：from=Y
只要在業(yè)務(wù)接口處通過AOP的方式判斷一下請求頭中是否含有from=Y，如果有，則是內(nèi)部請求，反之則是外部請求
網(wǎng)關(guān)+AOP
實現(xiàn)
碼猿慢病云管理系統(tǒng)中采用的是第二種方案：網(wǎng)關(guān)+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. 網(wǎng)關(guān)處理
在網(wǎng)關(guān)處需要對請求頭中的from進行清洗，避免有意之人偽裝內(nèi)部請求，這里需要做的就是對每個請求直接移除from這個請求頭，直接使用全局過濾器即可完成，代碼如下：
/**
* {@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 filter(ServerWebExchange exchange, GatewayFilterChain chain) {
// 1. 清洗請求頭中from 參數(shù)
ServerHttpRequest request = exchange.getRequest().mutate().headers(httpHeaders -> {
httpHeaders.remove(SecurityConstants.FROM);
// 設(shè)置請求時間
httpHeaders.put(CommonConstants.REQUEST_START_TIME,
Collections.singletonList(String.valueOf(System.currentTimeMillis())));
}).build();
.......
.......
} 3. feign接口處理
既然是內(nèi)部調(diào)用，按照之前的約定是要在請求頭中添加一個from=Y，因此在feign接口中需要新增這個請求頭，方式很簡單，比如設(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è)備詳細信息
*/
@GetMapping(value = "/device/sn/{sn}",headers = "from=Y")
R getBySn(@PathVariable("sn" ) String sn);
} @GetMapping中的headers屬性即可完成新增請求頭，同樣的比如@RequestMapping、@PostMapping等也是支持的。
這樣的話在feign接口發(fā)出請求時則會自動在請求頭中新增from=Y了。
4. AOP處理
在第1步中定義了@Inner這個注解，標(biāo)注在controller方法上表示這個接口只允許內(nèi)部調(diào)用，代碼如下：
圖片
@IngoreAuth這個注解是繞過鑒權(quán)的作用，前面文章中也有分享。
那么這個注解內(nèi)部的實現(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)然還有其他的實現(xiàn)方式，生產(chǎn)中根據(jù)項目需要選擇合適的方案為最佳。
本文名稱：微服務(wù)開發(fā)時，接口不能對外暴露怎么辦？
標(biāo)題鏈接：http://www.5511xx.com/article/dhodcpp.html
