Spring WebFlux 01 (原理及使用场景)

Posted 2021-03-17 朦胧的夜~

一、什么是 Spring WebFlux

好多人以为Spring WebFlux就是Spring MVC的升级版，其实不然，那到底什么是Spring WebFlux呢，首先就要搞清楚Spring WebFlux与Spring MVC的不同点与相同点。

下图截自 Spring Boot 官方网站：

上图是Spring官方给出的Spring MVC和Spring WebFlux的对比图，先看最上面的描述信息，右侧是Spring MVC的描述：

Spring MVC is built on the Servlet API and uses a synchronous blocking I/O architecture whth a one-request-per-thread model.（翻译：Spring MVC构建在Servlet API之上，使用同步阻塞I/O架构，每个线程一个请求模型。）

左边是Spring WebFlux的描述：

Spring WebFlux is a non-blocking web framework built from the ground up to take advantage of multi-core, next-generation processors and handle massive numbers of concurrent connections.（翻译： Spring WebFlux是一个从头开始构建的非阻塞web框架，它利用多核、新一代处理器并处理大量并发连接。）

 

二、异同点

说完Spring WebFlux与Spring MVC的描述后，再来对比一下两者的相同点和区别具体看下图：

相同点：

1、都可以使用 Spring MVC 注解，如 @Controller, 方便我们在两个 Web 框架中自由转换；

2、均可以使用 Tomcat, Jetty, Undertow Servlet 容器（Servlet 3.1+）；

......

三、WebFlux特性

1、Spring MVC 因为是使用的同步阻塞式，更方便开发人员编写功能代码，Debug测试等，一般来说，如果 Spring MVC 能够满足的场景，就尽量不要用 WebFlux;

2、WebFlux 默认是通过 Netty 启动，并且自动设置了默认端口为 8080。另外还提供了对 Jetty、Undertow 等容器的支持。开发者自行在添加对应的容器 Starter 组件依赖，即可配置并使用对应内嵌容器实例。

但是要注意，必须是 Servlet 3.1+ 容器，如 Tomcat、Jetty；或者非 Servlet 容器，如 Netty 和 Undertow。

3、starter组件

Webflux 提供了很多 “开箱即用” 的 Starter 组件。Starter 组件是可被加载在应用中的 Maven 依赖项。只需要在 Maven 配置中添加对应的依赖配置，即可使用对应的 Starter 组件。例如，添加 spring-boot-starter-webflux 依赖，就可用于构建响应式 API 服务，其包含了 Web Flux 和 Tomcat 内嵌容器等。

4、WebFlux 官方提供了很多 Starter 组件，每个模块会有多种技术实现选型支持，来实现各种复杂的业务需求：

• Web：Spring WebFlux
• 模板引擎：Thymeleaf
• 存储：Redis、MongoDB、Cassandra。不支持 mysql
• 内嵌容器：Tomcat、Jetty、Undertow

四、WebFlux 分发请求

使用过 Spring MVC 的小伙伴们，应该到知道 Spring MVC 的前端控制器是 DispatcherServlet, 而 WebFlux 是 DispatcherHandler，它实现了 WebHandler 接口：

来看看DispatcherHandler类中处理请求的 handle 方法：

 

①：ServerWebExchange 对象中放置每一次 HTTP 请求响应信息，包括参数等；

②：判断整个接口映射 mappings 集合是否为空，空则创建一个 Not Found 的错误；

③：根据具体的请求地址获取对应的 handlerMapping;

④：调用具体业务方法，也就是我们定义的接口方法；

⑤：处理返回的结果；

五、WebFlux 的优势&性能

WebFlux 内部使用的是响应式编程（Reactive Programming），以 Reactor 库为基础, 基于异步和事件驱动，可以让我们在不扩充硬件资源的前提下，提升系统的吞吐量和伸缩性。

看到这里，你是不是以为 WebFlux 能够使程序运行的更快呢？量化一点，比如说我使用 WebFlux 以后，一个接口的请求响应时间是不是就缩短了呢？

抱歉了，答案是否定的！以下是官方原话：

Reactive and non-blocking generally do not make applications run faster.（翻译：被动和非阻塞通常不会使应用程序运行得更快。）

WebFlux 并不能使接口的响应时间缩短，它仅仅能够提升吞吐量和伸缩性。

六、WebFlux 应用场景

上面说到了， Spring WebFlux 是一个异步非阻塞式的 Web 框架，所以，它特别适合应用在 IO 密集型的服务中，比如微服务网关这样的应用中。

PS: IO 密集型包括：磁盘IO密集型, 网络IO密集型，微服务网关就属于网络 IO 密集型，使用异步非阻塞式编程模型，能够显著地提升网关对下游服务转发的吞吐量。

七、选 WebFlux 还是 Spring MVC?

首先你需要明确一点就是：WebFlux 不是 Spring MVC 的替代方案！虽然 WebFlux 也可以被运行在 Servlet 容器上（需是 Servlet 3.1+ 以上的容器），但是 WebFlux 主要还是应用在异步非阻塞编程模型，而 Spring MVC 是同步阻塞的，如果你目前在 Spring MVC 框架中大量使用非同步方案，那么，WebFlux 才是你想要的，否则，使用 Spring MVC 才是你的首选。

 

在微服务架构中，Spring MVC 和 WebFlux 可以混合使用，比如已经提到的，对于 IO 密集型服务(如网关)，我们就可以使用 WebFlux 来实现。

选 WebFlux 还是 Spring MVC? This is not a problem！

咱不能为了装逼而装逼，为了技术而技术，还要考量到转向非阻塞响应式编程学习曲线是陡峭的，小组成员的学习成本等诸多因素。

总之一句话，在合适的场景中，选型最合适的技术。