Event-Driven Architecture Patterns 终极指南

DachuiLi2024-12-24 8:45

原文链接 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模式-CSDN博客

了解更多

1-3， Change Data Capture (CDC)

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

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

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

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

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

了解更多

1-4， Event Sourcing

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

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

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

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

了解更多

2，通信模式 （Communication Patterns）

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

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

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

命令消息（Command Messages）

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

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

文档消息（Document Messages）

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

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

事件消息（Event Messages）

表示系统中的事件或状态变化，也称为通知。它们通常用于通知相关方已经发生的事情。事件消息通常发布到消息代理，感兴趣的订阅者或服务可以使用这些事件。它们对于在事件驱动的体系结构中实现组件的松散耦合和解耦非常重要。

例如，当在电子商务系统中下了一个新订单时，会发布一条事件消息，通知库存管理、支付处理和运输等下游系统。

事件消息可以根据所携带的数据量进一步分类。

仅通知：事件包括一个业务对象键，可能还有一个用于检索数据的链接

通知+元数据：与通知相同，但携带额外的元数据来指示更改

通知+数据：事件包括行动所需的所有相关数据（也称为事件携带状态转移【Event Carried State Transfer】）

其次，发送方需要有一个策略，

比如消费、在接收时发送响应，或者在使用请求-应答交互模式时采取行动。根据用例，发送方还可以选择确保有保证的交付顺序并设置截止日期。

以下这些是构建事件驱动架构时使用的关键通信模式：

2-1，发布-订阅（Publish-Subscribe）

发布-订阅是一种通信模式，通过让应用程序将消息发布到中介代理（broker）而不是直接与使用者通信（如点对点）来解耦应用程序。这种方法引入了发布者和订阅者之间的异步通信模式，提供了更高的可伸缩性、更高的可靠性，以及通过使用代理上的队列延迟处理的能力。

从这个意义上说，发布者和消费者并不了解对方；它们只是产生或接收事件。事件代理（event broker）可以采用中间件软件（middleware software）、设备（appliance）或部署在任何环境中的SaaS的形式，在事件发生时促进和分发事件，将事件推送给可能位于各种环境（例如本地或公共/私有云）中的消费者。

在事件驱动的体系结构中，发布-订阅模式经常用于构建事件驱动的微服务体系结构和实时流（real-time streaming）。它可以帮助解耦应用程序的不同部分，实现灵活的扩展，并支持对大量数据的实时处理。

了解更多

2-2，点对点（Point-to-Point）

如果需要将消息传递给特定的收件人，则不需要使用发布-订阅模式。在这种情况下，使用点对点消息交换模式将消息传递给单个接收者，即所谓的"一对一"交换。也有可能几个发送者向同一个接收者发送消息，这是一种"多对一"交换。在这些情况下，端点通常采用命名队列的形式。如果多个接收器连接到队列，则只有其中一个接收到消息。

了解更多

2-3，请求-应答（Request-Reply）

虽然发布-订阅和点对点通信模式都促进了单向通信，但是当您的目标是专门从接收方获得响应时，请求-应答模式是必要的。此模式确保使用者向每个消费的消息发送响应，其实现从使用返回地址到将响应发送到单独的端点不等【是不是就像钩子函数， Webhooks 】。

实际上，我们正在研究两种不同的消息传递操作：一种是请求者使用点对点（交付）或发布-订阅（广播）模式传输消息，另一种是接收方以指向发送方的点对点方式响应请求。需要注意的是，应答交换总是点对点的，因为目的仅仅是将响应返回给请求者。

了解更多

2-4，（事件流）Event Streaming

Message Queues vs Event Streams 消息队列和事件流_event streaming和mq区别-CSDN博客

事件流是事件驱动体系结构中的一种通信模式，它允许向相关方持续交付事件。它经常在事件驱动的体系结构中用于解耦应用程序和服务，并支持事件的实时处理。在这种模式中，数据不断地从各种来源摄取并实时流式传输，从而能够构建即时见解并立即采取行动。

事件流模式支持创建高响应性和实时系统，可以在数据到达时对其进行分析和操作。

此模式通常用于需要实时监控的应用程序，例如欺诈检测、预测性维护和物联网系统。

