浅谈Spring Cloud Gateway源码

Posted 2022-12-14 默辨

本文不谈Spring Cloud Gateway相关的使用，仅梳理在微服务项目中，在使用Spring Cloud Gateway做为服务网关后，接收到请求后的大体执行流程。

文章目录

• 大致流程图
• 具体流程
• • 一、DispatcherHandler
  • 二、getHandler
  • • 1、getHandlerInternal
    • 2、lookupRoute
    • 3、RouteDefinitionRouteLocator.getRoutes()
    • 4、r.getPredicate().apply()
    • 5、AbstractRoutePredicateFactory（断言配置predicates）
  • 三、invokeHandler
  • • 1、FilteringWebHandler（过滤器配置filters）
    • 2、filter(exchange)

大致流程图

不难发现gateway的主体流程并不复杂，换句话说，gateway的源码不是特别难。唯一膈应的就是大量使用了jdk8的新特性，调试代码极不方便。

具体流程

流程图比较粗略，具体细节可以往下看

一、DispatcherHandler

该组件可以类比于Spring MVC中的DispatcherServlet。这里不在赘述Spring MVC接收到一个请求之后的跳转逻辑，如果对相关源码感兴趣的，可以查看我之前关于Spring MVC源码的分析。

浅谈SpringMVC源码的SpringServletContainerInitializer的完整加载流程

浅谈SpringMVC源码的DispatcherServlet组件执行流程

我们都知道，如果我们要使用Spring Cloud Gateway，需要移除Sping MVC相关的依赖，否则会出现依赖冲突。其本质是因为，Spring Cloud Gateway中是使用WebFlux替代了常规的Spring MVC做为请求转发，由于WebFlux是基于响应式编程，所以在面对大量请求的时候，性能是要明显优于Spring MVC的。

补充一点自己对技术相关的思考

以我一个毕业一年的Java开发从业者的角度看来，很多中间级提升效率的底层逻辑都差不多。这里以一篇我曾经记录的IO模型说明为起点：请不要再说NIO和多路复用IO是同一个东西了（内含BIO、NIO、多路复用、Netty、AIO案例测试代码） 。真的就有点万变不离其宗的味道。

我们熟知的高性能中间件，如Redis、Netty，包括我们这里说的WebFlux，它们底层不都是Reactor模型嘛。都是摒弃传统的一条龙执行到底的策略，使用基于事件响应的策略，继而达到提高响应性能的效果。但是有一说一，这种源码是真调试，对初学者并不友好。

前文我说过该组件可以类比于Spring MVC中的DispatcherServlet，所以不难发现该部分的代码逻辑风格大体相同

那么主要也就是两条路，一条是getHandler，一条是invokeHandler

二、getHandler

获取对应的处理器list，然后依次对每一个处理器进行响应的判断，要么返回一个empty，要么就是原样返回

1、getHandlerInternal

由于我们是在学习gateway相关的源码，所以可以直接跳转到gateway包下面的AbstractHandlerMapping抽象类的实现类中

该方法也可以主要分为3部分：

1、完成相关的参数判断，满足条件直接返回empty

2、调用lookupRoute方法，完成具体逻辑（重点）

3、移除exchange中的GATEWAY_PREDICATE_ROUTE_ATTR标签（这个标签是lookupRoute方法中放进去的）

2、lookupRoute

该方法内部内部分为三部分：

1、获取到所有的router信息，也就是我们配置在yaml中的配置

2、执行apply方法，完成路径相关的处理（我们想自己拼接相关的字符串）

3、其他的校验和日志打印

3、RouteDefinitionRouteLocator.getRoutes()

根据方法我们不难看出，gateway的解析逻辑为，将我们配置的每一组路由信息，会封装为一个RouteDefinition对象，然后调用convertToRoute方法，转换为一个Route对象，即就是我们的路由信息

获取解析后的配置信息的逻辑比较简单，可以自行了解。前文的获取getRouteDefinitions也就会调用该方法，即表示调用GatewayProperties类中的getRoutes方法。GatewayProperties想都不用想，直接就是一个@ConfigurationProperties注解，配置一个前缀，借助Spring Boot的能力，完成文件解析。

4、r.getPredicate().apply()

r即为route，获取路由信息上配置的断言接口，此处完成调用。用技术的角度来说，就是初始化route对象的时候，其中一个参数是函数式接口类型，这里就会拿到对应的属性，完成方法的调用。

具体有哪些类型的

5、AbstractRoutePredicateFactory（断言配置predicates）

这是gateway里面一个十分重要的扩展抽象类，即第4点中的断言工厂具体有多少种，如何使用，可以参考官方文档。我认为功能就可以类比为一个Filter差不多

我们这里可以简单看一个比较简单的实现：HeaderRoutePredicateFactory

1、首先获取我们的请求中的请求头，封装为一个list

2、如果list为空，或者和我们配置的断言工厂没有匹配的都会返回false。

三、invokeHandler

前文我们已经获取到了handlerMapping，并且进行了相关的断言处理。接下来我们要真正的开始处理我们的请求了，即调用handle方法。

这里和Spring MVC的代码写法类似

同样的，我们这里直接跳转到gateway对应的类中进行具体的逻辑处理

1、FilteringWebHandler（过滤器配置filters）

这个类里面的代码就很简单了，这里也出现了我们所熟知的GatewayFilter和GlobalFilter，即一个是作用在具体的路由路径上，一个是作用在所有的路由请求上。这两种不同类型接口放入一个list中，使用了一个适配器模式，这里就不再赘述，可参考：适配器模式（Gateway中GatewayFilter和GlobalFilter整合实现）

2、filter(exchange)

根据代码风格，我们也可以明白，该步骤完成的功能是把我们所有的Filter构建为一个责任链模式的调用形式，然后完成对应的责任链的中逻辑。

这里具体会有哪些Filter就根据你自己的配置了。

• GatewayFilter则直接看具体的内部类实现。
• GlobalFilter的调用逻辑则是位于GatewayFilterAdapter类中（适配器包了一层）。这里的请求就包含了把请求发送到具体服务器的功能

相关的Filter则都是以@Bean的形式加入到了Spring的容器中

补充两张Filter的功能图：