Spring WebFlux和Spring MVC的对比
原文网址：Spring WebFlux和Spring MVC的对比-CSDN博客
简介
本文介绍Spring WebFlux和Spring MVC的区别。
Webflux：是异步非阻塞的（IO多路复用），基于Netty。适合网络转发类的应用，比如：网关。
MVC：是同步阻塞的，基于Servlet。适合阻塞性的业务应用，比如：读写数据库等普通业务。
Webflux和MVC
功能性
Overview :: Spring Framework
Spring MVC 和 WebFlux 可以共存
在一个同时引入了 Spring MVC 和 Spring WebFlux 的项目中，Spring 通过请求路径的映射机制以及底层的配置来区分应该将请求交给谁处理（DispatcherServlet 或 WebHandler）。
返回值类型决定了处理器：
- 如果控制器方法返回阻塞类型（如 String、ResponseEntity<T>），请求会由 Spring MVC 的 DispatcherServlet 处理。
- 如果控制器方法返回响应式类型（如 Mono<T> 或 Flux<T>），请求会由 Spring WebFlux 的 WebHandler 处理。
Spring 的默认行为限制：
- Spring MVC 控制器和Spring WebFlux 控制器在逻辑上是完全独立的。
- 同一个控制器（@RestController 类）不能混用阻塞式方法和响应式方法。否则，Spring 不知道该为这个控制器注册到哪个处理器中（因为一个控制器只能归属到一个处理器）。
官方使用建议
官方建议：
- 如果已经有了一个运行良好的SpringMVC 应用程序，则无需更改。命令式编程是编写、理解和调试代码的最简单方法，我们可以选择最多的库，因为从历史上看，大多数都是阻塞的。
- 如果是个新应用且决定使用 非阻塞 Web 技术栈，那么 WebFlux 是个不错的选择。
- 对于使用 Java8 Lambda 或者 Kotlin 且 要求不那么复杂的小型应用程序或微服务来说，WebFlux 也是一个不错的选择。
- 在微服务架构中，可以混合使用 SpringMVC 和 Spring WebFlux，两个都支持基于注解的编程模型。
- 评估应用程序的一种简单方法是检查其依赖关系。如果要使用阻塞持久性 API（JPA、JDBC）或网络 API，那么 Spring MVC 至少是常见架构的最佳选择。
- 如果有一个调用远程服务的 Spring MVC 应用程序，请尝试响应式WebClient。
- 对于一个大型团队，向非阻塞、函数式和声明式编程转变的学习曲线是陡峭的。在没有全局开关的情况下，想启动 WebFlux，可以先使用 reactive WebClient。
Reactive和Servlet
官网地址：https://spring.io/reactive
总结
Spring Webflux的特点：
- 不能使接口的响应时间缩短，它仅仅能够提升吞吐量和伸缩性。
- 内部是响应式编程，以Reactor库为基础，基于异步和事件驱动，适合应用在网络IO密集型的服务中，如网关。
- 不是Spring MVC的替代方案，它们是不同的应用场景。
- 默认情况下使用Netty作为服务器，不支持MySQL。
- 前端控制器是DispatcherHandler（Spring MVC是DispatcherServlet。）
- 支持两种编程风格，一种是Spring MVC的注解形式，另一种是Java 8 Lambda函数式编程。
- 类型：Mono返回0或者1个元素，即单个对象。Flux返回N个元素，即List列表对象。
- 没有拦截器概念，类似的工作需要在过滤器中完成，例如：Token验证用过滤器。
- 可以用@ControllerAdvice注册全局异常处理器，但它仅对Controller中抛出的异常生效，无法顾及到过滤器。对异常，推荐的方式是注册WebExceptionHandler。