Spring Boot 2. 异步 API。 CompletableFuture vs. Reactive

Posted 2023-02-27

【中文标题】Spring Boot 2. 异步 API。 CompletableFuture vs. Reactive

【英文标题】：Spring Boot 2. Async API. CompletableFuture vs. Reactive

【发布时间】：2019-01-09 12:06:54

【问题描述】：

我的应用程序严重依赖异步 Web 服务。 它是用 spring boot 1.5.x 构建的，它允许我使用标准 Java 8 CompletableFuture<T> 来产生延迟的异步响应。有关更多信息，请参阅 https://nickebbitt.github.io/blog/2017/03/22/async-web-service-using-completable-future

Spring boot 2.0.x 现在带有可以利用响应式范例的启动包。 Spring WebFlux 是实现响应式 HTTP 的框架。

既然我已经按照第一段中的描述实现了我的 API，那么通过重做我的服务以使用非阻塞响应式方法，我会获得很多收益吗？简而言之，我也会有非阻塞 API，对吧？

有没有示例如何将基于CompletableFuture<T> 的异步API 转换为Mono<T>\Flux<T>？

我正在考虑完全摆脱基于 servlet 的服务器（在我的例子中是 Jetty）并使用 Netty + Reactor。

不用说，我对整个反应式范式是新手。

我想听听您的意见。

【问题讨论】：

我看不出有什么好处。所以我建议你保留它。

【参考方案1】：

至于问题：“通过重做我的服务以使用非阻塞反应式方法，我会获得很多收益吗”。文档中提供了一般答案：https://docs.spring.io/spring-framework/docs/current/reference/html/web-reactive.html#webflux-performance .. 不是。

性能有很多特点和含义。反应式和非阻塞通常不会使应用程序运行得更快。在某些情况下，它们可以（例如，如果使用 WebClient 并行运行远程调用）。总体而言，以非阻塞方式做事需要更多的工作，这会略微增加所需的处理时间。

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

这是一般答案，但具体情况取决于您必须衡量和查看。我将首先重新创建应用程序的一个简单部分，然后在隔离环境中检查两者的性能。

【参考方案2】：

我有两件事要说：

问：有没有示例如何将基于 CompletableFuture 的异步 API 转换为 Mono\Flux？

答： 1）您必须以不同的方式配置端点https://docs.spring.io/spring/docs/current/spring-framework-reference/web-reactive.html

2) CompletableFuture 到 Mono\Flux 示例：Mono.fromFuture(...)

【讨论】：

这是一个迟到的答案，但只是为了记录***.com/questions/49203360/…