前言
其實(shí)一開始想自己總結(jié)一下Spring Cloud Gateway的路由流程，但是在看源碼的過程中，發(fā)現(xiàn)很多類都是提前在Netty啟動(dòng)時(shí)已經(jīng)配置或者是已經(jīng)聲明好的，如果直接開始總結(jié)Spring Cloud Gateway 的路由流程，不但有點(diǎn)突兀，等過段時(shí)間我自己回來看的時(shí)候，可能也記不得了，所以先總結(jié)了總結(jié)了一下SpringBoot內(nèi)置Netty的啟動(dòng)流程，這樣調(diào)用的類和其中的方法，我們就可以知道到底是在何時(shí)聲明，從底層一步一步理解Spring Cloud Gateway路由流程。
簡(jiǎn)單介紹Spring Cloud Gateway
根據(jù)官方的文檔 的我們大體可以了解到Spring Cloud Gateway 大體上由三部分組成
路由：網(wǎng)關(guān)的基本構(gòu)建塊。 它由ID，目標(biāo)URI，斷言集合和過濾器集合定義。 如果聚合斷言為true，則匹配路由。
斷言： 輸入類型是Spring Framework ServerWebExchange。 這使您可以匹配HTTP請(qǐng)求中的所有內(nèi)容，例如標(biāo)頭或參數(shù)。
過濾器：這些是使用特定工廠構(gòu)造的Spring Framework GatewayFilter實(shí)例。 在這里，您可以在發(fā)送下游請(qǐng)求之前或之后修改請(qǐng)求和響應(yīng)。
官方的工方式如圖
上圖大體上可以理解為:
客戶端向Spring Cloud Gateway發(fā)出請(qǐng)求。 如果Gateway Handler Mapping 通過斷言的集合確定請(qǐng)求與路由匹配，則將其發(fā)送到Gateway Web Handler。 Gateway Web Handler 通過確定的路由中所配置的過濾器集合鏈?zhǔn)秸{(diào)用過濾器（也就是所謂的責(zé)任鏈模式）。 Filter由虛線分隔的原因是， Filter可以在發(fā)送代理請(qǐng)求之前和之后運(yùn)行邏輯。處理的邏輯是 在處理請(qǐng)求時(shí) 排在前面的過濾器先執(zhí)行，而處理返回相應(yīng)的時(shí)候，排在后面的過濾器先執(zhí)行。
Spring Cloud Gateway 詳細(xì)工作流程
首先先來一張大體流程調(diào)用圖，自己用軟件畫的，賣相不是很好看，但是大體流程都有，大家可以跟著圖去debugger一下，我覺得就可以搞明白整體流程了。
首先客戶端發(fā)送HTTP請(qǐng)求進(jìn)來后，先經(jīng)過的是 ReactorHttpHandlerAdapter#apply(HttpServerRequest reactorRequest, HttpServerResponse reactorResponse) 方法，然后通過在Netty啟動(dòng)時(shí)配置好的HttpHandler 進(jìn)行HTTP請(qǐng)求處理，這里的HttpHandler 指的是 HttpWebHandlerAdapter 。這里涉及到的幾個(gè)類 都是在啟動(dòng)時(shí)就已經(jīng)注入了，可以看一下我之前的總結(jié) SpringBoot-內(nèi)置Netty啟動(dòng)(一) 。 我們可以看一下源碼。
@Override
public Mono<Void> apply(HttpServerRequest reactorRequest, HttpServerResponse reactorResponse) {
//獲取請(qǐng)求處理的內(nèi)存空間
NettyDataBufferFactory bufferFactory = new NettyDataBufferFactory(reactorResponse.alloc());
try {
ReactorServerHttpRequest request = new ReactorServerHttpRequest(reactorRequest, bufferFactory);
ServerHttpResponse response = new ReactorServerHttpResponse(reactorResponse, bufferFactory);
if (request.getMethod() == HttpMethod.HEAD) {
response = new HttpHeadResponseDecorator(response);
}
//HttpWebHandlerAdapter 去處理請(qǐng)求
return this.httpHandler.handle(request, response)
.doOnError(ex -> logger.trace(request.getLogPrefix() + "Failed to complete: " + ex.getMessage()))
.doOnSuccess(aVoid -> logger.trace(request.getLogPrefix() + "Handling completed"));
}
catch (URISyntaxException ex) {
if (logger.isDebugEnabled()) {
logger.debug("Failed to get request URI: " + ex.getMessage());
}
reactorResponse.status(HttpResponseStatus.BAD_REQUEST);
return Mono.empty();
}
}
這里需要注意的是 HttpWebHandlerAdapter其實(shí)是個(gè)代理類，他層層代理 最終指向的是 DispatcherHandler 如圖所示
感興趣的同學(xué)可以按照上面給出的請(qǐng)求流程圖去自己debugger每一個(gè)代理類，需要注意的是 這里的FilteringWebHandler是org.springframework.web.server.handler包中的 而不是 Spring Cloud Gateway中的handler。
接下來我們來主要看一下 DispatcherHandler#handle(ServerWebExchange exchange) 這個(gè)方法，也是整個(gè)WebFlux請(qǐng)求處理的核心方法。
@Override
public Mono<Void> handle(ServerWebExchange exchange) {
if (this.handlerMappings == null) {
return createNotFoundError();
}
return
//創(chuàng)建Flux流操作
Flux.fromIterable(this.handlerMappings)
//流式執(zhí)行 getHandler方法
.concatMap(mapping -> mapping.getHandler(exchange))
//將流操作中返回的第一個(gè)項(xiàng)發(fā)送到新的Mono中
.next()
.switchIfEmpty(createNotFoundError())
//從獲取到的handler中執(zhí)行 invokeHandler(exchange, handler)
.flatMap(handler -> invokeHandler(exchange, handler))
//從獲取到的handler獲取到result執(zhí)行 handleResult(exchange, result)
.flatMap(result -> handleResult(exchange, result));
}
我們來看一下 handlerMappings 集合中有哪幾個(gè) HandlerMapping的實(shí)現(xiàn)類
- RouterFunctionMapping:匹配WebFlux的router functions。
- RequestMappingHandlerMapping:匹配@RequestMapping標(biāo)注的請(qǐng)求。
- RoutePredicateHandlerMapping:匹配Spring Cloud Gateway 中路由里的 斷言集合。
- SimpleUrlHandlerMapping: 匹配靜態(tài)資源等請(qǐng)求。
我們這里主要是看 RoutePredicateHandlerMapping 首先調(diào)用了父類 AbstractHandlerMapping#getHandler(ServerWebExchange exchange)，在父類方法中調(diào)用了子類的getHandlerInternal(ServerWebExchange exchange) 方法后做了跨域等邏輯之后返回得到的Handler對(duì)象。
//AbstractHandlerMapping
@Override
public Mono<Object> getHandler(ServerWebExchange exchange) {
return getHandlerInternal(exchange).map(handler -> {
if (logger.isDebugEnabled()) {
logger.debug(exchange.getLogPrefix() + "Mapped to " + handler);
}
ServerHttpRequest request = exchange.getRequest();
if (hasCorsConfigurationSource(handler) || CorsUtils.isPreFlightRequest(request)) {
CorsConfiguration config = (this.corsConfigurationSource != null ? this.corsConfigurationSource.getCorsConfiguration(exchange) : null);
CorsConfiguration handlerConfig = getCorsConfiguration(handler, exchange);
config = (config != null ? config.combine(handlerConfig) : handlerConfig);
if (config != null) {
config.validateAllowCredentials();
}
if (!this.corsProcessor.process(config, exchange) || CorsUtils.isPreFlightRequest(request)) {
return REQUEST_HANDLED_HANDLER;
}
}
return handler;
});
}
//RequestMappingHandlerMapping
@Override
protected Mono<?> getHandlerInternal(ServerWebExchange exchange) {
if (this.managementPortType == DIFFERENT && this.managementPort != null
&& exchange.getRequest().getURI().getPort() == this.managementPort) {
return Mono.empty();
}
exchange.getAttributes().put(GATEWAY_HANDLER_MAPPER_ATTR, getSimpleName());
//查找對(duì)應(yīng)的route配置
return lookupRoute(exchange)
.flatMap((Function<Route, Mono<?>>) r -> {
exchange.getAttributes().remove(GATEWAY_PREDICATE_ROUTE_ATTR);
if (logger.isDebugEnabled()) {
logger.debug("Mapping [" + getExchangeDesc(exchange) + "] to " + r);
}
//如果找到則將Route 放到exchange的屬性中
exchange.getAttributes().put(GATEWAY_ROUTE_ATTR, r);
//返回 FilteringWebHandler
return Mono.just(webHandler);
}).switchIfEmpty(Mono.empty().then(Mono.fromRunnable(() -> {
//如果沒有則不返回，即最后不會(huì)走 該類中的webHandler 去處理請(qǐng)求
exchange.getAttributes().remove(GATEWAY_PREDICATE_ROUTE_ATTR);
if (logger.isTraceEnabled()) {
logger.trace("No RouteDefinition found for [" + getExchangeDesc(exchange) + "]");
}
})));
}
//查找路由的方法
protected Mono<Route> lookupRoute(ServerWebExchange exchange) {
return this.routeLocator.getRoutes()
//遍歷定義好的路由
.concatMap(route -> Mono.just(route).filterWhen(r -> {
//遍歷路由中定義好的斷言集合
exchange.getAttributes().put(GATEWAY_PREDICATE_ROUTE_ATTR, r.getId());
//斷言校驗(yàn),返回正確的路由
return r.getPredicate().apply(exchange);
})
.doOnError(e -> logger.error("Error applying predicate for route: " + route.getId(), e))
.onErrorResume(e -> Mono.empty()))
.next()
.map(route -> {
//校驗(yàn)路由并返回
if (logger.isDebugEnabled()) {
logger.debug("Route matched: " + route.getId());
}
validateRoute(route, exchange);
return route;
});
}
RoutePredicateHandlerMapping的處理邏輯大致上如上源碼，重要的地方已經(jīng)給出注釋。獲取到 FilteringWebHandler后,在執(zhí)行 DispatcherHandler#invokeHandler
我們接著看一下 FilteringWebHandler#handle
@Override
public Mono<Void> handle(ServerWebExchange exchange) {
//獲取到已經(jīng)匹配好的路由
Route route = exchange.getRequiredAttribute(GATEWAY_ROUTE_ATTR);
//獲取路由中配置的過濾器
List<GatewayFilter> gatewayFilters = route.getFilters();
//獲取全局的過濾器
List<GatewayFilter> combined = new ArrayList<>(this.globalFilters);
//合并并排序
combined.addAll(gatewayFilters);
AnnotationAwareOrderComparator.sort(combined);
if (logger.isDebugEnabled()) {
logger.debug("Sorted gatewayFilterFactories: " + combined);
}
//執(zhí)行過濾器鏈
return new DefaultGatewayFilterChain(combined).filter(exchange);
}
//責(zé)任鏈模式調(diào)用 過濾器
@Override
public Mono<Void> filter(ServerWebExchange exchange) {
return Mono.defer(() -> {
if (this.index < filters.size()) {
GatewayFilter filter = filters.get(this.index);
DefaultGatewayFilterChain chain = new DefaultGatewayFilterChain(this, this.index + 1);
return filter.filter(exchange, chain);
}
else {
return Mono.empty(); // complete
}
});
}
Spring Cloud Gateway 詳細(xì)的執(zhí)行流程總結(jié)的差不多了，在上面的流程圖中還有很多細(xì)節(jié)我沒有說明，那是因?yàn)椴皇呛诵牡牧鞒檀a,但是不等于不重要，如果有心的同學(xué)可以一起debug 再深入的了解你會(huì)發(fā)現(xiàn)在 路由斷言的配置當(dāng)中也用到了 非org.springframework.cloud.gateway包中的Filter。這種設(shè)計(jì)雖然不算巧妙，但是確實(shí)可以節(jié)省一些不必要的消耗。
