概述

为什么创建 Spring WebFlux？

部分原因在于需要一个非阻塞 Web 栈来使用少量线程处理并发并使用更少的硬件资源进行伸缩。Servlet 非阻塞 I/O 偏离了 Servlet API 的其余部分，其中契约是同步的 (Filter, Servlet) 或阻塞的 (getParameter, getPart)。这是创建新的通用 API 的动机，该 API 可作为所有非阻塞运行时的基础。这一点很重要，因为像 Netty 这样的服务器在异步、非阻塞领域已经很成熟。

另一部分原因在于函数式编程。正如 Java 5 中添加注解创造了机会（例如注解的 REST 控制器或单元测试）一样，Java 8 中添加 Lambda 表达式也为 Java 中的函数式 API 创造了机会。这对于非阻塞应用和延续风格的 API（由 CompletableFuture 和 ReactiveX 普及）来说是一个福音，它们允许对异步逻辑进行声明式组合。在编程模型层面，Java 8 使 Spring WebFlux 能够在注解控制器之外提供函数式 Web 端点。

定义“响应式”

我们谈到了“非阻塞”和“函数式”，但是响应式意味着什么？

术语“响应式”是指围绕响应变化而构建的编程模型——网络组件响应 I/O 事件，UI 控制器响应鼠标事件等等。从这个意义上说，非阻塞是响应式的，因为我们现在不是被阻塞，而是处于响应操作完成或数据可用通知的模式。

我们 Spring 团队认为与“响应式”相关的另一个重要机制是非阻塞背压。在同步的命令式代码中，阻塞调用充当了一种自然的背压形式，强制调用者等待。在非阻塞代码中，控制事件速率变得很重要，以便快速生产者不会压垮其目的地。

Reactive Streams 是一个小型规范（也在 Java 9 中采用），它定义了带背压的异步组件之间的交互。例如，数据仓库（充当 Publisher）可以生成数据，然后 HTTP 服务器（充当 Subscriber）可以将数据写入响应。Reactive Streams 的主要目的是让 Subscriber 控制 Publisher 生成数据的快慢。

常见问题：如果 Publisher 无法减速怎么办？
Reactive Streams 的目的仅在于建立机制和边界。如果 Publisher 无法减速，它必须决定是缓冲、丢弃还是失败。

响应式 API

Reactive Streams 在互操作性方面发挥着重要作用。它对库和基础设施组件有意义，但作为应用 API 用处较小，因为它层次太低。应用需要更高层、更丰富的函数式 API 来组合异步逻辑——类似于 Java 8 Stream API，但不仅限于集合。这是响应式库所扮演的角色。

Reactor 是 Spring WebFlux 的首选响应式库。它提供了 Mono 和 Flux API 类型，通过一组丰富的与 ReactiveX 运算符词汇表对齐的运算符来处理 0..1 (Mono) 和 0..N (Flux) 的数据序列。Reactor 是一个 Reactive Streams 库，因此其所有运算符都支持非阻塞背压。Reactor 强烈关注服务器端 Java。它与 Spring 紧密合作开发。

WebFlux 要求 Reactor 作为核心依赖，但它可以通过 Reactive Streams 与其他响应式库互操作。作为一般规则，WebFlux API 接受普通 Publisher 作为输入，在内部将其适配为 Reactor 类型，使用它，并返回 Flux 或 Mono 作为输出。因此，您可以将任何 Publisher 作为输入传递，并可以在输出上应用操作，但您需要将输出适配以与其他响应式库一起使用。在可行的情况下（例如，注解控制器），WebFlux 透明地适配 RxJava 或其他响应式库的使用。有关详细信息，请参阅响应式库。

除了响应式 API，WebFlux 还可以与 Kotlin 中的Coroutines API 一起使用，后者提供了更命令式的编程风格。以下 Kotlin 代码示例将使用 Coroutines API 提供。

编程模型

spring-web 模块包含 Spring WebFlux 的响应式基础，包括 HTTP 抽象、支持服务器的 Reactive Streams 适配器、编解码器以及与 Servlet API 类似但具有非阻塞契约的核心 WebHandler API。

