1.什么是事件驱动型架构（EDA）？

Simply put, the event is a significant change in state, which is triggered when a user takes an action.

事件，本质上就是运动，变化，跟“函数”、“消息”、“操作”、“调用”、“算子”、“映射”等概念全息。

EDA（Event-Driven Architecture）是什么?EDA是一种软件体系结构，用于促进事件的生产、检测、处理和响应。事件可以是多种多样的，比如一个司机拿起一个包，一个机器测量达到一个阈值，或者一个特定的客户到达一个零售店。EDA由三个属性定义。首先，它有选择地将相关事件从传入数据传输到数据库。其次，它处理来自多个源的复杂事件，这些事件可以实时地相互影响。第三，它通过推式操作简化了实时服务。事件驱动架构的用例示例包括滴滴和Uber等资产共享解决方案、分配维护人员和备件的规定维护系统或动态客户服务应用程序。

事件驱动型架构（EDA）是一种现代架构模式，由发布、使用或路由事件的小型解耦服务构建而成。

事件代表状态的变更或更新。例如：放入购物车的商品、上传到存储系统的文件或准备发货的订单。事件可以携带状态（例如订单中的商品名称、价格或数量），也可以仅包含查找相关信息所需的标识符（例如，“订单#8942 已发货”）。

与传统的请求驱动模型不同，EDA 促进了产生器和使用器服务之间的松耦合。这样就可以更加轻松地扩展、更新和独立部署系统的单独组件。

2.为什么解耦架构很重要？

许多组织发现，整体式应用程序、数据库和技术会对创新和用户体验的改进产生负面影响。遗留应用程序和数据库减少了您采用现代技术框架的选择，并限制了您的竞争力和创新。但是，当您对应用程序及其数据存储进行现代化改造时，它们会变得更容易扩展和更快地开发。

解耦数据策略提高了容错性和弹性，有助于加快新应用程序功能的上市时间（TTM）。

3.事件驱动型架构（EDA）有哪些优势？

事件驱动型架构（EDA）可促进系统组件之间的松耦合，从而提高敏捷性。微服务可以独立扩展，失败时不会影响其他服务，并且可以降低工作流的复杂性。可以灵活地路由、缓冲和记录事件以用于审计目的。基于推送的事件流可以实时运行，从而降低了与创建和运行代码相关的成本，该代码不断地轮询系统以进行更改。

实现扩展和故障的独立性

通过解耦服务，事件驱动型架构中的组件可以独立扩展和失败，从而提高应用程序的弹性。随着服务之间集成数量的增加，这一点变得越来越重要。如果一个服务出现故障，其余的可以继续运行。

事件驱动的架构还可以简化近实时系统的设计，帮助组织摆脱基于批处理的处理。应用程序状态更改时会生成事件。处理事件的层可以随着事件的扩展而扩展。

事件通常发布到消息传递服务，其行为类似于微服务之间的弹性缓冲区，并且有助于处理扩展。事件也可能被发送到路由器服务，该服务可以根据事件的内容筛选和路由消息。因此，基于事件的应用程序可以比整体式应用程序更具可扩展性并提供更大的冗余。

敏捷开发

借助事件驱动型架构和事件路由器，开发人员不再需要编写自定义代码来轮询、筛选和路由事件。事件路由器会自动筛选事件并将其推送给使用器。该路由器还将消除产生器和使用器服务之间进行繁重协调的必要性，从而提高开发人员的敏捷性。

事件驱动型架构是基于推送的，这意味着当事件被发送到路由器和下游系统时，一切都按需发生，而无需通知相关服务。正因为如此，基础设施和资源可以随着事件量的增加和减少而扩展，从而降低处理工作负载和运行已部署应用程序的成本。

构建可扩展系统

事件驱动型架构也是高度可扩展的。其他团队可以在不影响现有微服务的情况下扩展特性和添加功能。通过发布事件，应用程序可以与现有系统集成 — 未来的应用程序可以作为事件使用器轻松集成，而无需更改现有解决方案。

事件产生器不了解事件使用器，因此扩展系统的摩擦较小，并且新功能或集成不会添加依赖项，进而拖慢未来开发的进度。

降低复杂性

微服务使开发人员和架构师能够分解复杂的工作流程。例如，他们可以将电子商务整体分解为具有单独库存、履行和会计服务的订单接受和支付流程。

在整体式应用中的管理和编排可能较为复杂的工作负载变成了一系列简单的、解耦的服务，这些服务被独立管理并通过事件消息异步通信。

事件驱动的方法使组装和编排以不同速率处理数据的服务成为可能。在以下示例中，订单接受微服务通过队列与支付处理系统交互。

在示例中，订单接受服务可以通过在队列中缓冲消息来存储大量传入订单。

由于处理支付的复杂性，支付处理服务通常较慢，它可以从队列中获取稳定的消息流。由于重试和错误处理逻辑，支付服务在各种系统状态之间转换。工作流服务根据系统状态编排和管理支付步骤，并最终产生更多库存、履行和会计服务感兴趣的事件。

轻松审核

