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

╰半夏微凉° 2022-09-11 03:29 6阅读 0赞

### 文章目录 ###

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

## 背景 ##

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

## Zull 请求处理模型 ##

首先需要说明的是这里的Zull版本是1.x,同时`zull`采用的是Tomcat容器，使用的是传统的Servlet IO处理模型,如下图  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAd2VpaHViZWF0cw_size_20_color_FFFFFF_t_70_g_se_x_16]  
简化版本的图片:  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAd2VpaHViZWF0cw_size_17_color_FFFFFF_t_70_g_se_x_16]

> 第二张图片来源于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处理如下  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAd2VpaHViZWF0cw_size_16_color_FFFFFF_t_70_g_se_x_16]  
但是由于SpringCloud 暂时没有集成Zull 2.0的计划。所以一般微服务中如果选用Zull网关多的还是1.x版本

## Gateway ##

随着Spring 5 推出的`WebFlux`,它是完全异步且非阻塞的，底层也是基于Netty实现的。在处理IO密集型请求场景下有着更大的优势。所以`Gateway`本身的起点就要比`Zull`高。我们一起来看看`Gateway`请求处理模型  
![在这里插入图片描述][watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAd2VpaHViZWF0cw_size_20_color_FFFFFF_t_70_g_se_x_16 1]  
可以看到`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

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

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

## 总结 ##

总的来说在Gateway在目前网关选型中会更优，然后也可以看出`Reactor`模型的强大，我们结合`WebFlux`分析了`Reactor`模型，让我们对`Reactor`模型理解更为透彻。

[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAd2VpaHViZWF0cw_size_20_color_FFFFFF_t_70_g_se_x_16]: /images/20220828/69eec1218038420fb5cb57f4cc0bc8e5.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAd2VpaHViZWF0cw_size_17_color_FFFFFF_t_70_g_se_x_16]: /images/20220828/d77eb4c0f0544d20a6353e1eedf9c1e0.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAd2VpaHViZWF0cw_size_16_color_FFFFFF_t_70_g_se_x_16]: /images/20220828/720e0cecebaf49a896fe6fa05f863361.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAd2VpaHViZWF0cw_size_20_color_FFFFFF_t_70_g_se_x_16 1]: /images/20220828/1f179cf88c144e5fa89be2fec51ab879.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAd2VpaHViZWF0cw_size_20_color_FFFFFF_t_70_g_se_x_16 2]: /images/20220828/80e2c56f39dd48f0806d7ef10dde8508.png
[watermark_type_ZHJvaWRzYW5zZmFsbGJhY2s_shadow_50_text_Q1NETiBAd2VpaHViZWF0cw_size_20_color_FFFFFF_t_70_g_se_x_16 3]: /images/20220828/e10745dfa3fd40faa3a41a9d38b1bea9.png