Spring MVC到Spring Webflux迁移-块与订阅

Question

让我们设想一个场景，其中有一个使用Servlet堆栈编写的旧应用程序，您决定将其迁移到Spring Webflux。我们还可以说，要迁移的第一件事是将RestTemplate迁移到WebClient。

什么是处理WebClient返回的Mono或Flux的首选方式？调用block似乎是可以的解决方案，因为应用程序使用RestTemboard无论如何都会阻塞。订阅应该更好一点，因为它有回调，但也许您必须等待才能继续。此外，使用订阅，我们是否需要处理Disposable，如果是，如何处理，因为我不确定在哪里是调用dispose的最佳位置？

还有一个关于JDBC的问题。使用Schedulers.boundedElastic（）有多危险？根据我的理解，拥有一个单独的线程池应该会有所帮助，尤其是在使用Netty的情况下。这并不理想，但在R2DBC驱动程序达到1.0.0之前，这可能是一个临时解决方案吗？如果应用程序使用Tomcat怎么办？因为Tomcat默认有更多线程，情况会更好吗？

Answer 1

处理WebClient返回的Mono或Flux的首选方式是什么？

鉴于您的目标是使用Webflow，最终首选的方法是在您的反应链的整个过程中与这些发布者打交道。这意味着您最终不会直接调用订阅任何内容，因为您的控制器本身将返回一个Mono（并且所有内容，包括WebClient调用，都将通过链中的一系列反应操作合并到该Mono中。）

然而，正如您所指出的，您不可能同时迁移所有内容。

如果现在只迁移网络客户端，那么只需调用block（），以与RestController相同的方式处理它。调用subscribe（）然后等待订阅完成没有任何好处，这只是一种不太明显、更冗长的阻塞方式。

一旦您将越来越多的堆栈迁移到反应式，您就可以以反应式的方式执行越来越多的操作，然后开始“移动”您的块（）调用，从而使调用链进一步向上移动（直到块处于控制器级别，然后您可以切换到返回单声道）

此外，使用subscribe，我们是否需要处理一次性

仅当您需要潜在地取消订阅服务器（并且它支持它）时这在我的经验中是很罕见的。

还有一个关于JDBC的问题。使用调度程序有多危险。boundedElastic（）？

boundedElastic（）被设计成一个用于阻塞IO的包装器，因此在Reactor侧使用它本身并没有什么问题。唯一的“危险”是JDBC/应用程序端是否符合您的要求：

• 它的上限是CPU内核数量的10倍
• 排队任务的数量上限为100K

如果您有足够长时间运行的DB查询，这还不够，那么您可以考虑使用newBoundedElastic（），并手动指定threadCap和queuedTaskCap。

如果应用程序使用Tomcat呢？由于Tomcat默认有更多的线程，情况会更好吗？

我不建议依赖它。Tomcat仍然每个请求使用一个线程（即使使用Webflux），因此存在的危险是，您最终会阻塞一个不应该阻塞的线程，并且最终没有意识到并依赖于该行为（当您切换到Netty时，这一切都会崩溃）