「第二部:容器和微服务架构](12) 基于异步消息的通信

「第二部:容器和微服务架构](12) 基于异步消息的通信

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

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

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

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

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

单接收器消息通信

与单个接收器的基于消息的异步通信意味着存在点对点通信，该点对点通信将消息准确地传递给从通道读取的某个消费者，并且消息仅被处理一次。但也有特殊情况。例如，在尝试从故障中自动恢复的云系统中，可以多次发送同一消息。由于网络或其他故障，客户端必须能够重试发送消息，而服务器必须实现一个等幂操作，以便仅处理一次特定消息。

单接收器基于消息的通信特别适合于从一个微服务向另一个微服务发送异步命令，如图18所示，该图说明了这种方法。

一旦开始发送基于消息的通信（使用命令或事件），就应该避免将基于消息的通信与同步HTTP通信混合使用。

图18 接收异步消息的单个微服务

注意，当命令来自客户端应用程序时，它们可以实现为HTTP同步命令。当您需要更高的可伸缩性或已经在基于消息的业务流程中时，应该使用基于消息的命令。

基于消息的多接收器通信

作为一种更灵活的方法，您可能还希望使用发布/订阅机制，以便来自发件人的通信可用于其他订阅服务器微服务或外部应用程序。因此，它有助于您在发送服务中遵循打开/关闭原则。这样，以后就可以添加额外的订阅者，而无需修改发送者服务。

使用发布/订阅通信时，可能正在使用事件总线/Kafka接口将事件发布到任何订阅服务器。

异步事件驱动通信

当使用异步事件驱动通信时，微服务在其域内发生某些事情时发布集成事件，而另一个微服务需要注意该事件，如产品目录微服务中的价格更改。其他微服务订阅事件，以便它们可以异步接收它们。当这种情况发生时，接收方可能会更新自己的域实体，这可能会导致发布更多的集成事件。这个发布/订阅系统通常通过使用事件总线/Kafka的实现来执行。事件总线/Kafka可以设计为一个抽象或接口，带有订阅或取消订阅事件和发布事件所需的API。事件总线/Kafka还可以具有基于任何进程间和消息传递代理的一个或多个实现，如支持异步通信和发布/订阅模型的消息传递队列或服务总线。

如果系统使用由集成事件驱动的最终一致性，建议最终用户完全清楚地了解此方法。系统不应该使用模拟集成事件的方法，例如来自客户端的信号器或轮询系统。最终用户和业务所有者必须明确地接受系统中的最终一致性，并意识到在许多情况下，业务对这种方法没有任何问题，只要它是明确的。这一点很重要，因为用户可能希望立即看到一些结果，而这可能不会随着最终的一致性而发生。

正如前面在“分布式数据管理的挑战和解决方案”一节中所述，您可以使用集成事件来实现跨多个微服务的业务任务。因此，这些服务之间最终会保持一致。最终一致的事务由一组分布式操作组成。在每个操作中，相关的微服务更新一个域实体并发布另一个集成事件，该事件在同一个端到端业务任务中引发下一个操作。

重要的一点是，您可能希望与订阅同一事件的多个微服务通信。为此，您可以使用基于事件驱动通信的发布/订阅消息传递，如图19所示。这种发布/订阅机制不是microservice体系结构独有的。它类似于DDD中有界上下文的通信方式，或者类似于在命令和查询责任隔离（CQRS）体系结

构模式中将更新从写数据库传播到读数据库的方式。目标是在分布式系统中的多个数据源之间保持最终的一致性。

图19。异步事件驱动消息通信

在异步事件驱动的通信中，一个微服务将事件发布到一个事件总线/Kafka，许多微服务可以订阅它，以获得通知并对其进行操作。您的实现将确定用于事件驱动的、基于消息的通信的协议。AMQP可以帮助实现可靠的排队通信。

使用事件总线/Kafka时，您可能希望使用抽象级别（如事件总线/Kafka接口），该抽象级别基于使用来自消息代理（如RabbitMQ）的API的类中的相关实现，或使用带有主题的服务总线（如Azure服务总线）。或者，您可能希望使用更高级别的服务总线（如NServiceBus、maststrait或Brighter）来表达您的事件总线/Kafka和发布/订阅系统。

关于生产系统消息传递技术的一点注记

可用于实现抽象事件总线/Kafka的消息传递技术处于不同的级别。例如，RabbitMQ（消息传递代理传输）和Azure服务总线等产品的级别低于其他产品，如NServiceBus、mastransit或Brighter，这些产品可以在RabbitMQ和Azure服务总线之上工作。您的选择取决于您的应用程序在应用程序级别上需要多少丰富的功能和开箱即用的可伸缩性。对于只为您的开发环境实现概念验证事件总线/Kafka，正如在eShopOnContainers示例中所做的那样，在Docker容器上运行RabbitMQ之上的简单实现可能就足够了。

但是，对于需要高度可伸缩性的任务关键型系统和生产系统，您可能需要评估Azure服务总线。对于更容易开发分布式应用程序的高级抽象和特性，我们建议您评估其他商业和开源服务总线，如NServiceBus、maststrait和Brighter。当然，您可以在RabbitMQ和Docker等低级技术的基础上构建自己的服务总线特性。但是，对于定制的企业应用程序来说，管道工程的成本可能太高。

弹性地发布到事件总线/Kafka

在跨多个微服务实现事件驱动体系结构时，一个挑战是如何原子地更新原始微服务中的状态，同时以某种方式基于事务将其相关集成事件弹性地发布到事件总线/Kafka中。以下是实现这一目标的几种方法，尽管也可能有其他方法。

使用事务（基于DTC）队列，如MSMQ。（但是，这是一种传统方法。）使用事务日志挖掘。使用完整的事件源模式。使用发件箱模式：事务数据库表作为消息队列，该消息队列将作为创建事件并发布事件的事件创建者组件的基础。

使用异步通信时要考虑的其他主题是消息等幂和消息重复数据消除。本指南后面的“实现微服务（集成事件）之间基于事件的通信”一节将介绍这些主题。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。