什么是事件驱动型架构（EDA）？
事件驱动型架构（EDA）是一种现代架构模式，由发布、使用或路由事件的小型解耦服务构建而成。
事件代表状态的变更或更新。例如：放入购物车的商品、上传到存储系统的文件或准备发货的订单。事件可以携带状态（例如订单中的商品名称、价格或数量），也可以仅包含查找相关信息所需的标识符（例如，“订单#8942 已发货”）。
与传统的请求驱动模型不同，EDA 促进了产生器和使用器服务之间的松耦合。这样就可以更加轻松地扩展、更新和独立部署系统的单独组件。
为什么解耦架构很重要？
许多组织发现，整体式应用程序、数据库和技术会对创新和用户体验的改进产生负面影响。遗留应用程序和数据库减少了您采用现代技术框架的选择，并限制了您的竞争力和创新。但是，当您对应用程序及其数据存储进行现代化改造时，它们会变得更容易扩展和更快地开发。
解耦数据策略提高了容错性和弹性，有助于加快新应用程序功能的上市时间（TTM）。
有关对整体式应用程序进行现代化改造的优势的更多信息，请参阅 AWS Prescriptive Guidance 中的在微服务中启用数据持久性。
事件驱动型架构（EDA）有哪些优势？
事件驱动型架构（EDA）可促进系统组件之间的松耦合，从而提高敏捷性。微服务可以独立扩展，失败时不会影响其他服务，并且可以降低工作流的复杂性。可以灵活地路由、缓冲和记录事件以用于审计目的。基于推送的事件流可以实时运行，从而降低了与创建和运行代码相关的成本，该代码不断地轮询系统以进行更改。
实现扩展和故障的独立性
通过解耦服务，事件驱动型架构中的组件可以独立扩展和失败，从而提高应用程序的弹性。随着服务之间集成数量的增加，这一点变得越来越重要。如果一个服务出现故障，其余的可以继续运行。
事件驱动的架构还可以简化近实时系统的设计，帮助组织摆脱基于批处理的处理。应用程序状态更改时会生成事件。处理事件的层可以随着事件的扩展而扩展。
事件通常发布到消息传递服务，其行为类似于微服务之间的弹性缓冲区，并且有助于处理扩展。事件也可能被发送到路由器服务，该服务可以根据事件的内容筛选和路由消息。因此，基于事件的应用程序可以比整体式应用程序更具可扩展性并提供更大的冗余。
敏捷开发
借助事件驱动型架构和事件路由器，开发人员不再需要编写自定义代码来轮询、筛选和路由事件。事件路由器会自动筛选事件并将其推送给使用器。该路由器还将消除产生器和使用器服务之间进行繁重协调的必要性，从而提高开发人员的敏捷性。
事件驱动型架构是基于推送的，这意味着当事件被发送到路由器和下游系统时，一切都按需发生，而无需通知相关服务。正因为如此，基础设施和资源可以随着事件量的增加和减少而扩展，从而降低处理工作负载和运行已部署应用程序的成本。
构建可扩展系统
事件驱动型架构也是高度可扩展的。其他团队可以在不影响现有微服务的情况下扩展特性和添加功能。通过发布事件，应用程序可以与现有系统集成 — 未来的应用程序可以作为事件使用器轻松集成，而无需更改现有解决方案。
事件产生器不了解事件使用器，因此扩展系统的摩擦较小，并且新功能或集成不会添加依赖项，进而拖慢未来开发的进度。
降低复杂性
微服务使开发人员和架构师能够分解复杂的工作流程。例如，他们可以将电子商务整体分解为具有单独库存、履行和会计服务的订单接受和支付流程。
在整体式应用中的管理和编排可能较为复杂的工作负载变成了一系列简单的、解耦的服务，这些服务被独立管理并通过事件消息异步通信。
事件驱动的方法使组装和编排以不同速率处理数据的服务成为可能。在以下示例中，订单接受微服务通过队列与支付处理系统交互。
在示例中，订单接受服务可以通过在队列中缓冲消息来存储大量传入订单。
由于处理支付的复杂性，支付处理服务通常较慢，它可以从队列中获取稳定的消息流。由于重试和错误处理逻辑，支付服务在各种系统状态之间转换。工作流服务根据系统状态编排和管理支付步骤，并最终产生更多库存、履行和会计服务感兴趣的事件。
轻松审核
事件驱动型架构中的事件路由器充当审核应用程序和定义策略的集中位置。这些策略可以限制谁能够发布与订阅到您的路由器，并控制哪些用户和资源有权限访问您的数据。您还可以对您的事件进行动态和静态加密。
削减成本
EDA 是基于推送的，因此一切都在事件本身出现在路由器中时按需发生。如此一来，您不用为持续轮询以检查事件付费。这意味着更少的网络带宽消耗、更低的 CPU 利用率、更少的闲置实例集容量，以及更少的 SSL/TLS 握手。
事件驱动型架构（EDA）的工作原理？
以下是适用于电商站点的事件驱动型架构（EDA）的示例：
%20for%20an%20ecommerce%20site.88b2240905b1b6addd672871b98bcb17bd44d701.jpg)
此示例站点显示了三个主要的事件产生器组件以及它们产生的事件。在这种情况下，事件路由器将摄取并筛选事件，然后将一个或多个事件发送给事件使用器。
此事件驱动型架构使网站能够对需求峰值期间的各种来源变动做出反应，而不会导致应用程序崩溃或过度预置资源。
哪些类型的工作负载适合事件驱动型架构（EDA）？
事件驱动型架构（EDA）可以提供一种有效的方式来满足高度可扩展和高度可用的工作负载的需求。EDA 也适用于具有不可预测或“高峰”流量模式的工作负载。
事件驱动型架构（EDA）如何改进应用程序？
事件驱动型架构（EDA）可以促进组件之间的松耦合，这使其成为构建现代分布式应用程序的好方法。
事件产生器不知道它们所生产的事件的下游使用器的任何活动，不为此担心，也不承担任何责任。事件本身代表状态的变化，可能包含也可能不包含数据。事件不知道它们存在的后果。使用器收听并处理感兴趣的事件。您可以在不中断现有工作流程的情况下让新使用器上线以提供新功能。
EDA 促进将整体式系统分解为更小的域模型。开发人员可以以更少的认知负荷快速上手，并更快地提高工作效率。当关键功能解耦时，部署更新和新功能的风险也更小。
有哪些常见的事件驱动型架构（EDA）使用场景？
Web 和移动后端的微服务通信
零售或媒体和娱乐网站通常必须纵向扩展以处理不可预测的流量。客户访问电子商务网站并下订单。订单事件被发送到事件路由器。所有下游微服务都可以获取订单事件进行处理。示例操作可能包括：提交订单、授权付款以及将订单详细信息发送给运输提供商。
由于每个微服务都可以独立扩展和失败，因此该流程可以在订单高峰期扩展而不会出现单点故障。
业务工作流程自动化
许多业务工作流程（例如金融服务交易）需要重复相同的步骤。您可以使用事件驱动型架构（EDA）来启动和自动化这些步骤。
例如，当客户向银行申请新账户时，银行必须进行一些数据检查（身份证明文件、地址等）。一些账户还需要人工批准阶段。您可以通过工作流服务编排所有这些步骤，该服务会在收到新账户申请时自动执行这些步骤。
您还可以添加一个工作流，通过机器学习异步处理客户应用程序数据以提取相关数据，这可能可以节省数小时的手动数据收集和验证时间。
SaaS 应用程序集成
软件即服务（SaaS）环境面临的最大挑战是缺乏对用户活动和数据的可见性。为了解锁孤立的数据，事件驱动型架构可以摄取 SaaS 应用程序事件或将事件发送到他们的 SaaS 应用程序。例如，您可以构建中间件来获取传入的合作伙伴订单数据并将订单直接发送到内部订单处理应用程序。
基础设施和自动化
在运行计算密集型工作负载（例如财务分析、基因组研究或媒体转码）时，您可以通过扩展计算资源以进行高度并行处理，然后在作业完成后缩减计算资源。
例如，在高度监管的行业中，拥有 EDA 的公司可以启动安全状态资源以响应事件，或者在安全策略发送警报事件时采取补救措施。
什么时候应该使用事件驱动型架构（EDA）？
事件驱动型架构（EDA）是快速提高敏捷性与进行移动的理想选择。它们常见于使用微服务的现代应用程序，或者有解耦组件的任何应用程序。
异构系统集成
如果您的系统在不同堆栈上运行，可以使用 EDA 在它们之间共享信息，而无需耦合。事件路由器会在系统之间建立间接性和互操作性，因此它们可以在保持独立性的同时交换消息和数据。
跨区域、跨账户数据复制
您可以使用 EDA，在跨不同 AWS 区域和账户进行操作与部署的团队之间协调系统。通过使用事件路由器在系统之间传输数据，您可以独立于其他团队开发、扩展和部署服务。
资源状态监控和警报
您可以利用 EDA 来监控与接收有关任何异常、变动和更新的警报，而不用持续检查您的资源。这些资源可能包括存储桶、数据库表、无服务器函数、计算节点等等。
扇出与并行处理
如果您需要操作多个系统以响应事件，则可以使用 EDA 对事件进行扇出，而不必编写自定义代码来推送到每个使用器。路由器会将事件推送到系统，每个系统可出于不同目的并行处理这些事件。
什么是常见的事件驱动型架构（EDA）模式？
许多简短的函数
创建多个较短的函数，而不是少量较大的函数。使函数专门针对您的工作负载意味着它们非常简洁，并且通常可以减少处理时间。每个函数都应该处理传递给它的事件，而不需要了解或预计整个工作流程或事务量。这使得函数与事件源无关，与其他服务的耦合最小。
按需处理而不是批量处理
许多传统系统设计为定期运行并处理随时间累积的批量事务。例如，银行应用程序可能每小时运行一次，将 ATM 交易处理到中央分类账中。
在事件驱动型架构（EDA）中，自定义处理可以响应每个事件。这允许服务根据需要扩展并发性，以近乎实时地处理事务。
中断恢复
在中断的情况下，可能会自动调用服务以重试事件处理。因为服务可能会多次接收相同的事件，所以函数设计为幂等。这可以确保结果不会在服务第一次接收事件后发生更改。
例如，如果零售商由于重试而尝试处理信用卡两次，则服务仅在第一次尝试时处理付款。在重试时，服务会验证支付状态并丢弃该事件。
事件驱动型架构（EDA）有哪些挑战？
在采用事件驱动型架构（EDA）时，您可能需要重新思考如何查看您的应用程序设计。
可变延迟
与可能在单个设备上处理相同内存空间内的所有内容的整体式应用程序不同，事件驱动应用程序跨网络通信。这种设计引入了可变延迟。尽管整体式应用程序可能具有更低或更少的可变延迟，但这通常是以牺牲可扩展性和可用性为代价的。
无服务器 AWS 服务具有高可用性，这意味着它们在一个 AWS 区域的多个可用区中运行。如果发生服务中断，服务会自动故障转移到备用可用区并重试事务。因此，事务可能会以更高的延迟成功完成，而不是失败。
需要一致的低延迟性能的工作负载不适合 EDA。银行中的高频交易应用或仓库中的亚毫秒机器人自动化就是其中的两个示例。
最终一致性
事件代表状态的变化。由于许多事件会在任一给定时间点流经架构中的不同服务，因此此类工作负载通常最终是一致的。 这使得处理事务、处理重复或确定系统的确切整体状态变得更加复杂。
由于需要 ACID 属性，一些工作负载不太适合 EDA。但是，许多工作负载包含最终一致性（例如，当前小时内的总订单）或强一致性（例如，当前库存）的需求组合。对于那些需要强数据一致性的特性，有一些架构模式可以提供支持。例如：
- 您可以将关系数据库用于需要 ACID 属性的功能，尽管任何关系数据库的可扩展性都低于 NoSQL 数据存储。
向调用者返回值
在许多情况下，基于事件的应用程序是异步的。这意味着调用者服务在继续其他工作之前不会等待来自其他服务的请求。EDA 的这一基本特征实现了可扩展性和灵活性；但是，它使传递返回值或工作流结果比在同步流中更复杂。
在许多情况下，返回一个值不如确保事件处理的成功或失败重要。确保事件处理的功能可能比将值返回给调用者更重要。
对于交互式工作负载，例如 Web 和移动应用程序，最终用户通常希望收到返回值或交易的当前状态。对于这些工作负载，有几种设计模式可以将各种事件处理返回给调用者。但是，事件驱动型架构中的这些实施比使用传统的异步返回值更复杂。该平台通常可以减轻这种复杂性。
跨服务和功能调试
调试事件驱动系统不同于调试整体式应用程序。与所有基于微服务的应用程序以及传递事件的不同系统和服务一样，在发生错误时记录和重现多个服务的确切状态可能是一项挑战。由于每个服务和函数调用都有单独的日志文件，因此确定导致错误的特定事件发生了什么可能会更加复杂。
编排
随着时间的推移，简单的工作流程变得更加复杂是很常见的。在典型的整体式应用中，这可能导致更紧密耦合的功能和服务组，以及复杂的代码处理路由和异常。
为了跟踪系统的状态，涉及分支逻辑、不同类型的故障模型和重试逻辑的工作流通常会使用编排工具。在创建事件驱动的无服务器应用程序时，重要的是要确定这种情况何时发生，以便您可以将此逻辑迁移到状态机以进行适当的编排。
哪些 AWS 服务使用事件驱动型架构（EDA）？
AWS 服务通常会产生或使用事件，从而可以轻松构建具有事件驱动型架构（EDA）的解决方案。
此外，Amazon EventBridge、Amazon SNS、Amazon SQS 和 AWS Step Functions 等服务包括可帮助客户编写更少样板代码并更快构建 EDA 的功能。
Amazon EventBridge
您可以使用 Amazon EventBridge，通过来自 SaaS 应用程序、其他 AWS 服务或自定义应用程序的事件为事件驱动的应用程序大规模构建事件总线。
EventBridge 应用规则将事件从事件源路由到不同的目标。目标可以包括 AWS 服务，例如 AWS Lambda、Step Functions 和 Amazon Kinesis，或通过 EventBridge API 目标的任何 HTTP 端点。
EDA 用例的一个热门集成是 Step Functions，其中，事件会触发特定工作流。
AWS Step Functions
AWS Step Functions 包括 Workflow Studio，这是一种低代码可视化工作流设计器，构建者可以使用它来编排不同的 AWS 服务。您可以使用 Workflow Studio 构建分布式应用程序、自动化 IT 和业务流程，以及使用 AWS 服务构建数据和机器学习管道。
Amazon SNS
我们建议使用 Amazon Simple Notification Service (Amazon SNS) 来构建对其他应用程序、微服务或 AWS 服务发布的高吞吐量和低延迟事件做出响应的应用程序。您还可以将 Amazon SNS 用于需要对数千甚至数百万个端点进行高扇出的应用程序。
Amazon SQS
Amazon Simple Queue Service (Amazon SQS) 提供安全、持久且可用的托管队列服务，您可以使用它来集成和分离分布式软件系统和组件。Amazon SQS 提供常见的结构，例如死信队列和成本分配标签。
