第3章 · 规范与协议
第 3 章 · 规范与协议
章节摘要：Reactive Streams 是响应式生态的「宪法」——仅 4 接口、13 方法，却把背压、错误传播与取消写成可跨库验证的契约。本章从规范正文到 R2DBC、MQTT 等衍生协议。
本章要回答的问题
- Publisher/Subscriber/Subscription/Processor 各自承诺什么？
- 2013 Netflix 微服务雪崩如何催生这份最小契约？
- Java 9
Flow、R2DBC 与规范如何对齐？
子章节导航
| 节 | 主题 | 读完应能 |
|---|---|---|
| 3.1 | Reactive Streams 规范 | 背诵 13 方法的状态机约束 |
| 3.2 | 衍生规范与扩展 | 说明 R2DBC 与 JDBC 阻塞差异 |
战略意义
规范不规定线程模型，只规定交互是否正确。这使 Spring WebFlux 与 Vert.x、Kotlin Flow 与 Java Reactor 能在同一 JVM 内通过 Publisher 桥接——如同 TCP/IP 让异构网络互通。
「规范不规定线程模型」这句话需要展开理解。Reactive Streams 允许所有回调在同一个线程串行发生，也允许跨线程调度——它只约束顺序与数量：onNext 之间必须串行，onError 后不能再有 onNext，request 累计不得超过下游能力。正因为不绑定线程，规范才能同时被 Reactor（基于 Netty）、RxJava 3（基于自定义调度）、Kotlin Flow（基于协程调度器）实现，而它们之间仍可通过 Publisher 接口互相桥接。这是「接口即契约」的胜利：实现自由，行为一致。
阅读地图
本章是全书最「文本化」的一章，建议对照两种阅读方式：
- 规范视角（3.1）：把四接口当状态机读——每个方法触发什么状态迁移，违规会产生什么后果；
- 生态视角（3.2）：看这份契约如何被 R2DBC、RSocket、MQTT 5 等协议继承与扩展——「背压」从 JVM 内部语义上升为跨进程协议语义。
读 3.1 前最好先回顾 2.1 的信号模型（onSubscribe/onNext/onError/onComplete）与 2.3 的 request 语义，因为规范文本正是把这些「机制」逐条写成「义务」。两章连着读，机制与条文会互相印证。
全链路非阻塞检查
读完本章后，你可以用它检查一条链路是否「规范合规」：浏览器（RxJS）→ 网关（WebFlux）→ 服务（Reactor）→ 数据库（R2DBC）。逐跳问三个问题：
- 这一跳传输的元素是不是流（而非整块缓冲）？
- 这一跳有没有背压信号的回传通道（request / 窗口 / ack）？
- 错误是作为信号传递（onError / error frame），还是被吞掉？
链路中任何一跳答不上来，契约就在那里断裂——这正是 4.3 选型时要重点审计的。
读 3.1 时对照 SOURCE 中 Netflix RxJava 与 Akka HTTP 背压语义鸿沟复盘：优秀框架在隐式契约不一致时仍会系统性失效。