java - 用于内部微服务调用的消息总线与 Quasar/HTTP

Question

我希望优化目前使用 HTTP/REST 进行内部节点到节点通信的微服务架构。

一种选择是在服务中实现背压功能，(例如)通过将 Quasar 之类的东西集成到堆栈中。这无疑会改善情况。但我看到了一些挑战。一是，异步客户端线程是暂时的(在内存中)并且在客户端失败(崩溃)时，这些重试线程将丢失。第二，理论上，如果目标服务器停机一段时间，客户端最终可能会出现 OOM 尝试重试，因为线程最终是有限的，即使是 Quasar Fibers。

我知道这有点偏执，但我想知道基于队列的替代方案在非常大规模的情况下是否会更有优势。

它仍然会像 Quasar/fibers 一样异步工作，除了 a) 队列是集中管理的并且脱离了客户端 JVM，并且 b) 队列可以是持久的，所以在客户端和/或目标服务器出现故障的情况下，不在飞行中消息丢失。

队列的缺点当然是有更多的跃点并且会减慢系统速度。但我认为可能存在一个最佳点，此时 Quasar ROI 达到峰值，并且集中且持久的队列对于扩展和 HA 变得更加关键。

我的问题是:

Has this tradeoff been discussed? Are there any papers on using a centralized external queue / router approach for intraservice communication.

TL;DR; 我刚刚意识到我可以将这个问题表述为:

"When is it appropriate to use Message Bus based intraservice communication as opposed to direct HTTP within a microservice architecture."

Answer 1

在大规模运行时，我已经看到三种微服务架构的通用协议(protocol)设计模式:

1. 消息总线架构，使用 ActiveMQ 或 Apache Qpid 等中央代理。
2. “弹性”HTTP，其中一些额外的逻辑构建在 HTTP 上以使其更具弹性。这里的典型方法是 Hystrix (Java) 或 SmartStack/Baker St(智能代理)。
3. 使用 NSQ、ZMQ 或 Qpid Proton 之类的点对点异步消息传递。

到目前为止，最常见的设计模式是#2，当需要队列时会混入一点#1。

理论上，#3 提供了两全其美(弹性、规模和性能)，但技术都不太成熟。事实证明，使用 #2 你可以走得很远(例如，Netflix 到处都使用 Hystrix)。

为了直接回答您的问题，我会说 #1 很少用作独占设计模式，因为它会为您的整个系统造成单一瓶颈。 #1 对于系统的一个子集是常见的。对于大多数人，我今天推荐 #2。