我的应用程序严重依赖异步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。
不用说我是整个反应式范式的新手。
我想听听您的意见。
答案 0 :(得分：0)
我有两句话要说：
问：有一个示例如何将基于CompletableFuture的异步API转换为Mono \ Flux？
A： 1）您必须以某种不同的方式配置端点https://docs.spring.io/spring/docs/current/spring-framework-reference/web-reactive.html
2）将CompletableFuture转换为Mono \ Flux，例如：Mono.fromFuture（...）
答案 1 :(得分：0)
至于问题：“通过重做我的服务以使用非阻塞响应式方法，我会获得很多好处吗”。文档中提供了一般答案：https://docs.spring.io/spring-framework/docs/current/reference/html/web-reactive.html#webflux-performance .. 并且它不是。
<块引用>性能有很多特点和意义。反应式和非阻塞通常不会使应用程序运行得更快。在某些情况下，它们可以（例如，如果使用 WebClient 并行运行远程调用）。整体而言，以非阻塞方式做事需要更多的工作，并且会稍微增加所需的处理时间。
反应式和非阻塞的主要预期好处是能够以固定数量的小线程和更少的内存进行扩展。这使得应用程序在负载下更具弹性，因为它们以更可预测的方式扩展。然而，为了观察这些好处，您需要有一些延迟（包括缓慢和不可预测的网络 I/O 的混合）。这就是反应式堆栈开始显示其优势的地方，而且差异可能是巨大的。
这是一般性答案，但具体情况将取决于您必须衡量并查看。我将首先重新创建应用程序的一个简单部分，并在隔离环境中检查两者的性能。