历史的巧合：WebFlux 为何选择了复杂的响应式编程？

最近，Spring WebFlux 这个框架的热度越来越高。据说它可以构建出百万并发的高性能应用。很多新的项目，比如 Spring AI，主推的就是 Spring WebFlux，而不是经典的 Spring MVC。

但是当你用上 Spring WebFlux，却发现它必须搭配 Mono 和 Flux 这样的写法，还总是有一些奇奇怪怪的报错。你查了资料，原来这叫做响应式编程，这是一个新鲜的东西，看起来非常的酷炫，但是学起来却总是云里雾里。

这不禁让人产生一个巨大的疑问：为什么我想写一个高性能应用，必须搭配这样一个复杂难懂的编程范式？

如果你也有这样的疑问，请跟随本文一起探寻 WebFlux 的诞生之谜。我们将穿越回 Spring WebFlux 诞生的十字路口，探究 Java 语言发展的得与失，以及 WebFlux 的工程选择。

响应式编程的复杂性

响应式编程是一种听起来美好，但是用起来十分复杂的编程范式。

当你查询响应式编程的概念，回发现它是一种面向异步数据流的声明式编程范式。你可以把它想象成一条高度自动化的「数据流水线」。在这条流水线上，数据不是一坨一坨地处理，而是一个一个地流动。

响应式编程在 Java 语言中的实现是 Project Reactor，这也是 WebFlux 的核心依赖。它提供了两个强大的流水线传送带：Mono 用于传送 0 或 1 个数据，Flux 用于传送 0 到 N 个数据。

你可以在流水线上设置各种工作站，也就是操作符，如 map, flatMap，以声明式的方式对流过的数据进行转换、过滤和组合。这个流水线还有一个非常关键的背压机制。如果下游的处理速度跟不上了，它可以反过来控制上游的输出速度，从而保证系统在高压下不被冲垮。

一切听起来都很美好，对吗？但这种美好是有代价的。你在尝试 WebFlux 的时候，是不是遇到过这样的烦恼：

• 想写个简单的业务逻辑，却要跟 Mono 和 Flux 缠斗半天，感觉杀鸡用上了宰牛刀。
• 一个简单的调用链，被 map 和 flatMap 套了一层又一层，过了两个礼拜，已经看不懂自己写的代码了。
• 好不容易跑起来了，一遇到 bug，看着那长得没谱的堆栈信息，想找到根源，简直比登天还难。

不过，最致命的问题还是「函数染色」。

响应式代码具有强烈的传染性。一旦你的某个方法返回了 Mono 或 Flux，那么调用它的方法、以及调用调用者的所有方法，都必须被迫变成响应式的。这条颜色链会一直蔓延到你的代码库的每个角落，你需要使用响应式的数据库驱动 R2DBC、响应式的 WebClient，而不能再使用我们熟悉的 JDBC 和 RestTemplate。这给项目带来了巨大的上手和维护成本。

为什么 Spring WebFlux 会出现？

既然响应式编程如此复杂，那为什么还要有 Spring WebFlux 呢？答案很简单：Spring MVC 真的很难顶得住高并发场景，面对新的挑战，Java 需要一个新的 Web 框架。

经典的 Spring MVC 构建于一个简单直观的模型之上，也就是「一个请求一个线程」。每当一个用户请求进来，Tomcat 等 Servlet 容器就会从线程池里拿出一个线程，专门为这个请求服务。这个模型直观简单，请求线程跟操作系统的线程绑定，运行十分稳定。

但随着微服务和云原生应用的兴起，我们需要同时处理成千上万甚至更多的并发连接。这时，Spring MVC 的阻塞式 I/O 就暴露了它的致命缺陷。当代码执行 I/O 操作（比如查询数据库或调用 API）时，当前线程就会被阻塞。成千上万的阻塞线程，造成了巨大的资源浪费，服务器的性能很快就达到了瓶颈。

Spring WebFlux 的诞生，正是为了打破这种「一个请求一个线程」的工作模式，用少量的线程支持大量的用户请求。

