SpringCloud系列——11Spring Cloud 源码分析之Gateway网关

学习目标

1. Gateway核心原理分析

第1章 Bean的准备

前面也讲了这么多组件了，这会儿我们集成spring-cloud-starter-gateway组件发现，又是一个starter组件，二话不说，先去找spring.factories文件，分析一下有哪些重要的bean被自动装配进IoC容器里面了。

1.  先来看GatewayClassPathWarningAutoConfiguration这个配置类

   @Configuration(proxyBeanMethods = false)
   //当前配置类在GatewayAutoConfiguration这个核心配置类之前加载
   @AutoConfigureBefore(GatewayAutoConfiguration.class)
   public class GatewayClassPathWarningAutoConfiguration {
   
   	...
           
   	@Configuration(proxyBeanMethods = false)
   	@ConditionalOnClass(name = "org.springframework.web.servlet.DispatcherServlet")
   	protected static class SpringMvcFoundOnClasspathConfiguration {
   
   		public SpringMvcFoundOnClasspathConfiguration() {
   			log.warn(BORDER
   					+ "Spring MVC found on classpath, which is incompatible with Spring Cloud Gateway at this time. "
   					+ "Please remove spring-boot-starter-web dependency." + BORDER);
   		}
   
   	}
   
   	@Configuration(proxyBeanMethods = false)
   	@ConditionalOnMissingClass("org.springframework.web.reactive.DispatcherHandler")
   	protected static class WebfluxMissingFromClasspathConfiguration {
   
   		public WebfluxMissingFromClasspathConfiguration() {
   			log.warn(BORDER + "Spring Webflux is missing from the classpath, "
   					+ "which is required for Spring Cloud Gateway at this time. "
   					+ "Please add spring-boot-starter-webflux dependency." + BORDER);
   		}
   	}
   }

   从这个配置类能看出来，它实际上就通过ConditionOnClass和ConditionOnMissingClass两个做了两个日志打印的功能；如果ClassPath下有org.springframework.web.servlet.DispatcherServlet类的话，则实例第一个Bean对象，然后打印日志：不能依赖spring-boot-starter-web这个包。然后再检查ClassPath下是否有正确的配置webflux，如果没有，则打印日志：加spring-boot-starter-webflux依赖。

2. 核心配置类GatewayAutoConfiguration

   因为代码太长，这里就不展示了，这里就列举几个比较重要的

   • PropertiesRouteDefinitionLocator：用于从配置文件（yml/properties）中读取路由配置信息！

   • RouteDefinitionLocator：把 RouteDefinition 转化为 Route

   • RoutePredicateHandlerMapping：类似于 mvc 的HandlerMapping，不过这里是 Gateway实现的。用于匹配对应的请求route

   • GatewayProperties：yml配置信息封装在 GatewayProperties 对象中

   • AfterRoutePredicateFactory：各种路由断言工厂，正是这些断言工厂在启动时已经生成对应的bean，我们才可以在 yml 中配置一下，即可生效

   • RetryGatewayFilterFactory：各种 Gateway 过滤器，正是这些过滤器在启动时已经生成对应的bean，我们才可以在 yml 中配置一下，即可生效

   • GlobalFilter实现类：全局过滤器

3. HttpHandlerAutoConfiguration和WebFluxAutoConfiguration配置类，在GatewayAutoConfiguration之后实例化

   分别实例化了HttpHandler和WebFluxConfigBean

第2章 执行流程

上一文中讲到Hystrix的原理，在Hystrix中核心业务逻辑都是通过响应式编程完成的，事实上，在Gateway中也都是基于同样的编程风格。同样的，Gateway的流程同SpringMVC流程也非常相似。

当前端有请求进来的时候，大体的流程如下：

1. 首先被DispatcherHandler给捕获拦截，然后对请求的URI进行解析

2. 然后根据URI去调用HandlerMapping，获取真正要执行的WebHandler

3. 然后选择一个合适的适配器HandlerAdapter执行

4. 执行WebHandler

当请求gateway服务时，所有的请求都会进入到DispatcherHandler中的handle方法，下面我们一起看看这个方法

@Override
public Mono handle(ServerWebExchange exchange) {
    if (this.handlerMappings == null) {
        return createNotFoundError();
    }
    //这里就是webFlux的响应式编程
    return Flux
        // 1.这里就是遍历所有的 handlerMapping
        .fromIterable(this.handlerMappings)
        // 2.获取对应的handlerMapping ，比如常用的 RequestMappingHandlerMapping、RoutePredicateHandlerMapping
        .concatMap(mapping -> mapping.getHandler(exchange))
        .next()
        .switchIfEmpty(createNotFoundError())
        // 3.获取对应的适配器，调用对应的处理器
        .flatMap(handler -> invokeHandler(exchange, handler))
        // 4.返回处理结果
        .flatMap(result -> handleResult(exchange, result));
}

2.1 getHandler

我们先来看看getHandler方法，它就是Gateway的核心逻辑所在，再getHandler中获取对应的HandlerMapping。

下面是AbstractHandlerMapping.getHandler的源码

@Override
public Mono