Event-Driven Architecture Patterns 终极指南

原文链接 The Ultimate Guide to Event-Driven Architecture Patterns

说实话,这个文章所涉及的内容的复杂(广度),有点吓到我了 🤣🤣🤣。

虽不深刻,但静下心来慢慢品,总能找出一些感悟,希望你也能喜欢😄

文中这句话也说到了我的心里。

“想要追求完美且能普遍接受的定义,只能排除干扰, 去理解和感受不同类型的event-driven 模式。 其过程堪比剥洋葱。 🤣”

The key to breaking through the noise and arriving at a pretty-universally-acceptable definition of the patterns of event-driven architecture is to peel back the onion and consider different kinds of event-driven architecture patterns:

在本文中,您将了解事件驱动架构模式的分类,并了解从通信到治理的各种有用模式。不是相互排斥的,一些应用程序和用例可能需要不同领域的模式组合。阅读更多内容,发现这些类别中一些流行的和重要的模式。

1,事件生成模式 (Event Generation Patterns)

        此类模式涉及 用于生成表示系统内重要事件或更改的事件 的技术和策略。

这些模式定义了如何根据特定的触发器或条件识别、捕获和生成事件。

这些模式支持检测和提取相关信息,确保生成重要事件,并使其可供其他组件或服务使用。

这些模式促进了实时响应、数据同步以及相关信息在整个系统中的传播。

1-1,Event Carried State Transfer (ECST)

事件携带状态传输(ECST)利用事件作为状态传播的机制,而不是依赖于同步请求/响应协议。这将分离服务,提高可伸缩性和可靠性,并提供维护系统状态一致视图的机制。

通过利用ECST模式,服务可以独立运行并更有效地扩展。

通过将事件传播给所有相关方,服务可以确保它们拥有系统状态的最新视图。这在高度分布式的系统中尤其重要,因为在这种情况下,维护系统状态的一致视图是具有挑战性的。

这里我更喜欢文中推荐的另一个blog Event-driven Design 里面描述的内容。

常见的 event message 只包含粗略的信息,如 “Mike logged in to server-001”

ECS(event carried state message),则包含更多的信息。如 Mike账户的完整信息、Mike手机设备登录时的位置信息 以及 安全相关的信息。

这使得ECS消息非常强大。由于ECS是一种“重量级”消息类型,因此它通常用于在数据库中存储数据或将大块数据从一个系统传输到另一个系统。例如,上面描述的登录信息可能用于更新数据库中Mike的用户记录,或者为访问系统的每个人添加日志数据。实际上,您可以将ECS消息看作是在RESTful系统中通常用于编写数据的JSON资源对象。这使得ECS消息在规划从RESTful到EVENTful实现的转变时成为一种方便的方法。

ECS可携带接收者所需要的所有信息,这样接收者省去了收集信息的操作。当然这样也存在包含了其它接收者不需要的信息的情况。

了解更多

1-2, Command Query Response Segregation (CQRS)

可以看这篇文章 CQRS Design Pattern in Microservices - CQRS模式-优快云博客

了解更多

1-3, Change Data Capture (CDC)

可以看这篇文章 What is Change Data Capture? CDC是什么?-优快云博客

更改数据捕获(CDC)是事件驱动体系结构中用于捕获和处理对数据库所做更改的模式。CDC模式用于跟踪对源数据库的更改,并将其转换为下游系统(如数据仓库、数据湖和流应用程序)可以轻松使用的格式。

CDC的工作原理是检测对源数据库所做的更改,并将其作为事件发布。其他系统可以使用这些事件,从而使它们的数据能够实时地与源数据库保持同步。CDC还可用于提供对数据库所做更改的历史记录,这对于审计和遵从性目的非常有用。

在事件驱动的体系结构中,CDC经常与其他模式(如事件流和流处理)结合使用,以构建实时数据管道。CDC提供了一种捕获和转换数据库中发生的数据更改的方法,而事件流和流处理提供了在数据流经管道时处理和分析数据的机制。

CDC捕获提供细粒度表示的单个数据更改,并与底层数据库技术密切相关。但是,如果希望在事务上下文中捕获更改,则可以使用事务性发件箱模式(Transactional Outbox)。

了解更多

1-4, Event Sourcing

可以看这篇文章 Event Sourcing Pattern 事件流模式-优快云博客

事件溯源是事件驱动体系结构中使用的一种模式,它涉及捕获作为事件序列的应用程序状态的所有更改,而不仅仅是当前状态。此事件序列用于构建和重建应用程序的状态,使其成为需要可审计性和可重玩性的系统的基本模式。

