WebFlux实践与选型对比详解

WebFlux实践与选型对比详解

定位：第 07 篇，讲透全链路响应式的实践要求、WebClient、响应式数据访问，以及 MVC 与 WebFlux 的选型决策 适用版本：Spring Framework 6.x（JDK 17+）

目录

• 一、全链路响应式
• 二、WebClient
• 三、响应式数据访问
• 四、MVC vs WebFlux 选型
• 五、总结
• 六、常见高频面试题

一、全链路响应式

1.1 收益的前提：端到端非阻塞

WebFlux 的收益建立在整条调用链都非阻塞之上：

请求 → WebFlux → WebClient（调下游）→ 响应式驱动（DB/缓存）→ 返回
非阻塞 非阻塞 非阻塞

任一环节阻塞（如同步 JDBC、阻塞的 HTTP 客户端），EventLoop 就被占住，收益归零甚至更差——这是"用了 WebFlux 却没变快"的最常见原因。

1.2 阻塞环节的两种处理

第二种是妥协：阻塞仍占线程，只是不占宝贵的 EventLoop。

二、WebClient

2.1 定位

响应式非阻塞 HTTP 客户端，替代 RestTemplate（后者已进入维护模式，新项目用 WebClient）。

2.2 用法

WebClient client = WebClient.create();

Mono<User> user = client.get()
.uri("/users/{id}", id)
.accept(MediaType.APPLICATION_JSON)
.retrieve()
.bodyToMono(User.class); // 返回 Mono，惰性

Flux<Order> orders = client.get()
.uri("/orders")
.retrieve()
.bodyToFlux(Order.class);

要点：与 Reactor 一致，调用链在 subscribe 前不发起请求；WebFlux 中直接返回 Mono/Flux 给框架。

2.3 错误与配置

.retrieve().onStatus(…)：按状态码转异常
.exchangeToMono(…)：拿到完整响应自行处理
构建时配置：baseUrl、超时（连接/响应）、连接池、编解码器

超时必配——响应式客户端不配超时同样会无限等待（01 篇纪律在响应式下依然成立）。

三、响应式数据访问

3.1 驱动选择

传统 JDBC 是阻塞式——在 WebFlux 里直接用它会阻塞 EventLoop，必须换 R2DBC 或隔离到弹性调度器。

3.2 与 Spring Data 的整合

Spring Data 提供响应式仓库接口：

public interface UserRepo extends ReactiveCrudRepository<User, String> { }
// 方法返回 Mono<User> / Flux<User>

3.3 响应式事务

响应式链路不能依赖 ThreadLocal 传递事务连接（线程会切换）
→ 用 ReactiveTransactionManager + @Transactional（响应式支持）
→ 事务上下文通过 Reactor Context 传播

这是响应式与命令式事务模型的本质差异：连接/会话不再绑定线程，而随订阅上下文流动。

四、MVC vs WebFlux 选型

4.1 决策维度

4.2 典型适用与不适用

适合 WebFlux：API 网关、实时推送（SSE/WS）、流式数据、聚合编排大量下游
不适合：常规 CRUD 业务系统、依赖大量阻塞库、团队无响应式经验

4.3 虚拟线程（JDK 21）的新变量

虚拟线程让"同步写法 + 高并发"重新可行：
每个请求一个（廉价的）虚拟线程，阻塞不再昂贵
→ 部分"为并发上 WebFlux"的场景，可用 MVC + 虚拟线程替代
→ 保留同步编程模型，降低复杂度

选型时要把虚拟线程纳入考量：若 JDK 21+ 可用，许多场景"同步 + 虚拟线程"比响应式更划算。

4.4 渐进式策略

不必非黑即白：
① MVC 项目里，个别接口返回 CompletableFuture/Mono（Spring MVC 支持异步返回值）
② 用 WebClient 替换 RestTemplate（即使非 WebFlux）
③ 确有收益的模块单独上 WebFlux

五、总结

六、常见高频面试题

1. 为什么说 WebFlux 需要"全链路响应式"才有收益？

要点：WebFlux 用少量 EventLoop 线程服务所有连接，前提是这些线程永不被阻塞。若链路中某环节阻塞（同步 JDBC、阻塞 HTTP 客户端），EventLoop 被占住，该线程上所有连接停摆——非阻塞的收益被阻塞点完全抵消，甚至因模型复杂度而更差。所以必须端到端非阻塞（响应式驱动），或把阻塞环节隔离到弹性调度器。

