Zull和Gateway请求IO模型比对(WebFlux优势)以及Reactor模型分析

背景
Zull 请求处理模型
Gateway
Doug Lea Reactor模型
总结

背景

最近在做一些开源网关的调研，首选也是主流的网关就是Zull和Gateway。然后在性能上基于Zull和Gateway的请求处理模型做了一些比对

Zull 请求处理模型

首先需要说明的是这里的Zull版本是1.x,同时zull采用的是Tomcat容器，使用的是传统的Servlet IO处理模型,如下图简化版本的图片:

第二张图片来源于zull官方

可以看到处理模型比较简单。首先每个请求的servlet由servlet container进行生命周期管理。container启动时构造servlet对象并调用servlet init()进行初始化；container关闭时调用servlet destory()销毁servlet；container运行时接受请求，并为每个请求分配一个线程（一般从线程池中获取空闲线程）然后调用service()方法去处理业务逻辑缺点：servlet是一个简单的网络IO模型，基于阻塞和多线程运行的。当请求进入servlet container时，servlet container就会为其绑定一个线程，在并发不高的场景下这种模型是适用的，但是一旦并发上升，线程数量就会上涨，而线程资源代价是昂贵的（操作系统的上线文切换，内存消耗大）严重影响请求的处理时间。在一些简单的业务场景下，不希望为每个request分配一个线程，只需要1个或几个线程就能应对极大并发的请求，这种业务场景下servlet模型没有优势优点：编程模型简单，易于理解

基于以上的一些缺点Zull 2.0 做了重大重构，对整个架构，首先IO模型选用了异步非阻塞，所以底层的通信框架选用了Netty 改进后的IO处理如下但是由于SpringCloud 暂时没有集成Zull 2.0的计划。所以一般微服务中如果选用Zull网关多的还是1.x版本

Gateway

随着Spring 5 推出的WebFlux,它是完全异步且非阻塞的，底层也是基于Netty实现的。在处理IO密集型请求场景下有着更大的优势。所以Gateway本身的起点就要比Zull高。我们一起来看看Gateway请求处理模型可以看到NettyServer的Boss Group线程池内的线程循环接收这个请求，然后把完成了TCP三次握手的连接channel交给Worker Group中的某一个事件循环线程来进行处理（该事件处理线程会调用对应的controller进行处理）。所以WebFlux的handler执行是使用Netty的IO线程进行执行的，所以需要注意如果handler的执行比较耗时，会把IO线程耗尽导致不能再处理其他请求，可以通过Reactor的publishOn操作符切换到其他线程池中执行。

Doug Lea Reactor模型

上面的图其实已经表现的比较清晰了，但是我们再结合Doug Lea的Reactor模型来理解下

Doug Lea 论文pdf原地址:http://gee.cs.oswego.edu/dl/cpjslides/nio.pdf

可以看到单线程的Reactor和上面的图类似，其中上面的Reactor就是EventGroup(bossGroup),负责处理请求的三次握手，返回结果。而业务请求处理就是交给线程池ThreadPool去处理(workerGroup)即,即Netty中我们编写的一些Handler,这些业务处理就包括编解码，心跳等。可以看到这种单线程的Reactor缺点就是一个EventGroup做了太多事，请求相应，握手等。所以Doug Lea提出了多线程的Reactor模型

如下图相比单线程的Reactor模型，我们在Boss Group又做了拆分，分为mainReactor和subReactor，可以看到mainReactor主要负责连接处理，而subReactor负责数据的读取，数据的返回，当然数据的业务操作还是交给workerGroup线程池去处理