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

Question

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

一种选择是在服务中实现背压功能,(例如)通过将类似Quasar的东西集成到堆栈中.这无疑会改善一切.但我看到了几个挑战.一个是,异步客户端线程是瞬态的(在内存中),在客户端故障(崩溃)时,这些重试线程将丢失.第二,理论上,如果目标服务器停机一段时间,客户端最终可能会尝试重试OOM,因为线程最终受到限制,甚至是Quasar Fibers.

我知道这有点偏执,但我想知道基于队列的替代方案是否会在非常大的范围内更有利.

它仍然像Quasar /光纤一样异步工作,除了a)队列是集中管理的并且离开客户端JVM,以及b)队列可以是持久的,因此在客户端和/或目标服务器发生故障的情况下,没有在线消息迷路了.

排队的缺点当然是有更多的跳跃,它会减慢系统的速度.但我认为Quasar ROI可能达到峰值,而集中且持久的队列对于扩展和HA来说更为关键.

我的问题是:

是否讨论了这种权衡？是否有任何关于使用集中式外部队列/路由器方法进行内部服务通信的文章.

TL; DR; 我刚才意识到我可以将这个问题说成:

"什么时候使用基于消息总线的内部服务通信,而不是微服务架构中的直接HTTP."

Answer 1

我在大规模运行时看到了三种具有微服务架构的通用协议设计模式:

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.