2. WebClient 和 RestTemplate 的区别？

要点：RestTemplate 是同步阻塞客户端（已进入维护模式，不再加新功能）；WebClient 是异步非阻塞、基于 Reactor，返回 Mono/Flux，支持背压与流式，可在 WebFlux 与 MVC 中使用。新项目推荐 WebClient。使用差异：WebClient 调用链惰性（不订阅不发起）、需自行处理错误（onStatus）、必须配置超时与连接池。

3. 在 WebFlux 里访问关系型数据库怎么办？

要点：传统 JDBC 阻塞，直接在响应式链上用会占住 EventLoop。方案：① 首选 R2DBC——关系库的响应式驱动，配合 Spring Data R2DBC，仓库返回 Mono/Flux；② 无法迁移时，把 JDBC 调用用 subscribeOn(Schedulers.boundedElastic()) 隔离到弹性线程池（妥协方案，仍占线程）。事务用 ReactiveTransactionManager。

4. 响应式事务和传统事务有什么不同？

要点：传统（命令式）事务把连接绑定到当前线程（ThreadLocal），方法调用链天然共享。响应式链执行跨线程切换，ThreadLocal 失效——连接不能绑线程。解法：ReactiveTransactionManager + @Transactional 的响应式支持，事务上下文通过 Reactor Context（随订阅流动而非线程）传播，保证同一流上的操作共享事务。这是响应式模型"线程不持有状态"的体现。

5. 什么场景适合用 WebFlux？

要点：IO 密集 + 海量并发连接的场景收益最大：API 网关（大量转发与聚合）、实时推送（SSE/WebSocket 服务）、流式数据处理、需要编排大量下游调用的聚合服务。不适合：常规 CRUD（复杂度不划算）、CPU 密集（响应式无收益）、依赖生态多为阻塞库、团队无响应式经验。原则：并发瓶颈真实存在且生态支持，才选。

6. JDK 21 虚拟线程对 MVC vs WebFlux 选型有什么影响？

要点：虚拟线程让"每个请求一个线程"的同步模型重新廉价——阻塞时虚拟线程被挂起而非占用平台线程，高并发不再需要海量平台线程。于是许多"为并发上 WebFlux"的场景，可以用 MVC + 虚拟线程替代，保留同步编程模型与简单调试，复杂度远低于响应式。选型时：JDK 21+ 可用且依赖阻塞为主，虚拟线程往往是更优解；响应式保留给流式/背压等特殊需求。

7. 阻塞代码必须保留时，在 WebFlux 里怎么处理？

要点：用调度器隔离：把阻塞段用 subscribeOn 或 publishOn 切到 Schedulers.boundedElastic()（专为阻塞设计的弹性线程池），让阻塞发生在独立池而非 EventLoop。示例：Mono.fromCallable(blockingCall).subscribeOn(boundedElastic())。注意这是妥协——阻塞仍消耗线程与资源，只是保护了 EventLoop；能换响应式实现（R2DBC、WebClient）应优先换。

8. WebClient 如何处理错误和超时？

要点：错误：.retrieve().onStatus(谓词, 响应→异常) 把 4xx/5xx 转为自定义异常在链上处理；或用 .exchangeToMono 拿完整响应自行决定。超时：构建时通过 HttpClient 配置连接超时与响应超时（reactor-netty），或链上 .timeout(Duration)。纪律：不配超时的客户端会无限等待，与同步调用一样必须设超时（01 篇的通用纪律在响应式下不变）。

9. 能只用 WebClient 不上 WebFlux 吗？

要点：可以。WebClient 是独立组件，在 Spring MVC（同步）项目里也能用，适合调用下游的异步编排、并行聚合多个远程结果（返回 Mono/Flux 组合），或替换 RestTemplate。此时 Web 入口仍是 MVC 的同步模型，只是出站调用用响应式客户端。这体现了"按需引入响应式能力"的渐进策略，不必整体迁移。

10. 团队要引入 WebFlux，有哪些风险和准备？

要点：风险：① 学习曲线陡（响应式思维、操作符、惰性执行）；② 调试排障难（异步堆栈不连贯）；③ 生态约束（阻塞依赖要换或隔离）；④ 运维监控方式不同。准备：先小范围试点（如一个网关或聚合服务）验证收益；统一阻塞处理规范（换响应式驱动或隔离调度器）；建立响应式测试（StepVerifier）与观测（上下文传播日志）；评估虚拟线程是否是更简单的替代。避免全量盲目迁移。