什么是事件驱动型架构?

企业越来越需要能够对各种触发因素(从客户互动到传感器读数)做出即时反应的系统。传统的请求-响应模型虽然很有价值,但可能无法始终为这些动态环境提供必要的敏捷性或可伸缩性。事件驱动型架构 (EDA) 可以为构建响应迅速、弹性好且可扩缩的应用提供强大的范例。这是一种软件架构模式,可以促进事件的生成、检测、使用和回应。

了解事件驱动型架构

事件驱动型架构的定义

事件驱动型架构是一种用于设计软件应用的模式,其中服务是松散耦合的,并通过生成和使用事件进行通信。“事件”表示有意义的发生或系统状态的变化。这可能是客户下订单、传感器检测到温度变化、新文件上传到存储空间或数据库记录更新等任何事件。

与传统请求驱动型模型(其中一项服务明确调用另一项服务并等待响应)不同,EDA 允许服务异步运行。生成事件的服务(“提供方”或“发布方”)只需宣布事件已发生。其他对该类型事件感兴趣的服务(“使用方”或“订阅方”)可以独立地在自己的时间对该事件做出反应。

EDA 中的关键组件通常包括:

  • 事件提供方:生成事件的应用或服务
  • 事件使用方(或订阅方):接收和处理事件的应用或服务
  • 事件通道(或事件总线、消息代理、事件路由器):从提供方提取事件并进行过滤,然后将事件传递给感兴趣的使用方的中间基础设施;此组件对于将提供方与使用方分离至关重要

事件驱动型架构如何运作?

事件驱动型架构中的工作流通常遵循一致的模式。

  • 事件发生和生成:服务或系统内发生重大操作。例如,用户可能会点击电子商务网站上的“提交订单”按钮。负责处理此初始操作的服务(事件生成器)会生成一个事件对象,其中包含有关所发生事件的相关信息,例如订单 ID、商品和客户详细信息。
  • 事件传输:提供方将此事件发送到事件渠道。此渠道是一个专用的基础设施,例如消息队列或发布-订阅 (pub/sub) 系统,旨在处理事件流。
  • 事件过滤和路由(按事件渠道):事件渠道接收事件。然后,它可能会应用过滤规则,或根据事件的类型、内容或主题,将事件路由到已注册对这类事件感兴趣的各种下游使用方。例如,“order_placed”事件可能会路由到库存服务、通知服务和配送服务。
  • 事件使用和处理:感兴趣的服务(使用方)从渠道接收事件。每个使用方都会异步且独立地处理事件。继续以电子商务为例:
  • 库存服务可能会减少所订购商品的库存水平
  • 通知服务可以向客户发送订单确认邮件
  • 配送服务可能会启动物流流程

事件驱动型架构的优势

采用事件驱动型架构可以带来许多优势,尤其对于复杂的分布式系统而言。

增强可伸缩性

EDA 中的服务是松散耦合的,可以独立扩缩。如果“订单处理”服务负载过重,您可以只扩容该服务,而不会影响“用户通知”服务等其他服务。

提高弹性和容错能力

事件驱动型架构可以通过隔离服务故障来帮助提高应用的稳健性。这种分离特性可确保一个使用方服务中的故障通常不会传播并导致整个系统发生故障。

提高敏捷性和灵活性

开发者可以添加、修改或移除服务,而对系统的其他部分几乎没有影响。新服务可以订阅现有事件流,以添加新功能,而无需更改原始事件提供方。

实时响应

事件驱动型架构有助于系统以显著的即时性响应事件。对于需要快速采取行动的应用(包括欺诈检测、实时分析和运营监控),此功能尤其有价值。

简化的集成

EDA 可作为灵活的骨干,用于集成不同的系统,包括旧版应用、现代微服务和第三方服务。每个系统都可以发布和使用事件,而无需与其他每个系统进行直接的点对点集成。

可扩展性

添加新功能或以新方式对现有事件做出反应,通常只需要部署订阅相关事件流的新消费者服务。

利用 Google Cloud 解决业务难题

