事件驱动型架构

事件驱动型架构是一种软件设计模式，其中微服务会对状态变化（称为“事件”）作出反应。事件可以携带状态（例如商品价格或收货地址），或者事件也可以是标识符（例如，订单送达或发货通知）。事件会触发协同工作以实现共同目标的微服务，但除了事件格式之外，无需相互了解任何信息。虽然微服务协同工作，但每个微服务都可以应用不同的业务逻辑，并发出自己的输出事件。

事件具有以下特征：

• 事件记录已经发生的事情。
• 事件捕获无法更改或删除的不可变事实。
• 无论服务在使用事件时是否应用任何逻辑，事件都会发生。
• 事件可以大规模无限期地持久保留，并且可以根据需要多次使用。

在事件驱动型系统中，事件由事件生成方生成，然后由事件路由器（或代理）提取并过滤，然后被扇出至适当的事件使用方（或接收器）。事件会根据一个或多个匹配的注册（使用 Eventarc 高级版时）或一个或多个匹配的触发器（使用 Eventarc 标准版时）定义的订阅转发给消费者。这三个组件（事件生成方、事件路由器、事件使用方）是脱耦的，可以独立部署、更新和扩缩：

事件路由器连接不同的服务，充当发送和接收消息的媒介。它对事件生成方生成的原始事件进行响应，并将此响应发送给适当的下游用户。事件是异步处理的，其结果会在服务对事件作出反应或受事件影响时决定，下图展示了一个简化的事件流：

何时使用事件驱动型架构

设计系统时，请考虑以下用法。

• 监控并接收提醒，了解存储桶、数据库表、虚拟机或其他资源的异常情况或更改。
• 将一个活动扇出到多个使用方。事件路由器会将事件推送到所有适当的使用者，您无需编写自定义代码。然后，每个服务可以并行但以不同方式处理事件。
• 在不同的技术栈之间提供互操作性，同时保持每个堆栈的独立性。
• 协调跨不同区域和账号运营和部署的系统和团队。您可以重新组织微服务的所有权。由于跨团队依赖项减少，您可以更快地对更改作出反应，而在非事件驱动型架构中，响应速度通常会受到数据访问权限壁垒的限制。

事件驱动型架构的优势

以下是构建事件驱动型架构的一些优势。

松散耦合和更好的开发者敏捷性

事件生成方与事件使用方在逻辑上是分开的。事件的生成与使用的分离意味着服务具有互操作性，但可以独立扩缩、更新和部署。

松散耦合可以减少依赖项，并可让您以不同的语言和框架实现服务。您无需更改任何一个服务的逻辑，即可添加或移除事件生成方和接收方。您无需编写自定义代码来轮询、过滤和路由事件。

异步事件和弹性

在事件驱动型系统中，事件是异步生成的，并且可以在事件发生时发出，而无需等待响应。松散耦合的组件意味着，如果一个服务失败，其他服务不受影响。如有必要，您可以记录事件，使接收服务可以从故障点恢复，或重放过去的事件。

基于推送的消息传递、实时事件流和更低的费用

事件驱动型系统支持基于推送的消息传递，客户端无需持续轮询远程服务的状态变化即可接收更新。这些推送的消息可用于即时数据处理和转换，以及实时分析。此外，由于轮询变少，网络 I/O 随之降低，费用也会减少。

简化审核和事件溯源

事件路由器的集中化位置可简化审核，允许您控制谁可以与路由器进行交互，以及哪些用户和资源有权访问您的数据。您还可以加密传输中的数据和静态数据。

此外，您还可以利用事件溯源这一架构模式，它可记录对应用状态所做的所有更改，并按照更改最初应用的顺序进行记录。事件溯源提供不可变事件的日志，这些保存的日志可以用于审核，用于重建历史状态，或者作为规范叙事来说明业务驱动的决策。

架构注意事项

事件驱动型架构可能要求您以新的方式设计应用。虽然事件驱动型架构非常适合使用微服务或解耦组件的应用，但您还应考虑以下事项：

• 如果您需要处理每个事件，您的事件来源是否可以保证传送？

  事件来源应该持久且可靠。

• 您的应用是否可以处理多个异步请求？

  您的系统性能不应依赖于全局范围或非弹性数据库。

• 您希望如何跟踪事件流？

  事件驱动型架构支持使用监控服务进行动态跟踪，但不支持使用代码分析进行静态跟踪。

• 您是否要使用事件来源中的数据重建状态？

  您应考虑如何确保数据去重和有序。

后续步骤

• 如需了解 Eventarc Advanced 如何处理事件，请参阅 Eventarc Advanced 概览。
• 如需了解 Eventarc Standard 如何处理事件，请参阅 Eventarc Standard 概览。