思考微服务中的异步消息传递

2 年 ago

新, 韵

1 minute

首先

最近，国内的企业逐渐开始采用微服务架构来更新长期使用的系统。随着对数字化转型的关注逐渐增加，对微服务的兴趣也在不断提升。

在@takahashisansan的文章《探讨微服务对于减少开发和运维成本的贡献》中，提到了设计松散耦合的微服务的关键点，其中包括确保微服务之间的协作和独立性。合适的异步消息传递被认为对于实现松散耦合非常有效。

此外，在@tsukmr的文章《通过领域驱动设计思想对微服务进行拆分的考虑》中提到，领域专家与设计师、开发人员共同参与领域和微服务的设计。

通过参考多篇文章，我整理了关于微服务之间接口的异步消息传递。

异步消息传递

当在涉及SoE领域的微服务架构和分布式架构整理时，我认为异步消息传递在服务间协作方面是一个讨论的重点之一。

经过查阅一些文章后，发现有很多使用消息平台Kafka（OSS）来实现服务之间协作的案例。
Apache Kafka（OSS）是在Linkedin公司中为处理大量流式数据（如社交数据等）而开发并开源化的。
Kafka作为一个消息平台，在群集中的多个机器上进行安装，使用Zookeeper来进行群集节点间的协作。
Zookeeper是用于共享群集（多个节点）配置的服务，用于跟踪节点、主题等的配置，并用于恢复故障节点。
在Kafka的消息平台上，当数据生产者（Producer）将消息发送到Kafka的主题时，这些数据的消费者（Consumer）可以读取和处理（微服务、应用程序处理）这些消息。

我已经考虑了在消息平台上使用异步消息传递的使用场景。

在微服务之间的协同合作中使用异步消息传递的场景。

在微服务之间的协作中，有以下两种使用场景预设了使用异步消息传递。

在微服务之间需要响应等通信

如果在微服务之间使用消息传递进行通信，可以预期与远程通信协议（如Web服务、HTTP/REST等）类似的使用场景。
假设想要将某一微服务的消息发送给另一个微服务（1对1），可以使用发布/订阅式的消息传递方式，将消息从微服务（发布者）发送到主题，然后另一个微服务（订阅者）可以读取该消息。
还可以考虑通过消息传递平台的消息代理和设置消息主题，将消息中继到某个微服务中，这个微服务可以是来自多个微服务之间的中间传递。

通过微服务发生的事件，使其他微服务相互协作并运行的微服务集成。

不仅仅限于1对1的情况，在某个微服务发送消息给多个微服务（1对N）的情况下，我们也可以考虑使用发布/订阅的消息传递方式。在消息的主题中，可能会涉及多个微服务进行订阅。

应该处理使用异步消息传输的事件。

在前面的章节中提到的“将微服务整合起来，以使其能够通过微服务之间发生的事件来协同工作”的方法中，需要与领域专家一起设计业务和微服务，如前面提到的使用领域驱动设计将微服务进行分解是必要的。
在这里，我们将总结与连接微服务之间的异步消息传递事件有关的内容。

根据「Microsoft docsドメインイベント：設計と実装」的说法，该文详细解释了在微服务之间进行异步消息传递所处理的事件。

リモートサービス間でのプロセス間分散通信を可能にする何らかのインフラストラクチャが必要

本文将不详细讨论Microsoft文档中提到的局部事件，而是省略。

最后

我整理了关于微服务之间的异步消息传递的接口。

首先，如上所述，如果在接口中可以使用异步消息传递，则可以期望实现微服务的独立性、松耦合和分布式互操作，并且可以减小服务之间的影响，增加系统对故障的抵御能力，具有非功能方面的效果。

非同期消息可以在多个平台上实现，例如云服务供应商的PaaS等。关于消息传递，我认为不仅限于Kafka，还有其他一些相关文章可以作为参考。希望您能参考下面的相关文章，如果对您有帮助，我将非常高兴。

以下是对以上文本的本地化翻译：

引用和参考：官方文件中有关Kafka的介绍非常好。
Microsoft 资料：领域事件的设计和实现。
探讨微服务如何为开发和运维成本降低做出贡献。
思考数字转型中系统的敏捷性是什么。
考虑使用领域驱动设计将微服务分割。