微服务通信:避免单点故障

Question

据我所知，在处理微服务架构中的服务通信时，有两种常用的模式：

1. 直接打电话给其他服务。例如:服务A处理一些数据，然后它需要告诉服务B对该数据做一些事情。A知道B的S端点URL，并直接调用它。
2. 使用总线(通常是消息队列)来分派消息，这些消息将由单个微服务接收。例如：A将在公共队列上发送消息，B将接收消息并知道该做什么。

两者都有缺点：

• 直接调用其他服务会导致将服务与其他服务紧密耦合。如果更改服务B，则可能需要调整和重新部署与B交互的所有其他服务。
• 使用总线是很酷的，因为您不需要知道哪个服务能够处理请求，但是如果MQ由于任何原因而失败，它将成为整个系统的单一故障点。

那么，管理服务通信的首选方法是什么？

我们是否有其他方法可以减少故障，避免微服务之间的紧密耦合？

Answer 1

正如您正确地指出的，拥有一个专用于传递消息的组件肯定比让每个服务负责知道如何准确地到达所有协作服务要好。因此，消息队列、通信总线等是一个好主意。

如果它们变成了单一的失败点呢？好吧，您总是为了健壮和扩展而做的:部署消息队列的多个实例。如果你的环境不能保持他们的任何一个，很可能你不会完成任何有用的工作无论如何。问题解决了。

Answer 2

嗯，假设B服务失败了，没有响应。现在整个过程不能继续，因为它仍然依赖于B来完成它的部分工作。为什么B不是一个单一的失败点呢？

我所看到的公共总线(或调度器，或您拥有的任何东西)的优点是能够处理单个服务的停机时间，例如，队列仍然可以保留发送给B的消息，直到服务恢复并能够使用它们。

此外，保持一个单一的高度可用的系统的机会比不得不担心N个不同的系统与不同的所有者。

下面是一个马丁·福勒的有趣文章，它使用我认为可以使用的事件为微服务提供解决方案。

Answer 3

一个拓扑还是另一个拓扑是最好的，这在很大程度上取决于您的通信方式。

例如，如果您主要是通过不需要在服务之间进行广泛对话的自包含消息发送，则代理消息总线可以正常工作。如果消息需要到达多个服务，或者您不知道哪个服务接收消息，则尤其如此。可以使用群集代理设置来管理弹性，大多数流行的消息代理都可以处理这些设置。

然而，如果你是双向交流的话，点对点可能是最好的选择。如果您要在服务之间传输数据，这将是特别正确的。有各种缓解耦合的技术，例如使用发现服务来识别适当的合作伙伴。也有限制接口耦合的常用技术。例如，拥有一个类似REST的API，并使用可扩展的声明性接口来进行业务通信。JSON是一种流行的格式，XML在此之前就是如此。

这并不是说您不能通过消息总线来执行点对点，但是您最终会管理大量的会话状态，这会使事情复杂化。如果您的通信大多是具有点对点的事件，那么最好还是只保留一个消息传递系统。

类似地，如果您大部分是流的消息传递，您很可能嵌入一个事件协议到流协议出于同样的原因。

这不是你唯一的选择。对于复杂的设置，我非常喜欢使用ZeroMQ，使用一个通信"fabric“，但在必要时应用适当的拓扑。

总之，最佳消息传递拓扑取决于消息的性质。没有一个正确的答案，但在积极的一面，这是一条很好的路。除非你正在做一些非常不寻常的事情，否则你应该能够得到好的、现成的、有合理缓解效果的解决方案。