在任何时间点,都可以通过从头开始重播事件存储中的所有事件来构建应用程序的当前状态。这允许系统始终拥有应用程序状态的最新视图,并使开发人员能够轻松地诊断和排除可能出现的问题。

事件源通常与上面描述的CQRS模式结合使用,该模式分离了应用程序的写和读操作,使相同数据的不同视图能够针对其特定用例进行优化。通过使用CQRS,开发人员可以优化写操作以有效地生成事件和更新事件存储,同时优化读操作以有效地查询数据并提供数据的实时视图。

了解更多

2,通信模式 (Communication Patterns)

事件驱动架构中的通信模式包含各种技术和方法,用于支持分布式系统中不同组件和服务之间的通信和数据交换。这些模式定义了如何传播(propagated)、交付(delivered)和使用(consumed)事件,确保事件生产者和消费者之间可靠和有效的通信。它们在建立松耦合、支持实时和异步通信、支持可伸缩性以及促进事件驱动生态系统中不同系统的集成方面发挥着至关重要的作用。

当两个应用程序想要交换数据时,它们将其封装在消息中(message)。然而,消息传递不仅仅是在网络上发送比特。要使其有效,必须考虑几个因素。

首先,消息的意图必须明确,有三种主要类型的消息:

命令消息(Command Messages

        用于请求或指示接收者采取特定的操作。它们通常从发送方发送到特定的接收方,指定要执行的预期操作。命令消息通常用于启动业务流程或触发服务或组件中的工作流或特定行为。它们在本质上被认为是命令式的,带有指示或命令。

一个例子是发送给支付服务的命令消息,请求它处理支付事务。

文档消息(Document Messages

        用于在不同组件或服务之间通信数据或信息。它们通常携带包含结构化数据(如JSON或XML)的有效负载,这些结构化数据表示文档或一条信息。文档消息通常用于数据交换和共享,它们可以被多个订阅者或服务使用。

例如,将携带客户数据的文档消息发送到分析系统以进行进一步处理。

### Event Driven Architecture Concepts In event-driven architecture (EDA), systems are designed around the production, detection, and consumption of events. An event represents a significant change in state within the system. Events trigger reactions that propagate through various components or services, enabling asynchronous communication between loosely coupled parts. The reuse of existing event handlers exemplifies how EDA promotes modular design principles where common behaviors can be encapsulated into reusable units[^1]. ### Implementation Methods #### Defining Events Events should capture meaningful changes occurring within applications. These could include user actions, data modifications, external triggers like sensor readings, etc. Each event typically contains metadata describing what happened along with relevant contextual information needed by consumers. #### Establishing Producers and Consumers Producers emit events while consumers listen for specific types of events to perform corresponding operations. Middleware such as message queues or stream processors facilitate decoupling producers from consumers ensuring reliable delivery even under high load conditions. ```python import pika def send_event(event_type, payload): connection = pika.BlockingConnection(pika.ConnectionParameters('localhost')) channel = connection.channel() channel.exchange_declare(exchange='events', exchange_type='topic') routing_key = f'event.{event_type}' channel.basic_publish( exchange='events', routing_key=routing_key, body=payload) print(f"Sent {payload} on topic '{routing_key}'") connection.close() send_event('order.placed', '{"orderId": "123"}') ``` This Python code snippet demonstrates sending an `order.placed` event using RabbitMQ as messaging middleware. #### Handling Failures Gracefully When designing EDAs, consider potential points of failure including network issues, service outages, or malformed messages. Implement robust retry mechanisms alongside dead-letter queues to handle transient errors effectively without losing critical business transactions[^3]. ### Best Practices - **Decouple Components:** Ensure each component operates independently so failures do not cascade across unrelated areas. - **Ensure Idempotency:** Design consumer logic idempotent whenever possible meaning processing duplicate copies does not affect outcome negatively. - **Monitor System Health:** Utilize monitoring tools tracking key performance indicators related to latency, throughput, error rates providing insights into operational efficiency. --related questions-- 1. How would you implement fault tolerance patterns in event-driven architectures? 2. What strategies exist for managing large volumes of events efficiently? 3. Can you provide examples demonstrating secure transmission methods suitable for sensitive event payloads? 4. In which scenarios might synchronous request-reply models prove more advantageous compared to event-based approaches? 5. Describe techniques useful for tracing end-to-end flows involving multiple microservices exchanging events asynchronously.
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值