java - 用于切换服务器的响应式(Reactive) Webflux - 有好处吗？

Question

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

Spring(响应式(Reactive))webflux 在这里有意义吗？

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

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

Answer 1

我有“传统”spring/spring-mvc应用程序开发经验，这些天我也开始学习spring webflux，根据问题中提供的数据，这是我的观察结果(免责声明) :正如我所说，因为我是这个领域的初学者，所以对这个答案持保留态度):

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

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

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

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

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

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