SpringCloud升级之路2020.0.x版-41. SpringCloudGateway 基本流程讲解(3)

本系列代码地址： https://github.com/JoJoTec/sp...

我们继续分析上一节提到的 WebHandler。加入 Spring Cloud Sleuth 以及 Prometheus 相关依赖之后， Spring Cloud Gateway 的处理流程如下所示：

Spring Cloud Gateway 入口 -> WebFlux 的 DefaultWebFilterChain

Spring Cloud Gateway 是基于 Spring WebFlux 开发的异步响应式网关，异步响应式代码比较难以理解和阅读，我这里给大家分享一种方法去理解，通过这个流程来理解 Spring Cloud Gateway 的工作流程以及底层原理。其实可以理解为，上图这个流程，就是拼出来一个完整的 Mono（或者 Flux）流，最后 subscribe 执行。

当收到一个请求的时候，会经过 org.springframework.web.server.handler.DefaultWebFilterChain，这是 WebFilter 的调用链，这个链路包括三个 WebFilter：

• org.springframework.boot.actuate.metrics.web.reactive.server.MetricsWebFilter：添加 Prometheus 相关依赖之后，会有这个 MetricsWebFilter，用于记录请求处理耗时，采集相关指标。
• org.springframework.cloud.sleuth.instrument.web.TraceWebFilter：添加 Spring Cloud Sleuth 相关依赖之后，会有这个 TraceWebFilter。
• org.springframework.cloud.gateway.handler.predicate.WeightCalculatorWebFilter：Spring Cloud Gateway 路由权重相关配置功能相关实现类，这个我们这里不关心。

在这个 DefaultWebFilterChain 会形成这样一个 Mono，我们依次将他们标记出来，首先是入口代码 org.springframework.web.server.handler.DefaultWebFilterChain#filter：

public Mono filter(ServerWebExchange exchange) {
    return Mono.defer(() ->
            // this.currentFilter != null 代表 WebFilter 链还没有结束
            // this.chain != null 代表 WebFilter 链不为空
            this.currentFilter != null && this.chain != null ?
                    //在 WebFilter 链没有结束的情况下，调用 WebFilter
                    invokeFilter(this.currentFilter, this.chain, exchange) :
                    //在 WebFilter 结束的情况下，调用 handler 
                    this.handler.handle(exchange));
}

对于我们这里的 WebFilter 链的第一个 MetricsWebFilter,假设启用了对应的采集统计的话，这时候生成的 Mono 就是：

return Mono.defer(() ->
    chain.filter(exchange).transformDeferred((call) -> {
        long start = System.nanoTime();
        return call
                //成功时，记录响应时间
                .doOnSuccess((done) -> MetricsWebFilter.this.onSuccess(exchange, start))
                //失败时，记录响应时间和异常
                .doOnError((cause) -> MetricsWebFilter.this.onError(exchange, start, cause));
    });
);

这里为了方便，我们对代码做了简化，由于我们要将整个链路的所有 Mono 和 Flux 拼接在一起行程完整链路，所以原本是 MetricsWebFilter中的 onSuccess(exchange, start)方法，被改成了 MetricsWebFilter.this.onSuccess(exchange, start) 这种伪代码。

接着，根据DefaultWebFilterChain 的源码分析，chain.filter(exchange) 会继续 WebFilter 链路，到达下一个 WebFilter，即 TraceWebFilter。经过 TraceWebFilter，Mono 就会变成：

return Mono.defer(() ->
    new MonoWebFilterTrace(source, chain.filter(exchange), TraceWebFilter.this.isTracePresent(), TraceWebFilter.this, TraceWebFilter.this.spanFromContextRetriever()).transformDeferred((call) -> {
        //MetricsWebFilter 相关的处理，在前面的代码中给出了，这里省略
    });
);

可以看出，在 TraceWebFilter 中，整个内部 Mono (chain.filter(exchange) 后续的结果)都被封装成了一个 MonoWebFilterTrace，这也是保持链路追踪信息的关键实现。