在此基础上，Spring WebFlux 提供了两种编程模型选择

  • 注解控制器：与 Spring MVC 一致，基于 spring-web 模块中的相同注解。Spring MVC 和 WebFlux 控制器都支持响应式（Reactor 和 RxJava）返回类型，因此，很难区分它们。一个显着的区别是 WebFlux 还支持响应式的 @RequestBody 参数。

  • 函数式端点：基于 Lambda、轻量级的函数式编程模型。你可以将其视为一个小库或一组应用可以使用它来路由和处理请求的工具。与注解控制器的主要区别在于，应用负责从头到尾处理请求，而不是通过注解声明意图并被回调。

适用性

Spring MVC 还是 WebFlux？

这是一个很自然的问题，但它构建了一个不健全的二分法。实际上，两者协同工作以扩展可用选项的范围。两者在设计上相互连续和一致，它们可以并行使用，来自每一方的反馈都有益于双方。下图显示了两者如何关联、它们有哪些共同点以及各自唯一支持什么

spring mvc and webflux venn

我们建议您考虑以下具体要点

  • 如果您有一个运行良好的 Spring MVC 应用，则无需更改。命令式编程是编写、理解和调试代码最简单的方式。您拥有最大的库选择范围，因为从历史上看，大多数都是阻塞的。

  • 如果您正在寻找非阻塞 Web 栈，Spring WebFlux 提供了与该领域其他技术相同的执行模型优势，还提供了服务器选择（Netty、Tomcat、Jetty、Undertow 和 Servlet 容器）、编程模型选择（注解控制器和函数式 Web 端点）以及响应式库选择（Reactor、RxJava 或其他）。

  • 如果您对使用 Java 8 Lambda 或 Kotlin 的轻量级函数式 Web 框架感兴趣，您可以使用 Spring WebFlux 函数式 Web 端点。这对于需求不太复杂的小型应用或微服务来说也是一个不错的选择，可以从更高的透明度和控制中受益。

  • 在微服务架构中，您可以混合使用包含 Spring MVC 或 Spring WebFlux 控制器或 Spring WebFlux 函数式端点的应用。在两个框架中支持相同的基于注解的编程模型，可以在选择合适的工具完成合适的工作的同时，更容易复用知识。

  • 评估应用的一个简单方法是检查其依赖项。如果您有阻塞的持久化 API（JPA、JDBC）或网络 API 要使用，至少对于常见架构而言，Spring MVC 是最佳选择。使用 Reactor 和 RxJava 在单独的线程上执行阻塞调用在技术上是可行的，但您将无法充分利用非阻塞 Web 栈。

  • 如果您有一个调用远程服务的 Spring MVC 应用，尝试使用响应式 WebClient。您可以直接从 Spring MVC 控制器方法返回响应式类型（Reactor、RxJava 或其他）。每次调用的延迟或调用之间的相互依赖性越大，效益就越显着。Spring MVC 控制器也可以调用其他响应式组件。

  • 如果您的团队规模较大，请记住转向非阻塞、函数式和声明式编程的学习曲线很陡峭。在不完全切换的情况下开始的一个实用方法是使用响应式 WebClient。除此之外，从小处着手并衡量收益。我们预计，对于许多应用而言，这种转变是不必要的。如果您不确定要寻找哪些好处，可以先了解非阻塞 I/O 的工作原理（例如，单线程 Node.js 上的并发）及其影响。

服务器

Spring WebFlux 支持 Tomcat、Jetty、Servlet 容器以及 Netty 和 Undertow 等非 Servlet 运行时。所有服务器都适配到一个低级的通用 API，以便可以在不同服务器上支持更高级别的编程模型。

Spring WebFlux 没有内置的服务器启动或停止支持。然而，从 Spring 配置和 WebFlux 基础设施组装一个应用，并用几行代码运行它很容易。

Spring Boot 有一个 WebFlux starter，可以自动化这些步骤。默认情况下，该 starter 使用 Netty，但通过更改 Maven 或 Gradle 依赖项，可以轻松切换到 Tomcat、Jetty 或 Undertow。Spring Boot 默认使用 Netty，因为它在异步非阻塞领域更广泛使用，并且允许客户端和服务器共享资源。

