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

Question

让我们想象一个场景，其中有一个使用 Servlet 堆栈编写的旧应用程序，并且您决定将其迁移到 Spring Webflux。我们还假设首先要迁移的是 RestTemplate 到 WebClient。

处理 WebClient 返回的 Mono 或 Flux 的首选方式是什么？调用 block 似乎是不错的解决方案，因为应用程序使用 RestTemplate 无论如何都会阻塞。 subscribe 应该好一点，因为它有一个回调，但也许你必须等待才能继续。另外，对于 subscribe，我们是否需要处理 Disposable，如果需要，如何处理，因为我不确定在哪里调用 dispose 的最佳位置 就在上面吗？

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

Answer 1

What would be preferred way of handling Mono or Flux that WebClient returns?

鉴于您的目标是使用 Webflux，最终的首选方式是在您的 react 链上整个与这些发布者打交道。这意味着您最终不会直接对任何内容调用 subscribe，因为您的 Controller 本身将返回 Mono (并且所有内容，包括 WebClient 调用)都将被合并到通过链中的一系列 react 操作实现 Mono。)

但是，正如您所指出的，您实际上无法一次迁移所有内容。

如果您现在仅迁移 WebClient，则只需调用 block() 即可以与你的RestController。调用 subscribe() 然后等待订阅完成没有任何优势 - 这只是一种不太明显且更冗长的阻塞方式。

一旦您将越来越多的堆栈迁移到响应式，您就可以以响应式方式执行越来越多的操作，然后开始将您的 block() 调用进一步“移动”到链上，如下所示结果(直到该 block 位于 Controller 级别，然后您可以切换到返回 Mono。)

Also, with subscribe, do we need to handle a Disposable

仅当您需要潜在地取消订阅者(并且它支持它)时。根据我的经验，这种情况相当罕见。

And one more question regarding JDBC. How dangerous is to use Schedulers.boundedElastic()?

boundedElastic() 被设计为阻塞 IO 的包装器，因此在 react 器端使用它并没有本质上的错误。唯一的“危险”是在 JDBC/应用程序端，以确定它是否符合您的要求:

• 其上限为 CPU 核心数量的 10 倍
• “排队”任务的数量上限为 100K

如果您有足够长的运行时间的数据库查询，这还不够，那么您可以考虑使用 newBoundedElastic() 代替，并指定 threadCap 和 queuedTaskCap 手动。

What if app uses Tomcat? Is the situation better since Tomcat by default has more threads?

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