了解更多

3，消费模式（Consumption Patterns）

消费模式包含用于消费和处理系统内生成的事件的策略和技术。这些模式定义了事件使用者如何接收、过滤和对事件采取行动。这些模式使组件和服务能够对相关事件作出反应，触发适当的操作，更新其内部状态，并在必要时传播新事件。消费模式促进解耦和异步处理，允许组件实时响应事件，维护数据一致性，并根据接收到的事件编排复杂的工作流。

3-1，（层次的话题）Hierarchical Topics

主题是事件驱动体系结构中的一个基本概念，它允许对事件进行分类并将其路由给感兴趣的消费者。但是，在不同的事件代理（brokers）之间实现主题的方式是不同的。

一些代理提供扁平（flat）主题结构，而其他代理提供分层（hierarchical）结构。此外，一些代理使用分区（partitioning）来提高可伸缩性，并确保将相关事件路由到相同的分区。带有通配符（wildcard）订阅的分层主题结构允许对主题订阅和过滤进行更细粒度的控制，使消费者能够只接收他们感兴趣的事件。

在定义主题结构之前，评估事件代理的功能（evaluate the capabilities of your event broker）非常重要，以确保它满足可伸缩性、弹性和灵活性的需求。

了解更多

3-2，事件过滤（Event Filtering）

组件如何避免接收不感兴趣的事件？事件过滤是一种模式，它允许使用者指定一组规则，以确定他们将根据事件元数据或有效负载接收哪些事件。此模式与流查询密切相关（stream querying），但它特别适用于消费者使用表达式（expression）来决定接收哪些事件的情况。重要的是要注意，事件代理的过滤特性可以有很大的不同。

基于订阅的代理要求所有消费者定义一个过滤器，代理使用该过滤器来决定将哪些事件发送给消费者。过滤规则通常只适用于消息元数据。另一方面，在面向日志和队列的代理中（log- and queue-oriented），过滤可以在客户端代码或代理中实现。当代理执行过滤时，不会传输客户机不需要的事件，从而节省带宽、客户机内存和CPU资源。然而，使用消费者端过滤，事件被发送给消费者，但客户端丢弃事件，而不是将其交付给应用程序代码，从而导致性能和网络开销。

了解更多

3-3，有保证的交付（Guaranteed Delivery）

"保证交付"模式是事件驱动体系结构中的一个关键概念，其重点是确保事件的可靠和一致交付。在事件驱动的体系结构中，事件表示系统中的重要事件或状态更改，并异步地传递给对它们感兴趣的组件或服务。

在分布式系统中，即使在出现故障、网络问题或中断的情况下，保证事件可靠地到达预期的接收者也是至关重要的。保证交付模式通过引入防止传输过程中事件丢失或遗漏的机制来解决这一需求。

通过持久化（persisting）事件，系统确保它们是持久的，并且在发生故障或中断时可以恢复。Acknowledgments 向发送方提供反馈，确认事件交付成功。交付重试机制允许在失败的情况下重新传输事件，其方法可以选择性地增加尝试之间的时间间隔。幂等性（Idempotency）确保多次处理同一事件产生与处理一次相同的结果。

通过采用保证交付模式，事件处理的可靠性、容错性和一致性得到了显著提高。它确保关键事件不会丢失，使系统即使在面临故障或中断时也能保持完整性和一致性。

了解更多

3-4，背压和推送（Backpressure and Push）

backpressure这里翻译成"背压"，给我造成了理解压力，但貌似很多地方都这么干。

所以找到了这篇文章 What Does "Back Pressure" Mean 解释了什么是 back pressure。

简单地说，反向压力是被抑制的压力。

在这种情况下，"反"指的是流体或气体的自然流动。

背压和推送是一种事件驱动的架构模式，用于管理具有不同处理速度的系统或组件之间的数据流。它的设计是为了防止由于过载而导致的数据丢失或降级。