Tomcat 和 Jetty 可以与 Spring MVC 和 WebFlux 一起使用。但请记住，它们的使用方式非常不同。Spring MVC 依赖于 Servlet 阻塞 I/O，如果需要，允许应用直接使用 Servlet API。Spring WebFlux 依赖于 Servlet 非阻塞 I/O，并在低级适配器后面使用 Servlet API。它不暴露用于直接使用。

强烈建议不要在 WebFlux 应用上下文中映射 Servlet 过滤器或直接操作 Servlet API。由于上述原因，在同一上下文中混合阻塞 I/O 和非阻塞 I/O 会导致运行时问题。

对于 Undertow，Spring WebFlux 直接使用 Undertow API，不使用 Servlet API。

性能

性能有许多特征和含义。响应式和非阻塞通常不会让应用运行得更快。在某些情况下可以实现——例如，如果使用 WebClient 并行运行远程调用。然而，以非阻塞方式做事需要更多工作，这可能会稍微增加所需的处理时间。

响应式和非阻塞的关键预期好处是能够使用少量固定数量的线程和更少的内存进行伸缩。这使得应用在负载下更具弹性，因为它们以更可预测的方式伸缩。然而，为了观察这些好处，您需要存在一些延迟（包括慢速和不可预测的网络 I/O 的混合）。在这里，响应式栈开始显示其优势，并且差异可能非常显着。

并发模型

Spring MVC 和 Spring WebFlux 都支持注解控制器，但在并发模型以及对阻塞和线程的默认假设方面存在关键差异。

在 Spring MVC（以及一般的 Servlet 应用）中，假设应用可以阻塞当前线程，例如，进行远程调用。因此，Servlet 容器使用大型线程池来吸收请求处理期间的潜在阻塞。

在 Spring WebFlux（以及一般的非阻塞服务器）中，假设应用不会阻塞。因此，非阻塞服务器使用少量固定大小的线程池（事件循环工作线程）来处理请求。

“伸缩”和“少量线程”可能听起来矛盾，但永远不阻塞当前线程（而是依赖回调）意味着您不需要额外的线程，因为没有要吸收的阻塞调用。

调用阻塞 API

如果确实需要使用阻塞库怎么办？Reactor 和 RxJava 都提供了 publishOn 运算符，用于在不同的线程上继续处理。这意味着有一个简单的逃生通道。但请记住，阻塞 API 不适合此并发模型。

可变状态

在 Reactor 和 RxJava 中，您通过运算符声明逻辑。在运行时，会形成一个响应式管道，数据在不同阶段顺序处理。这样做的一个关键好处是，它使应用无需保护可变状态，因为该管道中的应用代码永远不会并发调用。

线程模型

在运行 Spring WebFlux 的服务器上，您应该期望看到哪些线程？

  • 在“纯净的” Spring WebFlux 服务器上（例如，没有数据访问或其他可选依赖项），您可以期望一个服务器线程和几个用于请求处理的线程（通常与 CPU 核心数相同）。然而，Servlet 容器可能会启动更多线程（例如，Tomcat 上有 10 个），以支持 Servlet（阻塞）I/O 和 Servlet 3.1（非阻塞）I/O 使用。

  • 响应式 WebClient 以事件循环风格运行。因此，您可以看到与之相关的少量固定处理线程（例如，使用 Reactor Netty 连接器的 reactor-http-nio-）。然而，如果 Reactor Netty 用于客户端和服务器，两者默认共享事件循环资源。

  • Reactor 和 RxJava 提供了线程池抽象，称为调度器（schedulers），与 publishOn 操作符一起使用，后者用于将处理切换到不同的线程池。这些调度器的名称暗示了特定的并发策略——例如，“parallel”（用于 CPU 密集型工作，线程数有限）或“elastic”（用于 I/O 密集型工作，线程数较多）。如果你看到这样的线程，意味着某些代码正在使用特定的线程池 Scheduler 策略。

  • 数据访问库和其他第三方依赖项也可以创建和使用自己的线程。

配置

Spring Framework 不提供启动和停止服务器的支持。要配置服务器的线程模型，你需要使用服务器特定的配置 API，或者如果你使用 Spring Boot，请查阅 Spring Boot 对每种服务器的配置选项。你可以直接配置 WebClient。对于所有其他库，请参阅其各自的文档。