事件驱动型架构中的事件路由器充当审核应用程序和定义策略的集中位置。这些策略可以限制谁能够发布与订阅到您的路由器，并控制哪些用户和资源有权限访问您的数据。您还可以对您的事件进行动态和静态加密。

削减成本

EDA 是基于推送的，因此一切都在事件本身出现在路由器中时按需发生。如此一来，您不用为持续轮询以检查事件付费。这意味着更少的网络带宽消耗、更低的 CPU 利用率、更少的闲置实例集容量，以及更少的 SSL/TLS 握手。

3.事件驱动型架构（EDA）的工作原理？

以下是适用于电商站点的事件驱动型架构（EDA）的示例：

此示例站点显示了三个主要的事件产生器组件以及它们产生的事件。在这种情况下，事件路由器将摄取并筛选事件，然后将一个或多个事件发送给事件使用器。

此事件驱动型架构使网站能够对需求峰值期间的各种来源变动做出反应，而不会导致应用程序崩溃或过度预置资源。

4.有哪些常见的事件驱动型架构（EDA）使用场景？

Web 和移动后端的微服务通信

零售或媒体和娱乐网站通常必须纵向扩展以处理不可预测的流量。客户访问电子商务网站并下订单。订单事件被发送到事件路由器。所有下游微服务都可以获取订单事件进行处理。示例操作可能包括：提交订单、授权付款以及将订单详细信息发送给运输提供商。

由于每个微服务都可以独立扩展和失败，因此该流程可以在订单高峰期扩展而不会出现单点故障。

业务工作流程自动化

许多业务工作流程（例如金融服务交易）需要重复相同的步骤。您可以使用事件驱动型架构（EDA）来启动和自动化这些步骤。

例如，当客户向银行申请新账户时，银行必须进行一些数据检查（身份证明文件、地址等）。一些账户还需要人工批准阶段。您可以通过工作流服务编排所有这些步骤，该服务会在收到新账户申请时自动执行这些步骤。

您还可以添加一个工作流，通过机器学习异步处理客户应用程序数据以提取相关数据，这可能可以节省数小时的手动数据收集和验证时间。

SaaS 应用程序集成

软件即服务（SaaS）环境面临的最大挑战是缺乏对用户活动和数据的可见性。为了解锁孤立的数据，事件驱动型架构可以摄取 SaaS 应用程序事件或将事件发送到他们的 SaaS 应用程序。例如，您可以构建中间件来获取传入的合作伙伴订单数据并将订单直接发送到内部订单处理应用程序。

基础设施和自动化

在运行计算密集型工作负载（例如财务分析、基因组研究或媒体转码）时，您可以通过扩展计算资源以进行高度并行处理，然后在作业完成后缩减计算资源。

例如，在高度监管的行业中，拥有 EDA 的公司可以启动安全状态资源以响应事件，或者在安全策略发送警报事件时采取补救措施。

5.什么时候应该使用事件驱动型架构（EDA）？

事件驱动型架构（EDA）是快速提高敏捷性与进行移动的理想选择。它们常见于使用微服务的现代应用程序，或者有解耦组件的任何应用程序。

异构系统集成

如果您的系统在不同堆栈上运行，可以使用 EDA 在它们之间共享信息，而无需耦合。事件路由器会在系统之间建立间接性和互操作性，因此它们可以在保持独立性的同时交换消息和数据。

跨区域、跨账户数据复制

您可以使用 EDA，在跨不同 AWS 区域和账户进行操作与部署的团队之间协调系统。通过使用事件路由器在系统之间传输数据，您可以独立于其他团队开发、扩展和部署服务。

资源状态监控和警报

您可以利用 EDA 来监控与接收有关任何异常、变动和更新的警报，而不用持续检查您的资源。这些资源可能包括存储桶、数据库表、无服务器函数、计算节点等等。

扇出与并行处理

如果您需要操作多个系统以响应事件，则可以使用 EDA 对事件进行扇出，而不必编写自定义代码来推送到每个使用器。路由器会将事件推送到系统，每个系统可出于不同目的并行处理这些事件。

6.什么是常见的事件驱动型架构（EDA）模式？

许多简短的函数

创建多个较短的函数，而不是少量较大的函数。使函数专门针对您的工作负载意味着它们非常简洁，并且通常可以减少处理时间。每个函数都应该处理传递给它的事件，而不需要了解或预计整个工作流程或事务量。这使得函数与事件源无关，与其他服务的耦合最小。

按需处理而不是批量处理

许多传统系统设计为定期运行并处理随时间累积的批量事务。例如，银行应用程序可能每小时运行一次，将 ATM 交易处理到中央分类账中。

在事件驱动型架构（EDA）中，自定义处理可以响应每个事件。这允许服务根据需要扩展并发性，以近乎实时地处理事务。

中断恢复

在中断的情况下，可能会自动调用服务以重试事件处理。因为服务可能会多次接收相同的事件，所以函数设计为幂等。这可以确保结果不会在服务第一次接收事件后发生更改。

例如，如果零售商由于重试而尝试处理信用卡两次，则服务仅在第一次尝试时处理付款。在重试时，服务会验证支付状态并丢弃该事件。