Spring Boot 2. 异步 API。 CompletableFuture 与 Reactive

Question

我的应用程序严重依赖异步 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。

不用说，我对整个反应式范式不熟悉。

我想听听你的意见。

Answer 1

我有两件事要说：

问：有没有一个例子，如何将基于 CompletableFuture 的 async API 转换为 Mono\\Flux？

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

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

Answer 2

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

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

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

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