什么是事件驱动型架构？

它使团队能够识别系统事件（基本上是系统中发生的任何变化或操作），并实时（或近实时）地对其做出响应和反应。

在云原生环境中，事件驱动架构 (EDA) 的激增标志着从传统计算架构的一次重大转变，传统架构侧重于将静态数据存储在数据湖（如面向服务的架构中）等存储库中，现在则转向一种在数据穿越架构时进行跟踪的动态方法。数据在事件驱动系统中仍然具有价值，但 EDA 更强调对事件的及时响应，认识到事件的价值可能会随着时间的推移而下降。

在事件驱动架构中，事件生产者（如微服务、API 和 物联网设备）向事件使用者发送实时事件通知，事件使用者随后触发特定的处理流程。例如，当 Netflix 发布新的原创剧集时，多个 EDA 服务处于待命状态等待发布通知，这会触发级联更新以通知用户。

事件驱动架构的一个关键优势是前端和后端组件之间的解耦关系，这使得系统能够在彼此不直接了解的情况下共享信息。生产者可以在不知晓哪一个使用者会接收事件的情况下发送事件，而使用者也可以在不向生产者发送请求的情况下接收事件。换言之，EDA 可使系统独立工作，并异步处理事件。

现代、具有前瞻性的企业拥有庞大的数字足迹，而事件驱动系统的实时功能使企业能够在不闲置的情况下保持运营准备，并快速响应事件广播。因此，EDA 可帮助企业实现从优化供应链到主动识别质量问题等一系列组织流程的自动化，并最终改善企业的盈亏状况。

事件流围绕着被称为“事件”的数据记录的无界、顺序和实时流动展开，这些事件是基础数据结构，用于记录系统或环境中发生的任何事件或变化。此类变化的示例包括用户在电子商务网站上将商品添加到购物车、请求重置密码，或应用程序状态的变化。该术语本质上是指系统中每个数据点。“流”（也称为数据流或流数据）是指这些事件的持续传递。

每个事件通常包括一个标识事件或与其相关的实体的键、一个保存事件实际数据的值、一个指示事件发生或记录时间的时间戳，有时还包括有关事件源、架构版本或其他属性的元数据。它们可以携带状态数据（例如购买的商品、价格和送货地址），也可以作为标识符（例如运输通知）。

在专用流处理引擎的帮助下，事件可以在流中经历几个不同的过程。“聚合”执行数据计算，例如平均值、总和和标准差。“摄取”将流数据添加到数据库。分析处理使用流数据中的模式来预测未来事件，而丰富处理将数据点与其他数据源相结合，以提供上下文并创造意义。

事件通常与业务操作或用户导航流程相关联，通常会触发另一个操作、流程或一系列事件。以网上银行为例。 当用户点击“转账”，以将资金从一个银行账户汇款到另一个银行账户时，资金将从汇款人的账户中提取并添加到收款人的银行账户中，同时向一方（或双方）发送电子邮件或短信通知，必要时还会部署安全和欺诈预防协议。

除了事件之外，EDA 还依靠三个主要组件在架构中移动事件数据。

• 事件生产者（或发布者）：生产者是事件的源头；他们生成事件并将其发送给系统的其他部分。生产者可以是用户界面、传感器、服务，或任何能够检测或产生对系统其他部分有意义的状态变化的系统。虽然生产者负责创建事件，但它们没有事件处理功能。

• 事件使用者（或订阅者）：使用者在 EDA 中处理事件处理任务。它们监听事件通道，并在感兴趣的事件被发布时作出响应。该反应可以有多种形式，包括更新数据库、触发下游流程或只是记录信息。

• 事件路由器（或事件编排器）：路由器或编排器是将前端事件生产者与后端事件使用者解耦的代理，它们充当事件传递的通道，确保事件在无需实体间直接连接的情况下完成传输。路由器可以基于传统组件（例如 SaaS 等面向消息的中间件），并且在一系列消息传递系统（消息队列、发布/订阅模型、事件流等）中很有用。

在 EDA 中，事件驱动型应用程序充当生产者或使用者（有时两者兼而有之）。

当一个应用程序或服务执行另一个应用程序或服务可能想了解的操作时，它会发布一个新事件（该操作或更改的记录），另一个服务可以使用和处理该新事件以执行其他操作。

然后，事件生产者以消息的形式将事件传递给代理或其他类型的事件路由器，由其维护该事件相对于其他事件的时间顺序。事件使用者实时（在发生消息发生时）或在稍后的相关实例中采集消息，并处理该消息以触发另一个操作、工作流或事件。

举一个简单的例子，某银行服务可能会发送一个“存款”事件，另一银行服务接收到该事件后，会作出响应，在客户的账单中记录这笔存款。

但是，事件驱动型整合还可以根据对海量数据的复杂分析触发实时响应，例如当客户在电子商务网站上点击某个产品时，系统会根据其他客户的购买情况生成即时产品推荐。

事件驱动架构可最大限度地发挥云原生应用的潜力，并实现强大的应用技术，如实时分析。总体而言，它们取代了传统的“请求/响应”架构，在这种架构中，一个应用程序必须向另一个应用程序请求特定信息，并等待回复，然后才能继续执行下一个任务。