继续 WebFilter 链路，经过最后一个 WebFilter WeightCalculatorWebFilter; 这个 WebFilter 我们不关心，里面对路由权重做了一些计算操作，我们这里直接忽略即可。这样我们就走完了所有 WebFilter 链路，来到了最后的调用 DefaultWebFilterChain.this.handler，这个 handler 就是 org.springframework.web.reactive.DispatcherHandler。在 DispatcherHandler 中，我们会计算出路由并发送请求到符合条件的 GatewayFilter。经过 DispatcherHandler，Mono 会变成：

return Mono.defer(() ->
    new MonoWebFilterTrace(source, 
        Flux.fromIterable(DispatcherHandler.this.handlerMappings) //读取所有的 handlerMappings
            .concatMap(mapping -> mapping.getHandler(exchange)) //按顺序调用所有的 handlerMappings 的 getHandler 方法，如果有对应的 Handler 会返回，否则返回 Mono.empty();
            .next() //找到第一个返回不是 Mono.empty() 的 Handler
            .switchIfEmpty(DispatcherHandler.this.createNotFoundError()) //如果没有返回不为 Mono.empty() 的 handlerMapping，则直接返回 404
            .flatMap(handler -> DispatcherHandler.this.invokeHandler(exchange, handler)) //调用对应的 Handler
            .flatMap(result -> DispatcherHandler.this.handleResult(exchange, result)), //处理结果
    TraceWebFilter.this.isTracePresent(), TraceWebFilter.this, TraceWebFilter.this.spanFromContextRetriever()).transformDeferred((call) -> {
        //MetricsWebFilter 相关的处理，在前面的代码中给出了，这里省略
    });
);

handlerMappings 包括：

• org.springframework.boot.actuate.endpoint.web.reactive.WebFluxEndPointHandlerMapping：由于我们项目中添加了 Actuator 相关依赖，所以这里有这个 HandlerMapping。Actuator 相关路径映射，不是我们这里关心的。但是可以看出，Actuator 相关路径优先于 Spring Cloud Gateway 配置路由
• org.springframework.boot.actuate.endpoint.web.reactive.ControllerEndpointHandlerMapping：由于我们项目中添加了 Actuator 相关依赖，所以这里有这个 HandlerMapping。使用 @ControllerEndpoint 或者 @RestControllerEndpoint 注解标注的 Actuator 相关路径映射，不是我们这里关心的。
• org.springframework.web.reactive.function.server.support.RouterFunctionMapping：在 Spring-WebFlux 中，你可以定义很多不同的 RouterFunction 来控制路径路由，但这也不是我们这里关心的。但是可以看出，自定义的 RouterFunction 会优先于 Spring Cloud Gateway 配置路由
• org.springframework.web.reactive.result.method.annotation.RequestMappingHandlerMapping：针对 @RequestMapping 注解的路径的 HandlerMapping，不是我们这里关心的。但是可以看出，如果你在 Spring Cloud Gateway 中指定 RequestMapping 路径，会优先于 Spring Cloud Gateway 配置路由。
• org.springframework.cloud.gateway.handler.RoutePredicateHandlerMapping：这个是 Spring Cloud Gateway 的 HandlerMapping，会读取 Spring Cloud Gateway 配置并生成路由。这个是我们这里要详细分析的。

其实这些 handlerMappings，我们这里肯定走的是 RoutePredicateHandlerMapping 的相关逻辑，所以我们的 Mono 又可以简化成：

 return Mono.defer(() ->
    new MonoWebFilterTrace(source, 
        RoutePredicateHandlerMapping.this.getHandler(exchange)
            .switchIfEmpty(DispatcherHandler.this.createNotFoundError()) //如果没有返回不为 Mono.empty() 的 handlerMapping，则直接返回 404
            .flatMap(handler -> DispatcherHandler.this.invokeHandler(exchange, handler)) //调用对应的 Handler
            .flatMap(result -> DispatcherHandler.this.handleResult(exchange, result)), //处理结果
    TraceWebFilter.this.isTracePresent(), TraceWebFilter.this, TraceWebFilter.this.spanFromContextRetriever()).transformDeferred((call) -> {
        //MetricsWebFilter 相关的处理，在前面的代码中给出了，这里省略
    });
);

我们来看 RoutePredicateHandlerMapping，首先这些 handlerMapping 都是继承了抽象类 org.springframework.web.reactive.handler.AbstractHandlerMapping, 前面我们拼接的 Mono 里面的 getHandler 的实现其实就在这个抽象类中：

 public Mono