S07-A02 · WebFlux vs MVC：响应式到底适合谁

适用读者：被"响应式能提升性能"说服过、或正在犹豫的人。
前置：S07-J05、S05-B05（线程池）。
覆盖旧文：458（WebFlux 适合什么业务，204 点）。
覆盖扩展：E-S07-019（响应式收益与代价）。
上一篇：S07-A01 · 安全框架选型：Spring Security vs Shiro
下一篇：S07-X01 · 八股速查。

1. 一句话结论

响应式不是"更快的 Web 框架"，是"用更少的线程扛更多并发连接"的模型。它的收益只在"高并发 + IO 等待多"时成立，代价是"整条链路都要非阻塞"。

维度	同步（MVC，一线程一请求）	响应式（WebFlux，事件循环）
并发模型	线程池	少量事件循环线程
适合	CPU 密集、逻辑复杂、团队熟悉	IO 密集、连接数巨大
阻塞调用	允许	禁止（会卡住事件循环）
调试	栈清晰	栈难读、需 `checkpoint`
生态	最全	部分库无响应式版本

2. 收益什么时候成立（E-S07-019）

收益 ≈ 并发连接数 ÷ 可用线程数

场景	用 MVC 够吗	用 WebFlux 值得吗
100 QPS、逻辑复杂	✅	❌（复杂度不值）
1 万长连接（推送/网关）	❌（线程耗尽）	✅
大量下游 HTTP 调用（扇出）	⚠️（线程等 IO）	✅
需要流式（SSE）	可以	更自然

判据："我的瓶颈是线程数（等 IO）还是 CPU？" 等 IO → 响应式；CPU → 加机器/优化算法。

3. 代价清单

代价	说明
全链路非阻塞	一个阻塞调用（JDBC）就会拖垮事件循环
团队学习成本	`Mono/Flux`、背压、调度器
生态限制	关系型数据库驱动多为阻塞（需 R2DBC）
调试困难	异步栈、`checkpoint` 追踪
与现有代码不兼容	不能"局部改造"

结论："部分服务用 WebFlux"通常不划算——除非该服务本身就是 IO 密集且独立。

4. 迁移与回滚

阶段	动作	回滚
试点	选一个 IO 密集型服务（如聚合网关）	保留 MVC 实现，按路由切换
数据层	换 R2DBC 或保留阻塞 + 独立线程池	改回 JDBC
观测	增加事件循环线程的阻塞检测（BlockHound 类工具）	—

铁律：没有"阻塞检测"就别上响应式——阻塞调用是它最大的隐形杀手。

5. 五个误区

误区	真相
"WebFlux 比 MVC 快"	单请求延迟未必更低，收益在并发连接数
"可以局部把某个接口改成响应式"	一处阻塞就拖垮全局
"响应式=异步=高吞吐"	取决于是否 IO 密集
"JDBC 也能在 WebFlux 里用"	会阻塞事件循环
"上响应式是技术进步"	是权衡，多数业务不需要

6. 自检（架构师版）

响应式真正的收益条件是什么？
为什么"一个阻塞调用"会拖垮 WebFlux？
关系型数据库为什么是响应式的障碍？
什么样的服务适合试点？
没有阻塞检测就上响应式，风险是什么？

7. 下一篇

S07-X01 · Spring 八股速查与跨系列索引

最后一篇是附录索引：41 道 Spring 八股压成"题 → 一句话答案 → 正文位置"。

本篇属于系列《S07 · Spring 框架》。旧文来源：A-458；扩展点 E-S07-019。