WebFlux 在这样的架构中会不会有瓶颈？

Will WebFlux have any bottlenecks in such architecture?

我们目前即将从单体设计迁移到微服务架构，尝试选择最好的方式将JAX-WS替换为RESTful并考虑使用Spring WebFlux。

我们目前在 Tomcat EE 处部署了一个 JAX-WS 端点，用于处理来自第三方客户端的请求。 Web 服务端点对数据库进行长 运行 阻塞调用，然后使用从数据库 (Oracle) 检索到的数据向客户端发送 SOAP 响应。

Oracle DB 将很快被 NoSQL 数据库之一取代（可能是 MongoDB）。由于 MongoDB 支持异步调用，我们正在考虑用基于 WebFlux.

公开 REST 端点的微服务替代当前实现

我们在峰值时大约有 2500 req/sec，因此当前终点通常会下降 OutOfMemoryError。这是促使我们迁移的根本原因。

我的想法是创建一个非阻塞端点，它将以异步方式调用 MongoDB 并向客户端发送 REST 响应。因此，考虑到 WebFlux 提供的基本功能，我有几个问题：

  1. 就我而言，有一个内置的背压控制 WebFlux 中的业务级别（不是 TCP 流量控制）并且有效 通常通过 Reactive Streams。由于我们的客户不是 反应性，这是否意味着这种背压控制方式是 此处无法实施？

  2. 假设对新数据库的调用在新数据库中仍然很长-运行 建筑学。因为 Netty 使用 EventLoop 服务传入 请求，微服务是否有可能出现这种情况 接受所有传入的 HTTP 连接，调用异步调用 db 并将结果 Mono 订阅到调度程序，但是，因为 请求量持续爆发式增长，应用不断 在 scheduler 池中创建新的 workers 崩溃？这是现实场景吗？

  3. 假设对数据库的调用保持同步。有没有 使用 WebFlux 以微服务的方式处理它们 在负载下仍可访问吗？

  4. 这样的设计有哪些瓶颈？做这个解决方案 看起来够用吗？

  5. Netty（或Reactor-Netty，或其他）是否有工具来限制 同时处理的请求数量？说我会限制 服务不超过 100 个并行请求的端点并跳过 所有高于该点的请求，都可以吗？

  6. 假设我将创建大量的异步线程（或 可能是同步）对 DB 的调用。断点在哪里 应用程序将崩溃或停止响应传入 HTTP 请求？那里会发生什么 - 我们会 运行 内存不足 或者..?

最后，在我们的试点项目中，没有任何关于性能的重大问题。但不幸的是，我们没有考虑到一些特定的 Linux（以及 OpenShift）TCP 调整道具。

它们可能会显着影响整体性能，在我们的案例中，我们在调整后获得了大约 10 倍的请求。

所以要注意net.core.somaxconn等相关参数。 我总结了我们在 article.

方面的专业知识