Spring WebFlux与Spring MVC

Spring WebFlux 是对 Spring Boot 项目中传统 Spring MVC 部分的一种替代选择，主要是为了解决现代 Web 应用在高并发和低延迟场景下的性能瓶颈。

1.WebFlux 是对 Spring MVC 的替代

• 架构替代：

  • Spring MVC 使用的是基于 Servlet 规范的阻塞式模型（一个请求分配一个线程）。
  • WebFlux 是一个完全基于非阻塞 I/O 的框架，底层可以脱离 Servlet 容器（如使用 Netty），也支持运行在 Servlet 容器上。

• 编程模型替代：

  • Spring MVC 使用同步（阻塞）模型，直接返回对象（如 String 或 ResponseEntity）。
  • WebFlux 使用响应式（Reactive）模型，返回类型是 Mono 或 Flux，实现非阻塞操作。

2.Spring MVC 和 WebFlux 的共存

Spring MVC 和 WebFlux 在同一个 Spring Boot 项目中不能同时工作。

原因是两者的核心架构和运行时环境不同：

• Spring MVC 基于 Servlet 规范和线程池模型。
• WebFlux 使用 Reactive Streams 和事件驱动模型。

在构建一个 Spring Boot 项目时，您需要明确选择使用 Spring MVC 或 WebFlux，Spring Boot 会根据选择加载不同的配置和依赖：

• 如果添加了 spring-boot-starter-web，默认启用 Spring MVC。
• 如果添加了 spring-boot-starter-webflux，则启用 WebFlux。

3.什么时候选择 WebFlux？

• 替代 Spring MVC 的场景：

  • 如果您的应用需要高并发和低延迟，比如实时聊天、通知推送、流式处理等，WebFlux 是理想的替代方案。
  • WebFlux 非常适合构建响应式微服务架构。

• 不适合替代的场景：

  • 如果您的应用是传统的 Web 应用，依赖阻塞式组件（如传统数据库驱动 JDBC、文件操作等），Spring MVC 更简单高效。
  • 如果团队对响应式编程不熟悉，切换到 WebFlux 会增加复杂性和维护成本。

3.WebFlux 的核心替代点

• 请求处理模型：

  • Spring MVC：每个请求分配一个线程，阻塞 I/O 操作。
  • WebFlux：使用少量线程处理所有请求，非阻塞 I/O 和事件驱动。

• 数据流处理：

  • Spring MVC：传统对象处理（如返回 List）。
  • WebFlux：基于流（Flux）的动态数据处理。

• 底层容器：

  • Spring MVC：需要 Servlet 容器（如 Tomcat、Jetty）。
  • WebFlux：支持非 Servlet 容器（如 Netty）和传统 Servlet 容器。

• 性能与扩展性：

  • Spring MVC：受限于线程池大小和阻塞式操作的性能瓶颈。
  • WebFlux：更高的并发和更低的资源占用。

4.WebFlux 替代 Spring MVC 的主要挑战

代码改造：

Spring MVC：

@RestController
public class HelloController {
    @GetMapping("/hello")
    public String sayHello() {
        return "Hello, Spring MVC!";
    }
}

WebFlux：

@RestController
public class HelloController {
    @GetMapping("/hello")
    public Mono<String> sayHello() {
        return Mono.just("Hello, WebFlux!");
    }
}

• 传统 Spring MVC 的控制器代码需要改写为响应式风格，返回类型从 String 或 ResponseEntity 改为 Mono 或 Flux。

学习曲线：

• 团队需要学习响应式编程（Reactive Programming），熟悉 Mono 和 Flux 的操作。

阻塞组件的兼容性：

• WebFlux 在引入阻塞组件（如传统 JDBC 驱动）时，可能会破坏非阻塞特性，因此需要替换为响应式驱动（如 R2DBC）。