第4章 · 技术生态

第 4 章 · 技术生态

章节摘要：规范落地为库与框架——Rx 家族横跨 JS/JVM/.NET，服务端以 Project Reactor + WebFlux 为主流，数据层靠 R2DBC 与 Reactive Mongo Driver 补全非阻塞 I/O。

子章节导航

读完本章应能

画出一条「浏览器 RxJS → WebFlux → R2DBC → PostgreSQL」链路，并标出每跳背压如何传递。

选型视角：生态不是单选

技术生态章最容易陷入「哪个框架更快」的比稿陷阱。正确的打开方式是按链路分层看：

1. 前端层：浏览器/Node 里的响应式事实标准是 RxJS，它不依赖 Reactive Streams 规范（JS 生态走自己的背压方式），但操作符语义与 Reactor 同源；
2. 服务端层：JVM 服务端在 Reactor（WebFlux 内核）与 Vert.x（独立事件驱动栈）之间选——它们都尊重规范，但运行时哲学不同；
3. 数据层：R2DBC、Reactive Mongo、Reactor Kafka 解决「最后一段非阻塞」——很多系统把前两层做好了，却在数据库驱动处断了链。

「前端 RxJS → WebFlux → R2DBC」这条链路里，背压只在 WebFlux 与 R2DBC 之间有规范意义上的 request 传导；浏览器到服务端之间靠 SSE/WebSocket 传输，只能做窗口级流控。画链路时给每一跳标注「背压是否真传导」，比记一堆框架名有用得多。

共同心法

读完三节后你应该能回答三个统一的问题：

这三个问题贯穿全章：生态选型的本质，是把「响应式契约」从一层蔓延到全链路，并审计每一跳是否真的兑现了契约。

生态全景图

把第 4 章的知识整合成一张分层图，按「层 → 代表实现 → 核心机制 → 常见坑」组织：

选型决策示例

// 团队已用 Spring Boot 3 + PostgreSQL → 推荐栈
// 前端: RxJS（已有）
// 网关/API: WebFlux + Netty
// 数据: R2DBC PostgreSQL（较成熟）
// 消息: Reactor Kafka
// Redis: Lettuce
// 每一跳都有明确机制，链路完整无阻塞
​

选型的顺序建议是「先锁数据层，再选服务端，最后补前端」——因为数据层是瓶颈最集中的地方，Oracle 无 R2DBC 这类限制会反向决定上层框架。第 4 章三节正是按这个顺序展开的：4.1 前端、4.2 服务端、4.3 数据层。

本章实践任务

画一条真实链路（建议用你工作中实际的技术栈），逐跳标注：传输协议、元素形态（对象/流）、背压机制、错误传递方式。完成后对照下表自查：

• 是否每一跳都有非阻塞实现？
• 背压是协议原生（RS/RSocket/MQTT 窗口）还是需要操作符近似（RxJS）？
• 哪一跳最可能成为断点（驱动缺失、阻塞 SDK、无背压协议）？

这个练习比读十遍文档都有效——它强迫你把 4.1-4.3 的散点知识组织成一张可审计的架构图。