为了避免这个问题，背压和推模式使用一种机制，接收方向发送方发送一个信号，表明它准备接收更多的数据。这个信号叫做背压（backpressure） 。当发送方接收到这个信号时，它会减慢生成和发送事件的速度，让接收方能够赶上。一旦接收方准备好处理更多事件，它将向发送方发送另一个Backpressure信号，并继续此过程。在一些代理中，代理基于max unacked + receive window size 的配置提供了自回压机制（self-backpressure mechanism），从而减轻了接收方的 signaling 责任。

背压和推送模式通过基于接收系统的容量管理事件处理的速率，帮助确保组件之间平滑和有效的数据流。

了解更多

3-5，独占消费者（Exclusive Consumer (HA)）

独占消费者模式在事件驱动的体系结构中起着至关重要的作用，特别是在消息处理的顺序和完整性至关重要的场景中。此模式确保在为冗余设置多个消费者时，在任何给定时间只有一个消费者在积极地处理消息。这种设置可以防止消息重复，并保证按正确的顺序处理每条消息。此模式的一个基本特性是其自动故障转移机制，该机制允许次要消费者在主要消费者发生故障时无缝地承担处理职责，从而保持不间断的服务。尽管此模式显著提高了数据完整性和系统可靠性，但它依赖于底层消息传递代理的强大支持来管理消费者准备情况并有效地处理无缝传输。此模式提供无错误的顺序数据处理，以确保事务的准确性并维护系统的健壮性。

了解更多

4，消费者可伸缩性模式 （Consumer Scalability Patterns）

可伸缩性是任何企业系统关注的关键问题，当事件在系统中连续流动时，可伸缩性变得更加重要。事件驱动架构中的可伸缩性模式是用于构建能够处理大量事件并有效扩展以满足需求的系统的技术和最佳实践。这些模式解决了可伸缩性的各个方面，例如跨多个节点分配工作负载、处理流量高峰以及动态调整资源以匹配工作负载。通过利用事件驱动体系结构中的可伸缩性模式，组织可以构建高可用性、响应性和对故障具有弹性的系统。

4-1，竞争消费者（Competing Consumers）

竞争消费者是事件驱动体系结构中的一种可伸缩性模式，它涉及在多个消费者之间分配处理事件的工作负载，以提高吞吐量并减少处理时间。在此模式中，使用多个消费者或工作进程来并行处理来自共享事件流或队列的事件。每个使用者监听相同的事件流，只处理事件的一个子集，从而将工作负载分配给多个使用者。

此模式在处理大容量事件流时非常有用，因为单个使用者可能无法跟上事件速率或有效地处理处理工作负载。通过使用多个消费者，可以并行化处理，从而实现更好的资源利用和改进的可伸缩性。

了解更多

4-2，消费者组（Consumer Groups）

消费者组模式类似于竞争消费者模式，但增加了一个抽象层。在此模式中，将创建一组消费者来接收来自单个事件流或消息队列的消息。组中的每个使用者处理事件的一个子集，事件在组中的使用者之间进行负载平衡。消息传递系统确保每个事件仅由组中的一个使用者处理。

使用消费者组的好处是，它们提供了一个抽象级别，允许更大的灵活性和可伸缩性。可以根据需要在组中添加或删除消费者，而不会影响事件的整体处理。此模式通常用于需要使用相同事件流的多个服务或应用程序的分布式系统中。

消息的实际消耗可以基于简单的轮询方案或更复杂的方案，如使用键/散列方案的粘性负载平衡。

了解更多

4-3，减震器（Shock Absorber）

减震器模式是事件驱动体系结构中常用的一种技术，用于减轻可能导致服务降级或故障的突发事件的影响。该模式涉及在事件源和使用事件的下游服务之间引入缓冲区或队列。

通过引入这个缓冲区，模式可以平滑事件流，确保没有服务被突然爆发的事件压垮。此缓冲区还可以帮助将事件源与下游服务解耦，提供一个隔离层，可以帮助防止对事件源的意外更改。

当使用队列作为缓冲区时，减震器模式可以提供额外的好处。队列充当持久存储机制，即使下游服务不能立即可用，也允许对事件进行缓冲。这在下游服务有自己的突发工作负载并且可能并不总是可用来消费事件的情况下特别有用。

了解更多

4-4，分区（Partitioning）

