用于切换服务器的反应式 Webflux - 有好处吗？

Question

我们需要实现一个简单的切换服务器（其余应用程序），该服务器将获取切换名称并在启用或禁用时返回。我们预计每天会有数十万个请求的负载。

Spring（反应式）webflux 在这里有意义吗？

我的理解是，如果 http 线程有任何空闲时间的可能性，反应式休息 api 将很有用 - 这意味着线程等待完成某些工作，并且在收到来自数据库读取或休息调用的响应之前无法继续进行其他服务。

我们的用例只是返回正在查询的切换值（可能来自某些缓存）。反应式休息服务对我们的情况有用吗？与简单的 Spring Boot 应用程序相比，它有什么优势吗？

Answer 1

我来自“传统”spring/spring-mvc 应用程序开发经验的背景，这些天我也开始学习 spring webflux，并且根据问题中提供的数据，这里是我的观察（免责声明：因为我正如我所说，我是这个领域的初学者，对此答案持保留态度）：

1. 与传统应用程序相比，WebFlux 的实施不太“直接”：维护成本更高、调试更困难等。

2. 如果您的操作受 I/O 限制，WebFlux 将会大放异彩。如果您要从内存缓存中读取数据 - 这不是 I/O 绑定操作。我还理解“切换”数据的本质是它不会改变那么多，但会被频繁访问（读取），因此将其保留在某些内存缓存中确实有意义，除非您构建了一些巨大的东西，而这些数据不会完全符合记忆，但这是一个不同的故事。

3. WebFlux + netty 可以让你同时服务数千个请求，tomcat 具有传统的“每个请求一个线程”模型，默认情况下仍然允许队列中有 200 个线程 + 100 个，如果超过这些值就会失败，但 netty 会“存活”。根据问题中提供的数据，我认为您不会从 netty 中受益。每天数十个数千个请求似乎任何类型的服务器都可以轻松处理，tomcat、jetty 等等 - 您在这里不需要那种“高负载”。

4. 正如我在第“3”项中提到的，WebFlux 在并发请求处理方面表现出色，但与传统方法相比，您可能不会获得任何性能改进，这与速度无关，而是与更好的资源利用率有关。

5. 如果您要从数据库读取数据并且确实想使用 webflux，请确保您的数据库确实有反应式驱动程序 - 当您运行流程时，您应该一直“反应式”，阻塞数据库访问没有意义。

所以，底线是，如果我是你，我会从常规服务器开始，并考虑稍后转向反应式堆栈（只要问题中指定的期望不改变，这个“稍后”可能永远不会到来）。