Spring MVC 到 Spring Webflux 迁移 - 阻止与订阅

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

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

鉴于您的目标是使用 Webflux，最终的首选方式是在您的反应链上以整个方式处理这些发布者。这意味着您最终不会直接调用 subscribe 任何东西，因为您的控制器本身将返回一个 Mono （并且所有内容，包括 WebClient 调用，都将通过一系列反应性操作合并到 Mono在链中。）

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

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

一旦您将越来越多的堆栈迁移到响应式，您就可以以响应式的方式做越来越多的事情，然后开始“移动”您的 block() 调用，从而进一步向上链（直到块在控制器级别，然后您可以切换到返回Mono。）

另外，通过订阅，我们是否需要处理 Disposable

仅当您可能需要取消订阅者（并且它支持它）时。根据我的经验，这种情况非常罕见。

还有一个关于 JDBC 的问题。使用Schedulers.boundedElastic()有多危险？

boundedElastic() 被设计为阻塞 IO 的包装器，因此在反应器端使用它本身并没有错。唯一的“危险”在于 JDBC / 应用程序是否符合您的要求：

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

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

如果应用程序使用 Tomcat 会怎样？ Tomcat默认有更多线程，情况会更好吗？

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