Spring WebFlux 的核心理念借鉴了 Node.js 的事件循环模型。Node.js 是一个非常创新的发明，它用单个线程支撑所有的并发请求，通过非阻塞 I/O 可以实现极高的资源效率。WebFlux 吸收了这一理念，但把单线程扩展成了多线程事件循环，能更好地利用现代服务器的多核 CPU。

Spring WebFlux 的底层，则是用了高性能 Web 服务期 Netty。Netty 是 Java 世界高性能异步网络编程的事实标准。它提供了构建事件循环所需的一切底层工具。但是 Netty 的 API 过于底层，直接使用 Netty 开发效率很低。WebFlux 巧妙地将这个强大的引擎包装起来，提供了一套更友好的上层 API，让开发者可以专注于业务逻辑，而无需关心底层的网络细节。

历史的十字路口：WebFlux 为何选择了响应式编程

WebFlux 借鉴了 Node.js 的思想，底层使用了 Netty，现在万事俱备，只欠东风：能将这一切优雅地粘合起来的编程模型。然而不幸的是，Java 的语言能力在当时反而成了拖后腿的那个。

让我们回顾历史时间线，看看 Spring 团队在那个关键的十字路口上，究竟该如何选择。

纵向来看，Java 自身正在缓慢进化：

• 2013 年： Netflix 发布的 RxJava 将响应式编程的理念带入主流 Java 社区。它虽然强大，但诞生于 Java 8 之前，缺少 Lambda 表达式的支持，语法较为繁琐。
• 2014 年： Java 8 发布，带来了 Lambda 表达式。Java 补全了一个非常重要的现代语言特性，这简化了很多库和框架的写法。
• 2015 年： 响应式流规范（Reactive Streams）正式发布。这为 JVM 上的异步流处理提供了一个统一的标准，但它只是一个接口规范，不是具体的实现。
• 2016 年： Project Reactor 项目发布了关键的 2.0 版本，它完全遵循了响应式流规范，并为即将到来的 Spring 5 和 WebFlux 奠定了坚实的基础。

然而，Java 语言一直缺少一个关键的特性：协程（用户级线程）。Java 的虚拟线程（Project Loom）直到 2023 年的 Java 21 才正式发布。

横向对比其他语言，协程能力早已百花齐放：

• Go： 早在 2012 年发布的 Go 1.0 就已内置了 Goroutine。到了 2016 年，它已经成为构建高并发服务的成熟方案。Goroutine 的写法非常简便，开发者只需要用同步的方式写代码，就可以获得强大的异步执行效果。
• Node.js： 长期被「回调地狱」困扰的 Node.js 社区，在 2017 年初终于迎来了 async/await 语法的正式落地。这在语言层面极大地简化了异步代码的编写。
• Kotlin： 作为一个 JVM 上的新兴语言，Kotlin 在 2017 年 3 月也将协程作为实验性功能引入。它预示了 JVM 生态内部对更优并发模型的探索已经开始。

现在，我们来看看 Spring 团队当时面临的局面。他们面前摆着三个清晰的事实：

1. 问题已明确： Spring MVC 的阻塞模型在高并发下有严重的伸缩性瓶颈。
2. 底层方案已存在： Netty 可以解决问题，但它太复杂，必须在它之上构建一个现代化的 Web 框架。
3. 语言级异步能力不足： Java 自身既没有 Go 那样透明的协程，也没有 async/await 这样的语法糖。如果直接让开发者手写回调函数，无异于自掘坟墓。

在这样的约束条件下，Spring 团队的选择变得异常清晰。他们需要一种既能组织异步逻辑，又能避免回调地狱，还足够健壮的方案。

放眼望去，那个刚刚在 2015 年标准化的响应式流规范，以及其实现库 Project Reactor，成为了当时唯一合理且功能完备的选择。它不仅通过链式调用解决了回调地狱，更带来了一整套强大的、带背压的流处理方案。

这正是 WebFlux 诞生的核心逻辑。它本质上是一个「框架级垫片」。当语言层面缺乏某项关键能力时，框架就会挺身而出，模拟出这种能力。WebFlux 正是通过框架的复杂性，填补了 JVM 在轻量级并发能力上的缺失。

