「第二部:容器和微服务架构](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。(但是,这是一种传统方法。)
  • 使用事务日志挖掘。
  • 使用完整的事件源模式。
  • 使用发件箱模式:事务数据库表作为消息队列,该消息队列将作为创建事件并发布事件的事件创建者组件的基础。

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


额外资源


目录
打赏
0
0
0
0
112
分享
相关文章
Super MySQL|揭秘PolarDB全异步执行架构,高并发场景性能利器
阿里云瑶池旗下的云原生数据库PolarDB MySQL版设计了基于协程的全异步执行架构,实现鉴权、事务提交、锁等待等核心逻辑的异步化执行,这是业界首个真正意义上实现全异步执行架构的MySQL数据库产品,显著提升了PolarDB MySQL的高并发处理能力,其中通用写入性能提升超过70%,长尾延迟降低60%以上。
阿里面试:Redis 为啥那么快?怎么实现的100W并发?说出了6大架构,面试官跪地: 纯内存 + 尖端结构 + 无锁架构 + EDA架构 + 异步日志 + 集群架构
阿里面试:Redis 为啥那么快?怎么实现的100W并发?说出了6大架构,面试官跪地: 纯内存 + 尖端结构 + 无锁架构 + EDA架构 + 异步日志 + 集群架构
阿里面试:Redis 为啥那么快?怎么实现的100W并发?说出了6大架构,面试官跪地: 纯内存 + 尖端结构 +  无锁架构 +  EDA架构  + 异步日志 + 集群架构
云原生时代的应用架构演进:从微服务到 Serverless 的阿里云实践
云原生技术正重塑企业数字化转型路径。阿里云作为亚太领先云服务商,提供完整云原生产品矩阵:容器服务ACK优化启动速度与镜像分发效率;MSE微服务引擎保障高可用性;ASM服务网格降低资源消耗;函数计算FC突破冷启动瓶颈;SAE重新定义PaaS边界;PolarDB数据库实现存储计算分离;DataWorks简化数据湖构建;Flink实时计算助力风控系统。这些技术已在多行业落地,推动效率提升与商业模式创新,助力企业在数字化浪潮中占据先机。
246 12
基于阿里云容器服务Kubernetes版(ACK)的微服务架构设计与实践
本文介绍了如何基于阿里云容器服务Kubernetes版(ACK)设计和实现微服务架构。首先概述了微服务架构的优势与挑战,如模块化、可扩展性及技术多样性。接着详细描述了ACK的核心功能,包括集群管理、应用管理、网络与安全、监控与日志等。在设计基于ACK的微服务架构时,需考虑服务拆分、通信、发现与负载均衡、配置管理、监控与日志以及CI/CD等方面。通过一个电商应用案例,展示了用户服务、商品服务、订单服务和支付服务的具体部署步骤。最后总结了ACK为微服务架构提供的强大支持,帮助应对各种挑战,构建高效可靠的云原生应用。
微服务架构解析:跨越传统架构的技术革命
微服务架构(Microservices Architecture)是一种软件架构风格,它将一个大型的单体应用拆分为多个小而独立的服务,每个服务都可以独立开发、部署和扩展。
1818 36
微服务架构解析:跨越传统架构的技术革命
基于阿里云容器服务(ACK)的微服务架构设计与实践
本文介绍如何利用阿里云容器服务Kubernetes版(ACK)构建高可用、可扩展的微服务架构。通过电商平台案例,展示基于Java(Spring Boot)、Docker、Nacos等技术的开发、容器化、部署流程,涵盖服务注册、API网关、监控日志及性能优化实践,帮助企业实现云原生转型。
微服务引擎 MSE:打造通用的企业级微服务架构
微服务引擎MSE致力于打造通用的企业级微服务架构,涵盖四大核心内容:微服务技术趋势与挑战、MSE应对方案、拥抱开源及最佳实践。MSE通过流量入口、内部流量管理、服务治理等模块,提供高可用、跨语言支持和性能优化。此外,MSE坚持开放,推动云原生与AI融合,助力企业实现无缝迁移和高效运维。
232 1
《docker高级篇(大厂进阶):5.Docker-compose容器编排》包括是什么能干嘛去哪下、Compose核心概念、Compose使用三个步骤、Compose常用命令、Compose编排微服务
《docker高级篇(大厂进阶):5.Docker-compose容器编排》包括是什么能干嘛去哪下、Compose核心概念、Compose使用三个步骤、Compose常用命令、Compose编排微服务
421 24
智慧工地云平台的技术架构解析:微服务+Spring Cloud如何支撑海量数据?
慧工地解决方案依托AI、物联网和BIM技术,实现对施工现场的全方位、立体化管理。通过规范施工、减少安全隐患、节省人力、降低运营成本,提升工地管理的安全性、效率和精益度。该方案适用于大型建筑、基础设施、房地产开发等场景,具备微服务架构、大数据与AI分析、物联网设备联网、多端协同等创新点,推动建筑行业向数字化、智能化转型。未来将融合5G、区块链等技术,助力智慧城市建设。
244 0
云卓越架构:容器安全最佳实践
本次分享由阿里云智能集团解决方案架构师张玉峰主讲,主题为“云卓越架构:容器安全最佳实践”。内容涵盖容器安全的挑战、云原生容器安全架构及典型场景。首先分析了容器安全面临的问题,如镜像漏洞和权限管理。接着介绍了容器安全架构的五个维度:身份权限管理、配置安全检查、运行时防护、镜像安全检测及发布的安全管控。最后通过具体场景展示了容器身份与权限管理、密钥管理、运行时防入侵等最佳实践,强调了安全左移的重要性,确保从开发到运行的全生命周期安全覆盖。
AI助理

你好,我是AI助理

可以解答问题、推荐解决方案等

登录插画

登录以查看您的控制台资源

管理云资源
状态一览
快捷访问