我正在寻求优化目前使用 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."
最佳答案
在大规模运行时，我见过三种具有微服务架构的通用协议(protocol)设计模式:
- 消息总线架构，使用 ActiveMQ 或 Apache Qpid 等中央代理。
- “弹性”HTTP，在 HTTP 上构建一些附加逻辑以使其更具弹性。这里的典型方法是 Hystrix (Java) 或 SmartStack/Baker St(智能代理)。
- 使用 NSQ、ZMQ 或 Qpid Proton 等方式进行点对点异步消息传递。
到目前为止，最常见的设计模式是#2，当需要队列时会混合一点#1。
理论上，#3 提供了两全其美的方法(弹性、规模和性能)，但技术都有些不成熟。事实证明，使用#2 你可以走得很远(例如，Netflix 到处都使用 Hystrix)。
为了直接回答你的问题，我想说 #1 很少用作专有设计模式，因为它为整个系统创建了一个瓶颈。 #1 对于系统的子集来说是常见的。对于大多数人来说，我今天推荐#2。
关于java - 内部微服务调用的消息总线与 Quasar/HTTP，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/31973473/