SpringCloud gateway源码走读（顺带聊聊响应式）

1.概述

最近公司海外要搭建一套网关系统，调研相关开源组件，最终选择了springcloud gateway（scg）的网关框架。为了更好的使用，便走读了其核心源代码。本文对其重点源码就行剖析。scg是基于spring webflux实现的。如果 响应式基础不错的话会更容易理解。

2.聊聊响应式（事件循环）

其实对响应式开发一直很感兴趣，如果整个链路都支持响应式api，那么对于cpu的吞吐量会有很大的提升。毕竟更少的线程能负载高的qps，是非常吸引人的事情。说个玩笑话，对于泛娱乐c端业务，完全可以采用此架构，只不过学习成本确实很高，这一点就可以把这个方案否决掉。但是对于网关来讲，webflux还是非常迷人的。至少对我公司业务，网关鉴权通过响应式的rpc call可以大幅提升吞吐量。

两个问题:为什么可以减少线程数？是否可以提高响应速度？

响应式确实不能降低一个请求的处理时间，比如一个请求查询数据库300ms，这个除非在db优化，不然没有人能降低这个时间。响应式也是一个道理。那么响应式有什么用，这也就来到第二个问题。

非响应式的场景

对于一个http请求，接受请求是tomcat线程（默认500个），在处理redis操作的时候，用的redis的连接池，但是redis要经过一次网络io，阻塞的过程中，这个tomcat线程什么都干不了。

响应式

netty的eventloop接收http请求，执行redis操作的时候通过redis响应式API，eventloop会立刻返回（将数据丢给redis客户端线程），redis底层基于epol进行非阻塞IO，redis客户端线程将数据丢给网络然后返回，这个过程都非阻塞的。等redis 处理完成之后，epoll的机制去通知redis线程执行回调时间，完成整个网络。整个执行过程中线程各司其职（完全cpu密集操作），eventloop只负责接收以及传递，redis负责丢网络以及监听返回。当然你可以理解将阻塞交给了操作系统。

3.源码解析

底层通过netty启动的http服务器。所有请求进来之后先由DispatcherHandler的handle方法处理。handle方法会调用所有HandlerMapping的getHandlerInternal方法，选择一个支持该请求的Handler执行后续逻辑。

RoutePredicateHandlerMapping

我们重点关心scg实现的HandlerMapping：RoutePredicateHandlerMapping

@Bean

public RoutePredicateHandlerMapping routePredicateHandlerMapping(FilteringWebHandler webHandler,

      RouteLocator routeLocator, GlobalCorsProperties globalCorsProperties, Environment environment) {

   return new RoutePredicateHandlerMapping(webHandler, routeLocator,