分区是事件驱动架构中的一种设计模式，它通过跨多个队列分区分发事件来帮助提高可伸缩性、性能和可靠性。此模式背后的主要思想是将单个队列划分为多个较小的队列，通过并行处理消息来实现更高的吞吐量和更低的延迟。每个分区可以独立处理，这样可以增加并发性和并行性，从而提高事件系统的整体处理速度。

它通过将工作负载分配给多个可以并行处理事件的消费者来帮助处理突发事件。通过对队列进行分区，可以将工作负载分配给不同的服务器或处理单元，从而提高事件处理系统的整体效率。

分区是事件驱动架构中的一个重要概念，它允许扩展消费者。但是，根据使用队列或文件来持久化事件，不同的事件代理之间的实现会有所不同。

了解更多

5，部署体系结构（Deployment Architecture Patterns）

事件驱动体系结构中的部署体系结构模式指的是用于部署和组织事件驱动系统中涉及的代理的不同策略和配置。部署体系结构模式包括集中式事件中心、分散事件中心、混合部署、多区域部署和云原生体系结构等模式。这些模式有助于确保事件驱动系统中的可伸缩性、容错性、性能和弹性。它们解决了数据局部性、网络延迟、数据隐私和系统可靠性等问题，允许在整个部署基础设施中高效地分发和管理事件。

5-1，事件桥（Event Bridge）

事件桥接模式是事件驱动体系结构中常用的部署体系结构模式。它涉及使用两个相互连接的代理，使应用程序和服务能够通过桥接连接发送事件。这是通过在桥上设置订阅来实现的，这些订阅决定是否允许事件流过。

通过采用此模式，每个应用程序或服务都可以拥有其专用的事件代理。这些代理可以以点对点的方式相互连接，形成代理的临时网络。此外，代理可以是多个事件桥接的一部分。

与传统的集中式代理体系结构相比，这种分布式体系结构提供了几个优点，例如更大的可伸缩性、灵活性和容错性。通过跨多个代理分发事件处理工作负载，系统可以处理更多的事件，并且更容易扩展。根据系统的需要，可以将网桥配置为单向或双向。

在此模式中，每个应用程序或服务向其本地代理发布事件，然后由本地代理将事件分发给配置了订阅的事件桥的其他代理。然后，事件的订阅者可以使用来自其本地代理的事件。这种方法消除了对中央代理的需求，而中央代理可能成为大容量系统中的瓶颈。

了解更多

5-2，服务网格（Event Mesh）

事件驱动体系结构中的事件网格模式是一个相对较新的概念，它涉及创建一个相互连接的事件代理网络，允许跨不同系统和环境发布和使用事件。此模式旨在通过创建能够高效可靠地处理这些任务的网状代理网络，大规模地解决事件驱动体系结构的挑战，包括事件路由、发现和交付。

事件网格模式旨在支持跨复杂分布式系统（通常由多个应用程序、服务和数据存储组成）的事件驱动通信。通过创建一个相互连接的事件代理网络，此模式允许系统中的任何组件发布和使用事件，而不管其位置或技术堆栈如何。

事件网格模式的主要优点之一是它能够为事件驱动的通信提供分散和灵活的方法。使用事件网格，可以动态地添加或删除事件生产者和消费者，并且可以根据各种标准（如主题或内容）将事件路由到目的地。

除了提高事件驱动系统的可伸缩性和灵活性外，事件网格模式还可以提高它们的可靠性和弹性。通过利用多个代理来处理事件交付和故障转移，事件网格可以提供高可用性和容错性，即使在面对网络故障或组件中断时也是如此。事件网格模式代表了一种很有前途的方法，可以设计和部署事件驱动的体系结构，以满足现代分布式系统的复杂和不断发展的需求。

了解更多

5-3，事件网关（Event Gateway）

事件网关模式在事件网格或事件桥接中的代理之间充当连接和协调事件的重要组件，将其功能扩展到位于网格之外的边缘代理。作为事件的网关或入口点，它利用网关上配置的订阅设置，促进事件路由、转换和交付到边缘上的预期收件人。

事件网关模式建立在事件网格模式提供的优势之上，特别强调连接位于网络边缘的应用程序和系统。它支持中心事件网格或桥接器与分布式边缘代理之间的无缝通信，确保事件可以有效地传播到适当的目的地。

