背景

随着异步 I/O 和 Netty 等框架的流行，响应式编程逐渐走入大众的视野。但是，响应式编程本身并不是太新的概念，这个术语最早出现在 1985 年 David Harel 和 Amir Pnueli 的论文“响应式系统的开发”之中，他们对复杂计算机系统的特征进行了归纳，提出了一种新颖的二分方式：转换式（Transformative）与响应式（Reactive）系统。转换式系统接收已知的一组输入，转换这些输入并产生输出，而响应式系统则会持续受到外部环境的刺激，它们的角色就是持续响应刺激。在构建响应式 Web 服务上，Spring 5 中引入了全新的编程框架，那就是 Spring WebFlux。作为一款新型的 Web 服务开发框架，它与传统的 WebMVC 相比具体有哪些优势呢？

Spring WebFlux

介绍

Spring WebFlux 作为一个响应式 (reactive-stack) web 框架补充，在 5.0 的版本开始加入到 Spring 全家桶。这是一个完全非阻塞的，支持 Reactive Streams, 运行在诸如 Netty, Undertow, 以及 Servlet 3.1+ 容器上的，Spring WebFlux 构建在 Reactor 框架之上，提供了基于注解和函数式两种方式来配置和运行。Spring WebFlux 可以让你使用更少的线程去处理并发请求，同时能够让你使用更少的硬件资源来拓展你的应用。WebFlux 使用Netty作为默认的web服务器，其依赖于非阻塞IO，并且每次写入都不需要额外的线程进行支持。也可以使用Tomcat、Jetty容器，不同与SpringMVC依赖于Servlet阻塞IO，并允许应用程序在需要时直接使用Servlet API，WebFlux依赖于Servlet 3.1非阻塞IO。使用Undertow作为服务器时，WebFlux直接使用Undertow API而不使用Servlet API。

特点

• 非阻塞式，在有限资源下,提高系统吞吐量和伸缩性,以Reactor为基础实现响应式编程，异步非阻塞 I/O 模型，认为应用不会阻塞当前线程，所以只是需要一个包含少数固定线程数的线程池 (event loop workers) 来处理请求
• 函数式编程，Spring5框架基于Java8, WebFlux使用Java8函数式编程方式实现路由请求
• 支持异步I/O的Netty、Undertow等框架，以及基于Servlet 3.1+的容器（如Tomcat 8.0.23+和Jetty 9.0.4+）；
• 支持响应式的数据访问Spring Data Reactive Repositories；
• 支持响应式的安全访问控制Spring Security Reactive；

场景

WebFlux 用于构建响应式 Web 服务。微服务架构的兴起为 WebFlux 的应用提供了一个很好的场景。我们知道在一个微服务系统中，存在数十乃至数百个独立的微服务，它们相互通信以完成复杂的业务流程。这个过程势必会涉及大量的 I/O 操作，尤其是阻塞式 I/O 操作会整体增加系统的延迟并降低吞吐量。如果能够在复杂的流程中集成非阻塞、异步通信机制，我们就可以高效处理跨服务之间的网络请求。针对这种场景，WebFlux 是一种非常有效的解决方案。控制层一旦使用 Spring WebFlux，它下面的安全认证层、数据访问层都必须使用 Reactive API。其次，Spring Data Reactive Repositories 目前只支持 MongoDB、Redis 和 Couchbase 等几种不支持事务管理的 NOSQL。技术选型时一定要权衡这些弊端和风险。

响应式编程

响应式编程是一种面向数据流和变化传播的编程范式,这意味着可以在编程语言中很方便地表达静态或动态的数据流,而相关的计算模型会自动将变化的值通过数据流进行传播,电子表格程序就是响应式编程的。

响应式应用应该具备如下的四个特点：

