Spring WebFlux 01 (原理及使用场景)
一、什么是 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！
咱不能为了装逼而装逼，为了技术而技术，还要考量到转向非阻塞响应式编程学习曲线是陡峭的，小组成员的学习成本等诸多因素。
总之一句话，在合适的场景中，选型最合适的技术。