Java SpringDoc WebMvc与WebFlux

我正在使用SpringDocOpenAPI3作为RESTAPI。现在我正在使用WebMvc版本。切换到WebFlux版本有什么好处吗？在客户端使用WebClient（或其他异步客户端）不是一回事吗，只是异步会发生在客户端？最终，Rest方法可以在内部使用异步方法，但尝试看看是否值得将公开的方法迁移到WebFlux。

不，这是完全不同的事情。SpringMVC在每个请求的线程模型中运行。您有100个并发请求=您有100个线程来处理这些请求。100个线程已经很多了，现在想象一下1k、10k甚至100k——在这个模型中完全不可能

关键是这些线程并不是100%都在工作。如果您调用数据库或其他服务，那么线程只是在等待响应，而没有完成它在这段时间内可能正在做的工作

这就是Webflux的方式，使用更少的线程，因为线程不是等待外部服务的响应，而是在这段时间内工作，从而可以处理1k并发请求，而不会产生太多问题

---

那么为什么每个人都不这么做：使用的资源更少，性能更好等等。？首先，我认为最重要的是——这是难以置信的困难。程序流不像同步编程那么容易，调试非常困难，堆栈跟踪基本上变得无用，您需要非常小心，不要阻止所有内容。第二，好处在某种程度上是值得的，大多数应用不需要处理成千上万的并发用户。在这一阈值之前，不仅没有任何好处，而且在性能方面可能更糟，同时要为第一点中提到的开发人员知识和经验付出代价。第三，要实现这一点，您需要整个流程都是异步的，否则您只会阻塞事件循环——对外部服务的调用，最重要的是对数据库的调用——您需要异步数据库驱动程序，而不是每个数据库都支持它。

OP讨论的是从组件测试中使用API，不是控制器的实现。@chrylis小心光学-不，我是问控制器的实现。我在问，作为Webflux实现控制器与在客户端使用WebClient是否存在差异。@Shadov感谢您清理了服务器端的线程模型。那么您建议切换到Webflux的每分钟请求速率是多少？从您的描述来看，这听起来像是一个很低的门槛，在这里它成为了一个优势。@Shadov一直在做一些研究，似乎mssql的反应驱动程序非常原始。