1.1.4 Spring MVC 和 WebFlux 的适用性？

A natural question to ask but one that sets up an unsound dichotomy。实际上，两种一起用会扩大可用的范围。两者被设计用于相互连续统一，他们相互补充，互相弥补不足。下面图显示了两者的关系，它们的共同点和独有的特性：

我们建设你从下面几个点考虑下适用性：

• 如何你现有的Spring MVC应用程序运行的很好，不需要升级。命令式编程（Imperative programming）对程序的编写，理解和调试是最容易的。你目前可选的库，大部分是阻塞的。

• 如果你已经正在移植一个非阻塞的web栈，Spring WebFlux提供和其它一样的可执行的模型，也提供了许多可先的服务(Netty, Tomcat, Jetty, Undertow, and Servlet 3.1+ containers),和相关的lib(Reactor, RxJava, or other)。

• 如果你想用一个轻量的，使用java 8的lambdas或者Kotlin的函数web框架，你可以使用Spring WebFlux函数web endpoints。对于小应用程序或者没有复杂请求的微服务也是一个很好的选择。

• 在一个微服务架构中，你可以混着使用Spring MVC或者Spring WEbFlux控制器或者使用Spring WebFlux functional web endpooint。由于支持相同的声明式编程模型在两个框架中，这使得很容易复用现有的知识。

• 一个简单的方法来判断一个应用是否适用只要看下它的依赖。如果你使用一个阻塞的持久层APIs (JPA, JDBC)或者使用网编APIs，Spring MVC是最好的选择。典型的用法是使用 Reactor和RxJava建立独立线程执行阻塞，而不会使用非阻塞的web栈。

• 如果你的Sping MVC程序调用运程服务，试试响应式的webClient。你可以直接从Spring MVC控制器方法返回响应类型(Reactor, RxJava, or other)。每个调用等等时间越长，带来的益处越多。Spring MVC控制器也可以调用其它组件。

• 如果你有一个大的团队，脑子中要有对于非阻塞，函数式和声明式编程的学习曲线。开始没有全部转换的一个实践方法是使用响应式WebClient。同时小范围实践分析结果。我们所期望的是大范围的修改是不必要的。如果你不确定以还来多少好处，可以先学习下非阻塞IO看看它带来的影响。

参考：https://docs.spring.io/spring/docs/current/spring-framework-reference/web-reactive.html#webflux