6，错误处理模式（Error Handling Patterns）

事件驱动体系结构中的错误处理模式包含一组策略和技术，用于管理事件驱动系统中发生的错误和异常。这些模式旨在处理错误并从错误中恢复，从而确保系统的可靠性和弹性。它们有助于解决事件处理失败、网络问题、服务不可用和数据不一致等场景。通过实现这些模式，事件驱动的体系结构系统可以有效地处理错误，最小化中断，并维护事件驱动的工作流和流程的完整性和稳定性。

6-1，死信队列（Dead Letter Queue）

在事件驱动的体系结构中，死信队列（DLQ）模式用于处理系统无法成功处理的消息。当消息处理失败时，通常会将其路由到死信队列，并将其存储在死信队列中，以后可以对其进行检查和重新处理。

DLQ模式用于防止由于错误或其他问题而无法处理的消息丢失或丢弃。通过将失败的消息路由到DLQ，可以通过修复导致失败的问题或手动重新处理消息来检查和处理这些消息。当消息由于TTL过期、超过最大再发送限制或权限问题而失去其可交付状态时，代理还可以将消息路由到DLQ。

实现DLQ需要配置消息代理或中间件，将失败的消息路由到单独的队列或日志。同样重要的是，要有适当的流程来监控DLQ，并采取行动解决发现的任何问题。

了解更多

6-2，丢弃、暂停和重试 （Discard, Pause and Retry）

"丢弃、暂停和重试"模式是事件驱动体系结构中常用的错误处理模式，用于处理消息处理失败。在此模式中，当出现消息处理错误时，可以通过以下三种方式之一处理该消息：

Discard：直接丢弃该消息，不做进一步处理。此选项通常用于可以安全地忽略的非关键消息。

暂停：消息被暂时暂停并保存在重试缓冲区中，直到导致失败的问题被解决。然后可以重试并再次处理该消息。

重试：立即或在指定的延迟后重试消息。如果经过一定次数的重试后消息处理仍然失败，则该消息将被丢弃或暂停。

此模式提供了一种以灵活和容错的方式处理消息处理错误的方法。通过丢弃非关键消息、暂停并重试失败的消息，或立即重试无法丢弃的消息，此模式确保即使在遇到故障时也能以及时可靠的方式处理消息。此外，它还提供了一种对消息处理进行优先级排序的方法，以便首先处理关键消息，而可以丢弃或稍后处理非关键消息。

了解更多

6-3，Saga

传奇模式是事件驱动体系结构中使用的一种模式，用于确保应用程序或流程的一致结果。它通常用作错误处理模式，因为它可以补偿事件驱动或流应用程序中发生的错误。saga是必须以正确顺序发生以确保特定结果的事务或操作的序列。

可以将传奇模式的实现视为构建自己的事务协调器。您可以创建一个组件来观察事务的执行，如果它检测到出现了错误，它就可以开始执行补偿逻辑。传奇模式确保任何错误或失败的事务都能被优雅地处理，允许应用程序恢复，而不会对最终用户体验产生任何负面影响。

通过在事件驱动的体系结构中使用传奇模式，您可以维护数据一致性，并确保以正确的顺序执行发生的任何事务。这有助于避免竞争条件、数据不一致以及使用分布式系统时可能出现的其他问题。

了解更多

7，治理模式（Governance Patterns）

事件驱动体系结构中的治理模式对于建立对事件驱动系统的访问、管理、安全性和监督的控制至关重要。这些模式侧重于建立指导方针、策略和框架，用于管理事件驱动的体系结构生态系统的各个方面。治理模式包括事件命名约定、版本控制和兼容性、安全性和访问控制、监视和审计以及文档标准等主题。通过实现治理模式，组织可以促进跨事件驱动系统的一致性、标准化和最佳实践。这些模式有助于维护系统完整性，增强团队之间的协作，支持有效的事件发现和管理，并支持事件驱动架构实现的长期可维护性和可伸缩性。

7-1，事件目录（Event Catalog）