• 即时响应性（Responsive）：只要有可能，系统就会及时地做出响应。响应能力是可用性和实用性的基石，但是更加重要的是，响应能力意味着可以快速地检测出问题并且行之有效地解决它
• 弹性（Resilient）：系统在出现失败（Failure）时依然保持即时响应性。
• 适应性（Elastic）：系统在变化的工作负载之下依保持着即时响应性。反应式系统可以通过增加或者减少分配给服务于输入（负载的）资源，来响应输入（负载的）速率的变化
• 消息驱动（Message Driven）：反应式系统依赖异步的消息传递来确立组件之间的边界，以确保松散耦合、隔离以及位置透明性

并发模型

WebFlux模型主要依赖响应式编程库Reactor，Reactor 有两种模型，Flux 和 Mono，提供了非阻塞、支持回压机制的异步流处理能力。WebFlux API接收普通Publisher作为输入，在内部使其适配Reactor类型，使用它并返回Flux或Mono作为输出。

Spring WebMVC

介绍

SpringMvc是一种基于java的实现Mvc设计模式的请求驱动类型的轻量级web框架，属于SpringFrameWork的后续产品，已经融合在Spring Web Flow中，SpringMvc已经成为目前最主流的MVC框架之一，并且随着Spring3.0的发布，全面超越Struts2，成为最优秀的mvc框架，他通过一套注解，让一个简单的java类成为处理请求的控制器，他无需实现任何接口，同时他还支持RESTful编程风格的请求。

特点

• 清晰地角色划分
• 灵活的配置功能
• 提供了大量的控制器接口和实现类
• 真正的View层实现无关（JSP、Velocity、Xslt等）
• 国际化支持
• 面向接口编程
• Spring提供了Web应用开发的一整套流程，不仅仅是MVC，他们之间可以很方便的结合一起

MVC

Spring web MVC框架提供了MVC(模型 - 视图 - 控制器)架构和用于开发灵活和松散耦合的Web应用程序的组件。 MVC模式导致应用程序的不同方面(输入逻辑，业务逻辑和UI逻辑)分离，同时提供这些元素之间的松散耦合。

• 模型(Model)封装了应用程序数据，通常它们将由POJO类组成。
• 视图(View)负责渲染模型数据，一般来说它生成客户端浏览器可以解释HTML输出。
• 控制器(Controller)负责处理用户请求并构建适当的模型，并将其传递给视图进行渲染

并发模型

servlet由servlet container进行生命周期管理。container启动时构造servlet对象并调用servlet init()进行初始化；container关闭时调用servlet destory()销毁servlet；container运行时接受请求，并为每个请求分配一个线程（一般从线程池中获取空闲线程）然后调用service()。

处理请求的时候同步操作，一个请求对应一个线程来处理，并发上升，线程数量就会上涨（上线文切换，内存消耗大）影响请求的处理时间。现代系统多数都是IO密集的，同步处理让线程大部分时间都浪费在了IO等待上面。虽然Servlet3.0后提供了异步请求处理与非阻塞IO支持，但是使用它会远离Servlet API的其余部分，比如其规范是同步的（Filter, Servlet）或阻塞的（getParameter,getPart），而且其对响应的写入仍然是阻塞的。

总结

Spring WebFlux 不是 Spring MVC 的替代方案，Spring WebFlux 是 Spring Framework 5.0中引入的新的响应式web框架。与Spring MVC不同，它不需要Servlet API，是完全异步且非阻塞的，并且通过Reactor项目实现了Reactive Streams规范。Spring MVC依然构建在 Servlet API 以及 Servlet 容器之上；Spring Security 为两种不同的技术栈提供了安全性的支持，Spring Data 分别为两种不同的技术栈实现了 Repository；在数据访问方面，响应式 Repository 已经涵盖了 Mongo、Cassandra、Redis 以及 Couchbase。但是在关系型数据库方面，因为 JBDC 规范本身就是阻塞式的，所以进展并不明显。但是，像 PostgreSQL 和 MySQL 已经有了异步驱动。异步非阻塞并不会使程序运行得更快。WebFlux 并不能使接口的响应时间缩短，它仅仅能够提升吞吐量和伸缩性。Spring WebFlux 是一个异步非阻塞的 Web 框架，所以，它特别适合应用在 IO 密集型的服务中，比如微服务网关这样的应用中。