Spring Boot 2.异步API。CompletableFuture与反应式

Question

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

Spring boot 2.0.x现在附带了可以利用reactive范例的入门包。Spring是实现反应式WebFlux的框架。

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

有没有一个例子，如何将基于CompletableFuture<T>的异步API转换为Mono<T>\Flux<T>

我在考虑完全摆脱基于servlet的服务器(在我的例子中是Jetty)，转而使用Netty + Reactor。

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

我想听听你的意见。

Answer 1

我有两件事要说：

问:有没有一个例子可以把基于CompletableFuture的异步API转换成Mono\Flux？

答: 1)您必须使用与https://docs.spring.io/spring/docs/current/spring-framework-reference/web-reactive.html稍有不同的方式配置端点

2) CompletableFuture to Mono\Flux示例: Mono.fromFuture(...)

Answer 2

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

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

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

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