今天準備講一點簡單的東西豆巨。我們知道蜻拨，不管是我們去做框架還是應用程序本身，都或多或少會有些全局處理的邏輯眠冈，比如API用戶鑒權飞苇，再比如統(tǒng)一異常處理。那我們就來看下soul網(wǎng)關中對于請求的全局處理部分又包括那些。
在soul網(wǎng)關代碼中大致可以找出來如下幾個全局處理的邏輯：
-
GlobalPlugin-全局插件 -
GlobalErrorHandler-全局異常處理 -
SoulWebHandler-soul網(wǎng)關web請求處理 -
CrossFilter-跨域支持過濾器 -
FileSizeFilter-文件大小限制過濾器 -
ExcludeFilter-URL排除過濾器 -
WebSocketParamFilter-websocket請求參數(shù)過濾器
GlobalPlugin-全局插件
- 因為是插件布卡，所以我們只需要重點看
excute方法
public Mono<Void> execute(final ServerWebExchange exchange, final SoulPluginChain chain) {
final ServerHttpRequest request = exchange.getRequest();
final HttpHeaders headers = request.getHeaders();
final String upgrade = headers.getFirst("Upgrade");
// 構造soul上下文
SoulContext soulContext;
// 非websocket的處理
if (StringUtils.isBlank(upgrade) || !"websocket".equals(upgrade)) {
soulContext = builder.build(exchange);
} else {
// websocket的處理
final MultiValueMap<String, String> queryParams = request.getQueryParams();
soulContext = transformMap(queryParams);
}
exchange.getAttributes().put(Constants.CONTEXT, soulContext);
return chain.execute(exchange);
}
- 從代碼看出來雨让，該全局插件就為了做一件事情，構造網(wǎng)關上下文
soulContext忿等，構造完成后栖忠，并將其存放到請求exchange對象中，從而實現(xiàn)在整個請求流程中將網(wǎng)關上下文的傳遞贸街。 - 再來細看一下娃闲，構造網(wǎng)關上下文的實現(xiàn)部分。
public SoulContext build(final ServerWebExchange exchange) {
final ServerHttpRequest request = exchange.getRequest();
String path = request.getURI().getPath();
// 根據(jù)當前的請求路徑從緩存中獲取到metaData
MetaData metaData = MetaDataCache.getInstance().obtain(path);
// 原始metaData放到exchange中
if (Objects.nonNull(metaData) && metaData.getEnabled()) {
exchange.getAttributes().put(Constants.META_DATA, metaData);
}
// 將metaData轉換為SoulContext
return transform(request, metaData);
}
- 獲取元數(shù)據(jù)的邏輯需要提一下匾浪。首先，元數(shù)據(jù)是緩存于
MetaDataCache中的META_DATA_MAP中卷哩；其次是根據(jù)當前請求的路徑去獲取其metaData蛋辈。獲取metaData的邏輯如下：先使用請求路徑作為key，從META_DATA_MAP中get将谊，如果存在冷溶，則直接返回metaData；否則就需要先去遍歷所有的META_DATA_MAP尊浓，用其key去和當前請求路徑去做匹配逞频，這里的匹配算法為Spring的AntPathMatcher。這個大家就比較熟悉了栋齿，在與我們在各種Controller中用的RequestMapping的請求匹配規(guī)則是一致的苗胀。 - 其核心的
build邏輯就是根據(jù)request中的一些參數(shù)，以及此次請求的metaData轉換成SoulContext類的實例瓦堵。這個邏輯代碼雖然長基协，但不復雜，這里就不展開了菇用。
小結
-
GlobalPlugin的依賴類圖
GlobalPlugin - 從圖中可以看出澜驮，
SoulContext的數(shù)據(jù)是通過SoulContextBuilder接口對應的實現(xiàn)類DefaultSoulContextBuilder構造，當創(chuàng)建類的實例存在比較復雜的構造邏輯時惋鸥，可以參考此類實現(xiàn) -
GlobalPlugin做為全局的邏輯杂穷，在整個插件鏈中是第一個執(zhí)行的，因為后續(xù)的其他插件卦绣，或多或少都會有依賴SoulContext對象耐量，通過插件執(zhí)行順序order=0實現(xiàn)插件鏈的第一個調用
GlobalErrorHandler-全局異常處理
- 顧名思義，
GlobalErrorHandler就只是一個全局的異常處理器迎卤，邏輯是不會復雜的^_^ - 首先該類繼承了
DefaultErrorWebExceptionHandler拴鸵，這里spring框架中提供的默認異常處理。 - 整個源碼看下來，主要是為了
override了DefaultErrorWebExceptionHandler中實現(xiàn)的一些異常處理邏輯：getErrorAttributes劲藐、getRoutingFunction八堡、getHttpStatus。 - 在
GlobalErrorHandler中聘芜，所有未被處理并且進入到exceptionHandler中的異常兄渺，都會被轉化為INTERNAL_SERVER_ERROR，狀態(tài)返回碼為500汰现，且返回帶錯誤簡略信息的response挂谍，json對象
SoulWebHandler-soul網(wǎng)關web請求處理
-
SoulWebHandler繼承至org.springframework.web.server.WebHandler - 是網(wǎng)關插件鏈初始化并執(zhí)行插件鏈
DefaultSoulPluginChain處理的入口
CrossFilter-跨域支持過濾器
-
soul網(wǎng)關中的跨域支持，并沒有自己直接使用spring框架自帶的org.springframework.web.cors.reactive.CorsWebFilter - 這里的實現(xiàn)也挺簡單
public Mono<Void> filter(final ServerWebExchange exchange, final WebFilterChain chain) {
ServerHttpRequest request = exchange.getRequest();
// 判斷是否為跨域請求瞎饲，判斷的邏輯：是否有origin參數(shù)口叙，若有，再判斷當前請求的全路徑是否與origin一致
// 如果判斷為跨域請求嗅战，則在reponse的header頭中添加一些跨域支持的參數(shù)
if (CorsUtils.isCorsRequest(request)) {
ServerHttpResponse response = exchange.getResponse();
HttpHeaders headers = response.getHeaders();
headers.add("Access-Control-Allow-Origin", ALLOWED_ORIGIN);
headers.add("Access-Control-Allow-Methods", ALLOWED_METHODS);
headers.add("Access-Control-Max-Age", MAX_AGE);
headers.add("Access-Control-Allow-Headers", ALLOWED_HEADERS);
headers.add("Access-Control-Expose-Headers", ALLOWED_EXPOSE);
headers.add("Access-Control-Allow-Credentials", "true");
// 判斷是否為optins請求妄田，若是直接返回請求成功；否則會繼續(xù)執(zhí)行過濾器鏈
if (request.getMethod() == HttpMethod.OPTIONS) {
response.setStatusCode(HttpStatus.OK);
return Mono.empty();
}
}
return chain.filter(exchange);
}
- 需要顯示配置
soul.cross.enabled開啟
FileSizeFilter-文件大小限制過濾器
- 看下該過濾器的幾個特性
- 只針對帶文件的表單數(shù)據(jù)
multipart/form-data的請求生效 - 需要顯示開啟驮捍，配置
soul.file.enabled=true使用 - 默認支持的文件大小限制為
10M疟呐，超過該值，則會直接報錯东且；該參數(shù)可配置启具，配置項soul.fileMaxSize
- 只針對帶文件的表單數(shù)據(jù)
- 關鍵源碼
public Mono<Void> filter(@NonNull final ServerWebExchange exchange, @NonNull final WebFilterChain chain) {
MediaType mediaType = exchange.getRequest().getHeaders().getContentType();
// 只針對帶文件的表單數(shù)據(jù)的請求，會有文件大小限制
if (MediaType.MULTIPART_FORM_DATA.isCompatibleWith(mediaType)) {
ServerRequest serverRequest = ServerRequest.create(exchange,
messageReaders);
return //先將請求中的body轉換為DataBuffer
serverRequest.bodyToMono(DataBuffer.class)
.flatMap(size -> {
// dataBuffer的容量是否大于最大的文件大小珊泳，若大則直接返回異常
if (size.capacity() > BYTES_PER_MB * fileMaxSize) {
// 鲁冯。。旨椒。晓褪。
}
// 因上面已經(jīng)讀取了body數(shù)據(jù)，在io流中body體是不能讀取多次的
// 需要重新生成一個新的ServerHttpRequest對象包裝原有的body數(shù)據(jù)综慎，并傳遞到程序后面的請求中
BodyInserter<Mono<DataBuffer>, ReactiveHttpOutputMessage> bodyInsert = BodyInserters.fromPublisher(Mono.just(size), DataBuffer.class);
HttpHeaders headers = new HttpHeaders();
headers.putAll(exchange.getRequest().getHeaders());
headers.remove(HttpHeaders.CONTENT_LENGTH);
CachedBodyOutputMessage outputMessage = new CachedBodyOutputMessage(
exchange, headers);
return bodyInsert.insert(outputMessage, new BodyInserterContext())
.then(Mono.defer(() -> {
// ServerHttpRequest的裝飾涣仿，用傳入的CachedBodyOutputMessage替換原有Request的body
ServerHttpRequest decorator = decorate(exchange, outputMessage);
// 在原來exchange的基礎上，重新構造了新的exchange對象
return chain.filter(exchange.mutate().request(decorator).build());
}));
});
}
return chain.filter(exchange);
}
ExcludeFilter-url排除過濾器
- 該過濾器功能是將當前請求
url與網(wǎng)關中配置的url排除列表進行匹配示惊，如果匹配成功好港，則請求結束，直接返回給請求客戶端 - 通過
soul.exclude進行配置 - 可以用在將某些后臺請求直接從網(wǎng)關下線掉
WebSocketParamFilter-websocket請求參數(shù)過濾器
- 這個是最簡單的
>_<米罚，就做了一件事：校驗webscoket請求必傳的一些參數(shù)