协程，Java 的阿喀琉斯之踵

那么，Java 缺失的这个协程能力，为什么会造成如此大的影响？让我们对比我们需要看看其他语言的方案，以及 Java 当时的处境。

理想的协程实现：Goroutine

Go 语言从诞生之初就内置了 Goroutine 这一大杀器。它允许开发者用最简单、最直观的同步阻塞式代码，来获得异步非阻塞的性能。开发者无需关心线程切换和回调，只需像写普通代码一样，就能写出高并发程序。这是无数 Java 开发者梦寐以求的理想模型。

Goroutine 也被称为有栈协程。每一个 Goroutine 都拥有自己独立的、小巧的、且可以动态增长的栈空间。Go 的运行时调度器负责管理 Goroutine 的上下文，并巧妙地将大量的 Goroutine 在少量的物理线程间进行调度。这一切对开发者完全透明，从而实现了用同步代码写异步逻辑的魔法。

退而求其次的协程模型：async/await

像 JavaScript 和 Python 等语言，则提供了 async/await 语法能力。虽然它也存在函数染色、堆栈信息不友好等问题，但它至少让开发者可以用一种看似同步的方式来编写异步代码，极大地改善了开发体验。

async/await 也被称为无栈协程。它其实是一种语法糖，把 Promise 转换成类似同步的写法。编译器负责把不同的 async 函数编织起来。因此，async/await 在运行时并不存在真正的调用栈。这就是为什么 async 关键字会染色整个调用链，因为编译器需要这种明确的信息来进行转换。

Java 当时的处境

为什么 Java 的协程在当时没有出现？这背后是沉重的历史和技术包袱。Java 从诞生之初就做出了一个影响深远的设计决策：将 java.lang.Thread 与操作系统的内核线程进行一对一的深度绑定。这个模型在当时提供了极佳的稳定性和简单的并发心智模型，但也意味着，Java 的整个并发体系，包括内存模型、synchronized 关键字、JNI（本地方法接口）等，都是围绕着这个重量级的内核线程构建的。

想要在这个根基之上引入轻量级的用户态协程，无异于对 JVM 进行一场伤筋动骨的“心脏搭桥手术”。这需要重写调度器、改造内存管理、处理与本地代码的交互，工程量极其浩大。Java 社区对稳定性和向后兼容性的极致追求，也决定了这种根本性的变革必须经过漫长而审慎的研究与开发，也就是后来的 Project Loom。

而缺少语言的协程支持，也让 Java 开发者陷入了一个痛苦的两难困境：

• A. 简单但低效： 坚守 Spring MVC，代码简单，但应用的性能上限不高。
• B. 高效但复杂： 拥抱 Spring WebFlux，可以支持高并发，但要承受响应式编程带来的所有复杂性。

这正是 Java 当时最大的痛点，也让很多系统开始寻求 Java 以外的解法。

回望历史，走向未来

现在，我们可以回答最初的那个问题了。

WebFlux 选择响应式编程，并非因为它本身是编程的终点，而是因为在通往高效并发的道路上，在那个特定的历史时期，这是 Spring 团队唯一能走通的路。 它是一个在平台能力受限的情况下，设计出的卓越的、但充满妥协的解决方案。

而历史的车轮滚滚向前，Java 终于迎来了自己的答案，那就是 Java 21 的虚拟线程。

Java 的虚拟线程非常类似于 Goroutine。它的出现，让传统的 Spring MVC 应用几乎只需一个配置开关，就能「免费」获得大规模并发的能力，而无需对代码做任何大的改动。它从 JVM 层面，彻底解决了那个困扰 Java 开发者近十年的核心矛盾。

这恰恰反向印证了我们的论点。当语言补齐了自身的短板，那个为规避短板而生的框架层方案，其存在的必要性也就降低了。Spring WebFlux 这个框架最终会回归到了它更应该专注的领域，也就是真正的流式处理和事件驱动架构。

对于绝大多数 Java 开发者而言，那个在简单和高效之间艰难抉择的时代，已经结束了。