但是，“EDA”是一个包含多种架构模式的术语，所有架构模式均可用于不同的目的：

在发布/订阅模型中（由对象之间的一对多依赖关系以及发布者（事件生产者）和使用者之间的解耦异步关系定义），发布者不需要了解订阅者。它只是将事件发布到共享事件通道，订阅者可以在该通道中独立实时监听事件并做出反应。

通常情况下，消息代理（路由器）负责处理发布者和订阅者之间的事件消息传输。代理接收每条事件消息，对其进行转换（如有必要），维护其相对于其他消息的顺序，使其可供订阅者使用，然后在使用后将其删除（因此无法再次使用）。

发布/订阅消息模式非常适合拥有大型代码库的企业，以及向多个使用者广播信息（例如，用于通知系统和实时数据馈送）。

与发布/订阅一样，事件流将发布者和使用者解耦以实现异步通信。然而，在事件流模型中，事件使用者并不需要订阅这些流；相反，生产者将事件流发布到代理日志中，使用者可以在任意时间点接入某个事件流，并只使用自己想要的事件（而不是接收并处理所有已发布的事件）。

然而，与发布/订阅不同的是，事件流代理即使在使用者收到事件后也会保留事件。

由于使用者可以在事件发布后随时处理事件，因此事件流记录是持久性的。这意味着这些事件会被保留一段可配置的时间（从几分之一秒到永久保存不等）。使用者可以在任意时间访问事件流，以读取最新消息、批量处理自上次访问以来的一系列消息，或引用近期的相关消息。

事件流技术（例如 Apache Kafka、亚马逊网络服务 (AWS) Kinesis 和 IBM Event Automation）也包括两种模型：拉动模型（只有当使用者表示愿意接受事件时，代理才发送使用者数据）和推送模型（代理的业务逻辑决定哪些使用者接收事件）。

事件流模式对于既需要实时事件更新又需要访问过去事件的应用程序最有用（例如，金融机构的欺诈检测系统）。

除了两种主要的 EDA 架构模式外，还有三种设计模式决定事件到达订阅者后如何被处理。

• 简单事件处理：使用者在从发布者处收到事件时对其进行处理，触发即时行动。

• 事件流处理 (ESP)：数据流平台采集事件并为流处理器建立管道，然后由流处理器对流进行处理和转换。
  
  
• 复杂事件处理 (CEP)：使用者处理一系列事件，以识别数据中的趋势和模式。

所有三种处理模式（以及其他模式）都可以在发布/订阅和事件流架构模式中使用，但 ESP（事件处理服务）在事件流架构模式中（自然地）最为常见。

EDA 对各行各业的企业都很有用，但对于拥有大型、复杂IT 环境的企业来说，它们尤其有价值。

例如，如果企业试图整合在不同技术堆栈中运行的系统，可以利用事件驱动架构的解耦特性，使事件数据与系统无关，从而提升互操作性。跨国公司可以使用 EDA 来协调跨账户和区域的系统，从而促进架构不同部分的独立扩展。对于每个系统处理事件不同部分的企业，EDA 的分发功能可以将事件推送给各个使用者（无需新增代码）以在整个系统中进行并行处理。

在电子商务中，事件驱动架构可以实时过滤和路由事件，以确保它们只发送给对其数据感兴趣的订阅者。新订单会直接发送给订单处理使用者，订单问题会直接路由到客户服务渠道，依此类推。

事件驱动架构正变得至关重要，以帮助当今的企业跟上市场节奏，并引领其迈向未来。事实上，已有近 37% 的公司计划采用 EDA 来满足业务需求，还有 26% 的组织正在计划采用 EDA。¹到 2027 年，EDA 软件行业的规模预计将翻一番，收入达到 165 亿美元以上。 ²

每天成千上万的业务事件流经组织的各个部门，这些事件提供了丰富的信息，让企业能够随时了解业务的运行情况。然而，如果没有适当的技术，许多企业就无法处理和使用这些数据，从而就其客户、产品或业务做出明智的决策。

正是在这种情况下，EDA 平台变得至关重要，它能够实现高吞吐量、低延迟自动化，并为各种用例提供高级工具，包括：

事件驱动架构通过实时捕捉业务事件、迅速响应、自动化决策并充分挖掘收益潜力，让业务数据创造实际价值。EDA 还可以通过以下方式帮助企业维持和加速增长：

EDA 使系统能够通过增加更多服务实例来处理增加的工作量，从而实现扩展。

EDA 使组件能够异步通信；生产者按照自己的时间表发布事件消息，无需等待使用者接收（甚至无需知道使用者是否已接收），从而简化了整合和用户体验。

可独立添加、删除或修改服务，从而促进敏捷开发和部署实践。

EDA 在时间和同步方面解耦，因此事件生产者和使用者可通过事件（而不是直接的 API 调用）进行交互，从而减少依赖关系并提高整体系统弹性。

EDA 本质上是为实时处理和响应而设计的，它使团队能够更主动地响应并促进更智能的操作和自动化。