25.2 Spring WebFlux 架构与适用场景

Spring WebFlux 是 Spring 5 引入的响应式 Web 框架，与传统的 Spring MVC 并肩而立，但它在底层基于完全不同的编程模型和运行时架构。理解 WebFlux 的内部机制，并不是为了“替换掉所有 MVC 应用”，而是为了在合适的场景下做出正确的技术选型。

25.2.1 架构核心：非阻塞与响应式流

Spring MVC 基于 Servlet API，采用的是一请求一线程的模型。在并发量较高或者存在大量等待 I/O 的慢操作时，线程池很容易成为瓶颈，因为每个阻塞的线程都在消耗内存和 CPU 上下文切换成本。

WebFlux 从根本上改变了这一模式。它构建在 Reactive Streams 规范之上，利用 Reactor 库提供的 Mono（0-1 个元素）和 Flux（0-N 个元素）作为异步序列，能够在等待远程数据时不阻塞线程。请求的处理线程只需要发起异步调用，然后立即返回去处理其他请求，数据就绪后由事件驱动的方式继续执行。

在架构上，WebFlux 的运行环境可以工作在多种容器上：

Netty：默认的、首选的响应式服务器，完全是异步非阻塞的。
Undertow / Jetty / Tomcat 8.5+ 的异步 Servlet 模式：借助 Servlet 3.1 的非阻塞 I/O 能力来运行，但真正的响应式特性仍有限制。
无需 Servlet 容器：WebFlux 应用可以脱离传统的 Servlet 容器，直接在 Netty 上启动，这也是 Spring Boot 中 WebFlux 的默认方式。

整个 WebFlux 的请求处理流程由 事件循环（Event Loop） 驱动，通常只需要少量线程即可处理数千甚至数万并发连接，而不会像线程池模型那样因线程耗尽而拒绝服务。

25.2.2 核心组件与处理模型

为了让开发者能够像编写 MVC 一样直观地使用响应式模型，WebFlux 复用了很多熟悉的注解和概念，但背后是截然不同的执行器。

1. 函数式与注解式双模式

WebFlux 同时支持两种编程风格：

注解式编程：与 Spring MVC 极其相似，使用 @RestController、@GetMapping 等注解，但返回的是 Mono 或 Flux 类型。例如：

@RestController
public class OrderController {
    @GetMapping("/orders/{id}")
    public Mono<Order> findById(@PathVariable String id) {
        return orderRepository.findById(id);
    }
}

函数式编程：使用 RouterFunction 和 HandlerFunction，将路由配置和请求处理函数式地组合起来，可以完全避免注解，特别适合需要动态路由或更高灵活性的场景：

@Bean
public RouterFunction<ServerResponse> route(OrderHandler handler) {
    return RouterFunctions
            .route(GET("/orders/{id}"), handler::findById);
}

2. 无阻塞的端到端链路

WebFlux 的非阻塞能力不仅体现在 Web 层，更需要整个技术栈的配合。这意味着：

数据库访问必须使用响应式驱动，例如 R2DBC（针对 SQL）、Reactive MongoDB、Reactive Redis 等。传统的 JPA 和 JDBC 因其阻塞特性无法在 WebFlux 中真正发挥异步优势，反而可能拖垮整个处理线程。
HTTP 客户端应当使用 WebClient（替代阻塞的 RestTemplate），它也是基于 Reactor 的非阻塞客户端。

只有从接收请求、调用服务、操作数据库到返回响应的全链路都采用非阻塞组件，WebFlux 的并发优势才能得以释放，否则在阻塞点处依然会拖住事件循环。

3. 背压（Backpressure）机制

WebFlux 底层遵循 Reactive Streams 规范，天然支持背压。简单来说，当数据生产者（如数据库查询结果）流水般产生数据，而消费者（如网络写出）处理不过来时，消费者可以反向通知生产者减缓或暂停发送，从而避免内存溢出。这在处理文件上传、流式数据推送等场景中尤为关键。

25.2.3 适用场景

WebFlux 不是 MVC 的全面替代品，而是针对特定问题的利器。以下场景最适合使用 WebFlux：

1. 网关与服务编排（API Gateway）

网关需要代理大量外部请求，并在多个后端服务之间聚合数据。由于大部分时间都消耗在等待 I/O 响应上，传统 MVC 会迅速耗尽线程池。WebFlux 用极少的线程就能处理海量并发连接，是构建高性能网关的理想选择。Spring Cloud Gateway 本身就基于 WebFlux 构建。

2. 实时数据流与长连接

如股票行情推送、聊天消息、物联网设备数据上报等场景，服务端需要同时维持数以万计的 WebSocket 或 SSE（Server-Sent Events）连接，并向客户端实时推送数据。WebFlux 的事件循环模型天然适合这种长连接、低吞吐但高并发的需求。

3. 高并发轻量服务

某些微服务自身不涉及复杂业务，只是简单地从缓存或文档数据库中读取数据并返回。这类服务几乎没有 CPU 密集计算，但并发数极高。将 MVC 线程池调整到几百甚至上千已不现实，而 WebFlux 可以在少量固定线程上平滑支撑数万 QPS。

4. 流式文件上传与下载

处理大文件的分块上传或流式下载时，WebFlux 能够以响应式流的方式分块写入磁盘或发送到客户端，全程不会将整个文件加载到内存，也不会阻塞请求线程。这在文件交换中心、影像服务等场景中价值明显。

25.2.4 不适合的场景与选型建议

WebFlux 并非万能，以下几种情况应谨慎选择：

以阻塞式 JDBC/JPA 为主要数据访问层：如果现有项目中大量依赖 MyBatis、Hibernate，这些框架本身是阻塞的，强行迁移到 WebFlux 只会让代码变得复杂且性能不升反降。此时应该继续使用 MVC。
团队缺乏响应式编程经验：响应式编程的调试、异常处理与思维模型与命令式编程差异很大，排查问题时堆栈信息复杂，入门成本较高。如果团队未做好准备，可暂时将 MVC 作为主力。
CPU 密集型业务：如果服务的瓶颈在于复杂的计算、加密或图像处理，响应式模型无法有效提升吞吐量，反而可能因为将计算投入事件循环线程而阻塞 I/O 调度。这时可以考虑用 MVC 配合异步任务线程池。

选型建议：在同一个项目中，也可以让 MVC 和 WebFlux 并存。例如，某些管理后台接口继续用 MVC 提供，而高并发的对外 API 单独拆出 WebFlux 服务。从架构演进的角度看，WebFlux 不是“下一个必须迁移的目标”，而是工具箱中为特定并发需求准备的先进武器。

理解了 WebFlux 的架构和适用边界，才能真正发挥它的价值。下一节我们将着力于函数式端点的定义与路由配置，进一步体会 WebFlux 在编程风格上的灵活性。