事件目录模式为记录业务事件提供了一个集中的位置，使它们更易于使用。该模式包括一个事件开发人员门户，该门户提供对已发布事件的信息和文档的自助访问，类似于API开发人员门户对RESTful API的工作方式。此外，该模式利用公共/共享事件代理，允许轻松地使用业务事件。通过将事件文档集中在一个地方，event Catalog模式使开发人员能够更容易地发现和理解正在发布的事件，最终生成更有效的事件驱动应用程序。

通过维护事件的中心目录，可以更容易地管理系统中的不同事件，包括添加新事件、删除不推荐的事件和更新现有事件。这在大型复杂系统中尤其有用，因为在这些系统中，不同的服务产生和使用了许多不同的事件。事件编目应该包括每个事件的描述，包括其有效负载和任何相关的元数据以及发布状态。目录还可以包括关于每个事件的生产者和消费者的信息，以及在使用事件时需要考虑的任何依赖项或约束。

了解更多

7-2，Event APIs

事件驱动体系结构中的事件api模式是一种将事件视为一级api的设计模式。事件api模式不使用传统的请求-响应api，而是使用事件在服务之间进行通信。在此模式中，服务发布描述系统中状态变化的事件。然后，其他服务可以订阅这些事件，以便随时了解更改。

此模式的主要优点是它提供了服务之间松散耦合的异步通信。服务不需要知道彼此的api或实现细节，这使得独立发展服务变得更加容易。它还使生产者和消费者脱钩，允许在不影响生产者的情况下增加或删除消费者。通过传统API管理原则管理的关于版本控制、数据格式、文档、数据关系和表示的某些策略也可以应用于Event API。

要实现事件api模式，应该定义一个描述事件结构和元数据的事件模式。该模式充当生产者和消费者之间的契约，定义事件及其相关元数据的格式。一旦定义了模式，它就可以在生产者和消费者之间共享，以确保互操作性。

了解更多

7-3，中介的治理（Intermediated Governance）

中介治理指的是这样一种体系结构，它具有一个称为网关的组件，该组件拦截客户机和API之间的流量，并在此过程中应用治理规则（又名策略）。从本质上讲，网关托管和管理API代理，并在这些代理上实施策略，即，在将流量从客户机路由到所需的API之前，它将应用必要的安全和流量整形约束。

在讨论同步RESTful api时，这相当简单，但由于事件驱动架构的性质，这就变得复杂了。尽管中间仍然会有一个网关，而不是只有一个客户端和一个API，并且只需要限制对客户端的访问，但现在您有一个生产者和一个消费者，并且您需要限制对两者的访问。事件驱动API网关的另一个考虑因素是需要支持多种协议。生产者和消费者将利用相同的传输协议（慰藉/Kafka/JMS/MQTT/AMQP等），但由于它们并不完全相同，网关需要知道哪个策略应用于哪个协议。

基于网关的体系结构对于成本和延迟不是关键考虑因素的场景是理想的，并且基于网关的系统更容易管理，因为它们不会产生或需要额外的开发成本。

了解更多

7-4，去中介化的治理（Disintermediated Governance）

您还可以在没有网关的情况下实现事件驱动api的治理。您仍然需要一个"管理器"来处理策略的定义及其对各种通道的分配，但是如果生产者和消费者可以访问API管理器来下载与它们所连接的通道相关联的策略，并且能够在本地执行这些策略，则可能不需要网关。

在本例中，您实际上是将策略执行委托给生产者和消费者。例如，当开发人员为给定的AsyncAPI生成代码脚手架时，他们将拥有一个"治理SDK"或库，可以将其合并到实现中。

此模式实现了相同类型的关注点分离，但执行将由客户端（生产者/消费者）完成，而不是网关。其优点是对基础设施的操作影响较小，因为不需要部署和供应网关，因此基础设施开销和成本更少，并且对数据流没有延迟影响。直接治理模型的缺点是，它让开发人员有责任将治理整合到他们的应用程序和微服务中。

了解更多

7-5，访问控制和授权（Access Control and Authorization）

访问控制和授权模式侧重于根据定义的策略和权限控制和管理对系统中资源的访问，包括事件和事件驱动的组件。此模式确保只有经过授权的实体才有必要的特权来发布或使用事件，并在事件驱动的体系结构中执行特定的操作。

