事件驱动型架构

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

事件具有以下特征:

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

在事件驱动型系统中,事件由事件生成方生成,然后由事件路由器(或代理)提取并过滤,然后被扇出至适当的事件使用方(或接收器)。事件会被转发到由一个或多个匹配触发器定义的订阅者。这三个组件(事件生成方、事件路由器、事件使用方)是脱耦的,可以独立部署、更新和扩缩:

事件代理和订阅者

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

事件驱动型架构

何时使用事件驱动型架构

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

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

事件驱动型架构的优势

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

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

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

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

异步事件和弹性

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

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

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

简化审核和事件溯源

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

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

架构注意事项

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

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

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

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

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

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

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

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

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

后续步骤