新客户可获得 $300 赠金,用于抵扣 Google Cloud 的费用。

事件驱动型架构的应用场景

EDA 的特性使其非常适合各个行业的各种应用。

EDA 是一种常见模式,用于实现微服务之间的通信和数据流。微服务可以在状态发生变化时发布事件,其他微服务可以订阅这些事件并做出相应反应,而不是直接进行同步 API 调用,这样可能会导致紧密耦合。

处理高速数据流的应用(例如 IoT 传感器数据、应用日志、社交媒体动态或金融市场数据)可以使用 EDA 实时处理、分析这些信息并做出反应。这有助于为信息中心、提醒系统或自动化决策流程提供支持。

从根据销售情况管理库存水平,到处理各个阶段(付款、发货、履单)的订单,再到发送客户通知,EDA 可以帮助管理线上零售中固有的复杂异步工作流。如果付款处理服务速度较慢,订单事件仍可由库存预订等其他服务捕获和处理。

许多业务流程本质上都是事件驱动的。例如,提交保险索赔(事件)可以触发一系列下游活动:欺诈检查、评估、客户沟通,最后是付款处理。EDA 可以帮助有效地对这些工作流进行建模和自动化。

当需要在多个系统或数据存储区之间保持数据一致性时,可以使用 EDA。一个数据库中的更改(事件)可以发布,允许其他数据库或缓存订阅这些更改事件并自行更新。

无服务器函数(如 Cloud Run 函数)通常设计为事件驱动型。它们会响应各种事件触发器来执行,例如将对象上传到云端存储空间、消息到达队列或 HTTP 请求。EDA 非常适合使用无服务器组件构建应用。

实时欺诈检测、股市监控和交易处理是关键的金融应用,它们受益于 EDA 的低延迟和高吞吐量功能。

Google Cloud 如何使用事件驱动型架构?

Google Cloud 提供了一套强大的服务,可帮助客户构建和部署强大的事件驱动型应用。该平台本身利用事件驱动原则来帮助提供可扩缩且弹性的服务。对于构建事件驱动型解决方案的客户,Google Cloud 提供以下几项关键的托管式服务:

  • Pub/Sub:这是一种覆盖全球、可扩缩且可靠的实时通讯服务,在 EDA 中充当事件总线或消息代理。Pub/Sub 可帮助服务发布事件,并帮助其他服务异步订阅这些事件。它将发布方与订阅方分离,并支持“至少一次”传送、推送和拉取订阅以及消息过滤等功能。
  • Eventarc:Eventarc 可以将事件来源(例如 Cloud Storage 存储桶更改、BigQuery 作业完成或自定义应用事件)连接到事件使用方,从而提供一种标准化方式来管理事件流。它允许开发者轻松触发 Cloud Run 服务、Cloud Run functions 或 Workflows 来响应事件。
  • Cloud Run:借助这个全托管式计算平台,您可以运行无状态容器,并通过 HTTP 请求或来自 Pub/Sub 的事件(通常通过 Eventarc)调用这些容器。使用 Cloud Run functions,您可以部署小型、单一用途的代码段(函数),这些代码段可以响应各种事件,而无需管理服务器或运行时环境。在事件驱动型架构中,Cloud Run 服务可以作为事件使用方发挥非常有效的作用,处理由这些事件触发的工作负载。
  • Workflows:一个全托管式编排平台,可让您定义、部署和管理无服务器工作流。Workflows 可以由事件(通过 Eventarc 或 Pub/Sub)触发,并且可以协调对各种 Google Cloud 服务和基于 HTTP 的 API 的调用,这使得它们非常适合编排复杂的事件驱动型业务流程。
  • Dataflow:对于复杂事件处理 (CEP) 和数据流分析,Dataflow 可以提供统一的流式数据和批量数据处理平台。它可以从 Pub/Sub 提取事件流,执行复杂的转换、汇总和分析,然后将结果输出到其他系统或触发进一步的操作。

更进一步

获享 $300 赠金以及 20 多种提供“始终免费”用量的产品,开始在 Google Cloud 上构建项目。