Spring MVC 到 Spring Webflux 的迁移——阻塞 vs 订阅

Question

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

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

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

Answer 1

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

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

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

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

一旦您将越来越多的堆栈迁移到反应式，您就可以以反应式的方式做越来越多的事情，然后开始将您的block()调用“移动”到链上（直到块处于控制器级别，并且然后你可以切换到返回Mono.)

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

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

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

boundedElastic()被设计成一个用于阻塞 IO 的包装器，所以在反应器端使用它并没有本质上的错误。唯一的“危险”是 JDBC / 应用程序方面是否符合您的要求：

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

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

如果应用程序使用Tomcat怎么办？情况是否更好，因为默认情况下 Tomcat 有更多线程？

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