1.3 发展历程与里程碑

1.3 发展历程与里程碑

本节摘要：响应式编程从 70 年代数据流编程、90 年代 FRP 学术奠基，经 2011 Rx.NET、2013 Manifesto、2014 Reactive Streams，到 Java 9 Flow 与全栈 R2DBC/RxJS，是一条螺旋上升的脉络。本节按时间线定位关键节点，避免「凭空冒出一个 Flux」。

你能学到什么

1. 说出 FRP 论文中 Behavior 与 Event 的区别
2. 列出 Rx、Manifesto、Reactive Streams、Java 9 Flow 的年份
3. 解释「全栈响应式」指什么

一、时间线

Conal Elliott 与 Paul Hudak 在 FRP 中形式化：Behavior a 是随时间连续变化的值（如鼠标位置），Event a 是离散发生（如点击）。这证明对时间的编程可以像对数据一样严谨。

FRP 论文的价值在于给出了「时间」的两种抽象，这正是今天所有响应式框架的基因源头：

• Behavior（行为）是「每个时刻都有一个值」——连续时间上的函数。今天的 BehaviorSubject、Reactor 的 BehaviorProcessor、RxJS 的 BehaviorSubject 都保留了这个名字。
• Event（事件）是「在某些时刻发生」——离散时刻的集合。今天的 onNext、onClick 事件流直接对应它。

两种抽象合在一起，等于承认：系统里既有连续状态，也有离散瞬变，必须用统一的时间模型把它们编织起来。命令式代码里这两种东西都要靠回调互相拼凑，FRP 给了它们共同的形式语言。

二、工业倒逼与标准化

2000 年代消息队列「推模型」常压垮消费者，各种 pull/ack/DLQ 补丁本质是在补偿背压缺失。Netflix 等推动 Reactive Streams，把背压从各框架私有实现升为宪法条款。

Rx 的革命性（SOURCE）：IObservable 与 IEnumerable 对称；提供 Throttle、Debounce、Window 解决 UI 真实痛点；并移植到 RxJS、RxJava。

值得强调的是「推模型压垮消费者」这条线。消息队列的经典故障模式是：生产者突发（秒杀、舆情），消费者处理不过来的消息在队列里积压，队列又按默认配置全部推给消费者，消费者内存溢出重启，重启后积压继续推送——恶性循环。各中间件给出的补丁方案不同：Kafka 用 max.poll.records 限制单次拉取，RabbitMQ 用 prefetch 限制在途消息，TCM 用流控。这些补丁本质上都是在业务侧重新发明 request(n)。Reactive Streams 的价值是把这条规则统一成接口级义务，让「消费者能约束生产者」成为所有 JVM 框架共享的底层语言，而不是各家各写的私有协议。

三、全栈响应式与混合模型

「全栈响应式」指契约从浏览器 RxJS、Svelte 绑定，延伸到 R2DBC、MongoDB Reactive Driver、AWS IoT MQTT、Azure IAsyncEnumerable 触发器——流成为端到端数据契约。

Project Loom 虚拟线程则带来新讨论：Mono.fromCallable(() -> blockingIo()) 在轻量线程下是否仍「罪恶」。趋势是混合执行模型：CPU 密集走并行流，I/O 密集走非阻塞流，运行时按负载编排。

// 混合模型示例：I/O 密集走非阻塞流，CPU 密集段用并行
Flux.fromIterable(userIds)
    .flatMap(id -> reactiveUserRepo.findById(id), 32)   // 非阻塞 I/O
    .parallel(4)                                          // CPU 密集并行
    .runOn(Schedulers.parallel())
    .map(this::computeRiskScore)                          // 纯计算
    .sequential();
​

这段代码展示的是 2023 年之后的真实生态：没有人再追求「全线响应式」，而是在资源错配点引入响应式。阻塞 JDBC 仍是很多系统的现实约束，此时用 boundedElastic 隔离而不是硬塞进 EventLoop；CPU 密集计算用并行流而不是伪装成异步；只有真正的 I/O 等待才值得走非阻塞链。Loom 出现后，Thread 变得廉价，「一个请求一个虚拟线程」重新具备竞争力——但背压与组合的价值不会消失，虚拟线程解决的是「线程资源」，响应式解决的是「组合与流量控制」，两者走向融合而非替代。

四、版本化进程：从「框架特性」到「平台义务」

回看时间线可以发现一个清晰的演进规律：响应式的能力逐级下沉——从学术概念（FRP）到框架特性（Rx），再到跨框架标准（Reactive Streams），最终进入平台标准库（Java 9 Flow）。每一次下沉都意味着「更底层的承诺」：

这种下沉带来两个实际好处。第一，投资保护：基于 Reactive Streams 写的一次性代码可以跨框架移植——今天用 Reactor，明天换 Vert.x，核心链路不变。第二，心智统一：新人只要学一遍四接口契约，就能读懂任何 JVM 响应式框架的文档。代价则是——标准往往落后于框架的创新速度，框架的先锋特性（如 Reactor 的 context 传播）要等标准跟进。理解这个张力，你就明白为什么有些 API 在框架里已经「无处不在」，却在规范里还没有正式条文。

// Java 9 Flow 已经把「订阅」写进标准库
SubmissionPublisher<String> publisher = new SubmissionPublisher<>();
publisher.subscribe(new Flow.Subscriber<>() {
    private Flow.Subscription subscription;
    @Override public void onSubscribe(Flow.Subscription s) {
        this.subscription = s;
        s.request(Long.MAX_VALUE);
    }
    @Override public void onNext(String item) { System.out.println(item); }
    @Override public void onError(Throwable t) { t.printStackTrace(); }
    @Override public void onComplete() { System.out.println("done"); }
});
publisher.submit("hello");
publisher.close();
​

这段代码不依赖任何第三方库——Flow 从 Java 9 起就是 java.base 的一部分。它验证了 1.3 的核心论点：响应式的「订阅-请求-推送-终止」模型，已经从第三方库的私有 API 上升为 JVM 平台的语言级保证。学习响应式时不必迷信框架，标准库里的这份最小实现足以让你把四接口的原型跑通。

本节速览

• FRP 提供数学地基，Rx 提供工业入口，Reactive Streams 提供互操作
• Manifesto 定原则，Flow API 定平台
• 今日重点在系统契约，不仅是 UI 事件

三条结论分别对应三种贡献者：学术给出了时间模型（Behavior/Event），工业给出了落地实现（Rx 家族）与互操作标准（Reactive Streams），平台给出了标准库承诺（Java 9 Flow）。今天学习响应式，你已经站在这三层成果之上——不必重新发明语义，但需要知道每一层解决什么、边界在哪。

第 2 章进入运行时：Publisher/Subscriber、Scheduler 与背压机制。