2

我正在寻找优化当前使用 HTTP/REST 进行内部节点到节点通信的微服务架构。

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

我知道这有点偏执，但我想知道基于队列的替代方案在非常大的规模上是否更有利。

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

当然，排队的缺点是有更多的跃点，它会减慢系统的速度。但我认为可能存在一个甜蜜点，即 Quasar ROI 达到峰值，集中且持久的队列对于扩展和 HA 变得更加重要。

我的问题是：

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

TL;博士; 我刚刚意识到我可以将这个问题表述为：

“什么时候适合在微服务架构中使用基于消息总线的服务内通信而不是直接 HTTP。”

4

1 回答 1

5

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

  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。

于 2015-08-13T13:31:13.880 回答