访问控制和授权的实现可以使用基于角色的访问控制（RBAC）或基于用户的访问控制策略来确保对事件驱动系统的访问是安全的，并遵循适当的访问控制实践。此模式有助于防止未经授权的访问，保护敏感信息，并维护事件驱动体系结构中事件的完整性和机密性。

了解更多

8，迁移模式（Migration Patterns）

事件驱动架构中的迁移模式指的是一组策略和技术，用于从现有实现（单体或事件驱动系统）过渡到另一个事件驱动系统，或者升级现有系统，同时尽量减少中断并确保平稳的迁移过程。这些模式解决了诸如数据迁移、模式演变、向后兼容性以及逐渐采用新组件或技术等挑战。它们帮助组织处理迁移到事件驱动系统的复杂性，确保连续性，保持数据完整性，并支持向新的或升级的体系结构的无缝过渡。

8-1，阻气门 （Strangler）

strangler模式是一种迁移模式，用于以可控和渐进的方式从单片（monolithic）应用程序逐步过渡到基于微服务的体系结构。此模式涉及识别单体中功能的内聚区域，将它们提取到独立的服务中，并用对新服务的调用替换单体功能。随着时间的推移，随着越来越多的功能迁移到新的服务上，这个庞然大物被"扼杀"了，直到这个庞然大物完全退役。

在事件驱动架构的上下文中，strangler模式可用于从单片应用程序中提取事件驱动的功能，并将其迁移到分布式、事件驱动的微服务架构中。这涉及到识别单体中的离散事件处理区域，将它们提取到独立的事件驱动服务中，并逐渐用对新服务的调用取代单体事件处理。

扼杀者模式可以有效地解决随着时间的推移而变得难以处理的大型、复杂的单片应用程序的挑战。它允许团队将大型、紧密耦合的系统分解成更小、更易于管理的部分，从而更容易开发、测试、部署和维护。通过用新服务逐步替换功能，该模式使团队能够按照自己的节奏进行迁移，从而最大限度地降低风险，并确保关键业务功能在转换过程中不会中断。

了解更多

8-2，数据同步（Data Synchronization）

在事件驱动的体系结构中使用Data Synchronization迁移模式，以确保迁移过程中不同系统或组件之间数据的一致传输和同步。在从一个事件驱动系统或其他软件系统（如数据库、大型机等）过渡到事件驱动架构时，这满足了维护数据完整性和一致性的需求。

根据源系统的类型，此模式有多种工具可供使用------CDC或复制适用于数据库源系统，连接器/适配器适用于大型机等遗留系统，如果源系统是另一个事件驱动系统，则使用事件重播。

了解更多

References

  1. Patterns for Distributed Systems
  2. Cloud Design Patterns
  3. Event-driven Architecture Patterns
  4. Enterprise Integration -- Messaging Patterns
  5. Enterprise Integration Patterns with WSO2 ESB
  6. Patterns in EDA
  7. Java Design Patterns
  8. A pattern language for microservices
  9. 6 Event-Driven Architecture Patterns
  10. Event-driven Solution
  11. Event-driven architecture
  12. EDA VISUALS -- Small bite sized visuals about event-driven architectures
  13. Event-driven architecture for microservices
  14. The Complete Guide to Event-Driven Architecture
  15. My TOP Patterns for Event Driven Architecture
  16. Event Driven Microservices Architecture Patterns and Examples | HPE Developer Portal
热门推荐
01【一文读懂】NTN（非地面网络）技术介绍02优化手机性能，解决卡顿问题：关闭这3个微信开关，释放内存空间03玄机平台应急响应—webshell查杀04Cube-Studio：开源大模型全链路一站式中台05基于大语言模型（LLM）的合成数据生成、策展和评估的综述06(欧拉)openEuler系统添加网卡文件配置流程、(欧拉)openEuler系统手动配置ipv6地址流程、(欧拉)openEuler系统网络管理说明07组基轨迹建模 GBTM的介绍与实现（Stata 或 R）08HCIA-datacom数通题库和录播视频资料09Docker 夺命连环 15 问10RAG 实践- Ollama+RagFlow 部署本地知识库