如何实现基于异步消息的微服务架构通信？

本文共计2533个文字，预计阅读时间需要11分钟。

在多个微服务和相关域模型传播更新时，异步消息传递和事件驱动通信至关重要。正如在讨论microservices及其上下文（BCs）时所提到的，模型涉及用户、客户、产品、账户等。

在跨多个微服务及其相关的域模型传播更改时，异步消息传递和事件驱动的通信至关重要。正如前面在讨论microservices和有界上下文（BCs）时所提到的，模型（用户、客户、产品、帐户等）对不同的microservices或BCs可能有不同的含义。这意味着当发生更改时，您需要某种方法来协调不同模型之间的更改。解决方案是基于异步消息传递的最终一致性和事件驱动通信。

使用消息传递时，进程通过异步交换消息进行通信。客户端通过发送消息向服务发出命令或请求。如果服务需要回复，它会向客户端发送另一条消息。由于这是一种基于消息的通信，客户端假定不会立即收到回复，并且可能根本没有响应。消息由头（标识或安全信息等元数据）和正文组成。消息通常通过异步协议（如AMQP）发送。

微服务社区中此类通信的首选基础设施是轻量级消息代理，它不同于SOA中使用的大型代理和编排器。在轻量级消息代理中，基础设施通常是“哑的”，仅充当消息代理，具有简单的实现，如RabbitMQ或云中的可伸缩服务总线（如Azure服务总线）。在这个场景中，大多数“智能”思维仍然存在于生成和消费消息的端点中，也就是在微服务中。

您应该尽量遵循的另一个规则是，在内部服务之间只使用异步消息传递，并且只使用从客户端应用程序到前端服务（API网关加上第一级微服务）的同步通信（如HTTP）。

异步消息通信有两种：单接收者消息通信和多接收者消息通信。以下各节提供了有关它们的详细信息。