我希望优化当前使用HTTP / REST进行内部节点到节点通信的微服务架构。
一种选择是在服务中实现背压功能，（例如）通过将类似Quasar的东西集成到堆栈中。这无疑会改善一切。但我看到了几个挑战。一个是，异步客户端线程是瞬态的（在内存中），在客户端故障（崩溃）时，这些重试线程将丢失。第二，理论上，如果目标服务器停机一段时间，客户端最终可能会尝试重试OOM，因为线程最终受限，甚至是Quasar Fibers。
我知道这有点偏执，但我想知道基于队列的替代方案是否会在非常大的范围内更有利。
它仍然可以像Quasar /光纤一样异步工作，除了a）队列是集中管理的并且离开客户端JVM，以及b）队列可以是持久的，因此在客户端和/或目标服务器发生故障的情况下，在飞行中消息丢失。
排队的缺点当然是有更多的跳跃并且它会降低系统速度。但是我认为Quasar投资回报率可能达到最高点，而且集中且持久的队列对于扩展和HA来说更为关键。
我的问题是：
是否讨论了这种权衡？有没有关于使用a的论文？ 用于内部服务的集中式外部队列/路由器方法 通信。
TL; DR; 我刚才意识到我可能会将这个问题说成：
＆＃34;何时适合使用基于消息总线的内部服务 与微服务中的直接HTTP相反的通信 。架构＆＃34;
答案 0 :(得分：5)
我在大规模运行时看到了三种具有微服务架构的通用协议设计模式：
到目前为止，最常见的设计模式是＃2，当需要队列时，混合了一点＃1。
从理论上讲，＃3提供了两全其美（弹性和规模和性能），但这些技术都有些不成熟。事实证明，对于＃2，你可以走得很远（例如，Netflix到处使用Hystrix）。
要直接回答您的问题，我会说＃1很少用作独家设计模式，因为它会为整个系统创建一个瓶颈。 ＃1对于系统的子集是常见的。对于大多数人来说，我今天建议＃2。