Eventarc 概览

借助 Eventarc,您可以构建事件驱动型架构,而无需实现、自定义或维护底层基础架构。Eventarc 提供了一个用于管理解耦的微服务之间的状态更改(称为“事件”)流的标准化解决方案。触发后,Eventarc 会将这些事件路由到各个目的地(在本文档中,请参阅事件目的地),同时理传送、安全、授权、可观测性和错误处理。

您可以通过 Google Cloud 控制台、从命令行(使用 gcloud CLI)或使用 Eventarc API 来管理 Eventarc。

Eventarc 符合这些认证和标准

Eventarc 将事件从事件提供方路由到事件目的地。
图 1. Eventarc 将事件从事件提供方路由到事件目的地(点击图表可放大)。

1 来自 Google 提供方的事件可以直接从来源(例如 Cloud Storage)发送,也可以通过 Cloud Audit Logs 条目发送,并使用 Pub/Sub 作为传输层。来自 Pub/Sub 来源的事件可以使用现有的 Pub/Sub 主题,或者 Eventarc 会自动为您创建主题并进行管理。

2 Google Kubernetes Engine (GKE) 目的地的事件(包括在 GKE 集群中运行的 Cloud Run for Anthos (CRfA) 服务)使用 Eventarc 的事件转发器从 Pub/Sub 中拉取新事件并转发到目的地。此组件充当 Pub/Sub 传输层与目标服务之间的中介。它适用于现有服务,还支持信令服务(包括未在全代管式集群外部公开的服务),同时简化设置和维护。 请注意,事件转发器的生命周期由 Eventarc 管理,如果您不小心删除了事件转发器,Eventarc 将恢复此组件。

3 工作流执行的事件会被转换并作为运行时参数传递给工作流。Workflows 可以按照您定义的顺序组合和编排 Google Cloud 服务和基于 HTTP 的 API 服务。

4 Cloud Functions(第 2 代)中的所有事件驱动型函数都使用 Eventarc 触发器传递事件。使用 Cloud Functions 界面部署 Cloud Functions 函数时,您可以配置 Eventarc 触发器

关键使用场景

Eventarc 支持目标应用的许多使用场景。以下是一些示例:

配置和监控
  • 系统配置:启动新虚拟机时,在新虚拟机上安装配置管理工具。
  • 自动修复:检测服务是否没有正确响应并自动重启服务。
  • 提醒和通知:监控加密货币钱包地址的余额并触发通知。
协调
  • 目录注册:在新员工加入公司时激活员工卡。
  • 数据同步:CRM 系统中有潜在客户转化时触发会计工作流。
  • 为资源加标签:在虚拟机创建时为其创建者添加标签并进行标识。
分析
  • 情感分析:使用 Cloud Natural Language API 训练和部署机器学习模型,该模型可在客户服务工单完成后附加满意度分数。
  • 图片修整和分析:在零售商将图片添加到对象存储区时,移除背景并自动对其进行分类。

事件

事件是表示出现及其上下文的数据记录。事件是与其他事件无关的独立通信单元。例如,事件可能是数据库中数据的更改、添加到存储系统的文件或预定作业。

请参阅 Eventarc 支持的事件类型

事件提供程序

事件会从事件提供程序(来源)路由到对其感兴趣的事件使用方。路由根据事件中包含的信息执行,但事件不标识特定的路由目标。Eventarc 支持来自以下提供方的事件:

  • 超过 130 个 Google Cloud 提供方。这些提供方会直接从来源或通过 Cloud Audit Logs 条目发送事件(例如,对 Cloud Storage 存储桶中的对象的更新或发布到 Pub/Sub 主题的消息)。
  • 第三方提供方。这些提供方直接从来源发送事件(例如 Datadog 或 Check Point CloudGuard 平台等第三方 SaaS 提供方)。

事件目的地

事件通过 Pub/Sub 推送订阅被路由到特定目的地(目标),称为事件接收器(或使用方)。

Cloud Functions (第 2 代)

Cloud Functions(第 2 代)中的所有事件驱动型函数都使用 Eventarc 触发器传送事件。Eventarc 触发器支持由 Eventarc 支持的任何事件类型触发的函数。使用 Cloud Functions 界面部署 Cloud Functions 函数时,您可以配置 Eventarc 触发器

Cloud Run

了解如何构建可部署到 Cloud Run 的事件接收器服务

如需确定将事件路由到 Cloud Run 服务的最佳方式,请参阅事件路由选项

GKE

Eventarc 支持创建以 Google Kubernetes Engine (GKE) 服务为目标的触发器。这包括在 GKE 集群中运行的专用服务和公共服务的公共端点。

  • 要使 Eventarc 定位和管理任何给定集群中的服务,您必须向 Eventarc 服务账号授予任何必要的权限

  • 您需要在运行目的地服务的 GKE 集群上启用 Workload Identity。正确设置事件转发器需要使用 Workload Identity,由于 Workload Identity 增强的安全属性和可管理性,因此它是从在 GKE 中运行的应用访问 Google Cloud 服务的推荐方法。如需了解详情,请参阅启用 Workload Identity

VPC 网络中的内部 HTTP 端点

您可以在 Virtual Private Cloud (VPC) 网络中配置到内部 HTTP 端点的事件路由。如需配置触发器,您还必须提供网络 ID。如需了解详情,请参阅将事件路由到 VPC 网络中的内部 HTTP 端点

Workflows

工作流的执行由以下各项触发:

  • 消息发布到 Pub/Sub 主题时
  • 创建与触发器的过滤条件匹配的审核日志时
  • 响应无中介事件(例如对 Cloud Storage 存储桶中的对象的更新)

Workflows 需要一个 IAM 服务账号电子邮件,您的 Eventarc 触发器将使用该电子邮件来调用工作流执行。我们建议您使用具备访问必需资源所需的最小权限的服务账号。如需了解详情,请参阅创建和管理服务账号

事件格式和库

Eventarc 使用二进制内容模式中的 HTTP 请求将事件(无论提供方为何)以 CloudEvents 格式传递到目标目的地。CloudEvents 是一种以通用方式描述事件元数据的规范,它属于 Cloud Native Computing Foundation,并由该基金会的无服务器工作组整理。

根据事件提供方,您可以将事件载荷数据的编码指定为 application/jsonapplication/protobuf协议缓冲区(或 Protobuf)是一种与语言和平台都无关的可扩展机制,用于序列化结构化数据。请注意以下几点:

  • 对于自定义来源或第三方提供方,或者来自 Pub/Sub 的直接事件,不支持此格式设置选项。
  • JSON 格式的事件载荷大于 Protobuf 格式的事件载荷,这可能会影响可靠性,具体取决于您的事件目的地以及它对事件大小限制。如需了解详情,请参阅已知问题

目标目的地(如 Cloud Functions、Cloud Run 和 GKE)使用 HTTP 格式的事件。对于 Workflows 目的地,Workflows 服务会将事件转换为 JSON 对象,并将事件作为运行时参数传递给工作流执行。

使用标准方法描述事件元数据可确保一致性、可访问性和可移植性。事件使用方可以直接读取这些事件,您也可以使用各种语言(包括 C#、Go、Java、Node.js 和 Python)的 Google CloudEvents SDK 和库来读取和解析事件:

Eventarc 以 CloudEvents 格式传送事件。您可以直接读取事件,也可以使用 Google CloudEvents SDK 或库来解析事件。
图 2. Eventarc 以 CloudEvents 格式将事件传送到事件目的地。您可以直接读取这些事件,也可以使用 Google CloudEvents SDK 或库来读取和解析事件。

Google CloudEvents GitHub 代码库中提供了所有事件的 HTTP 正文结构。

向后兼容性

Eventarc 考虑增加以下特性和字段的向后兼容

  • 可选的过滤属性或仅限输出的属性
  • 事件载荷的可选字段

Eventarc 触发器

无论目标目的地是否响应,这些事件都会发生。您可以使用触发器创建对事件的响应。触发器是一种声明,用于表明您对某个事件或一系列事件感兴趣。创建触发器时,可为触发器指定过滤条件,以允许您捕获这些特定事件并对其执行操作,包括它们从事件来源到目标目的地的路由。如需了解详情,请参阅触发器资源的 REST 表示法以及事件提供方和目的地

请注意,默认情况下,为 Eventarc 创建的 Pub/Sub 订阅会持续存在(无论其活跃状态如何),并且不会过期。如需更改订阅属性,请参阅订阅属性

Eventarc 支持以下事件类型的触发器:

Cloud Audit Logs (CAL) 事件
说明Cloud Audit Logs 会为每个 Cloud 项目、文件夹和组织提供管理员活动日志和数据访问审核日志。Google Cloud 服务将条目写入这些日志。此支持的事件列表包含 serviceNamemethodName 值的目录。
事件过滤条件类型当创建与触发器的过滤条件匹配的审核日志时,type=google.cloud.audit.log.v1.written 的 Eventarc 触发器会向您的服务或工作流发送请求。
直接事件
说明Eventarc 可以由各种直接事件触发,例如更新 Cloud Storage 存储桶、更新 Firebase Remote Config 模板或更改 Google Cloud 服务上的资源

Eventarc 还可以由发布到 Pub/Sub 主题的消息触发。Pub/Sub 是一个覆盖全球的分布式消息总线,可根据需要自动扩缩规模。由于 Eventarc 可以由 Cloud Pub/Sub 主题中的消息调用,因此您可以将 Eventarc 与其他任何支持将 Pub/Sub 作为目的地的服务集成。

事件过滤条件类型当发生与触发器的过滤条件匹配的事件时,具有特定事件过滤条件类型的 Eventarc 触发器会向您的服务或工作流发送请求;例如 type=google.cloud.storage.object.v1.finalized(在 Cloud Storage 存储桶中创建对象时)或 type=google.cloud.pubsub.topic.v1.messagePublished(将当消息发布到指定的 Pub/Sub 主题时)。

触发器位置

Google Cloud 服务(例如 Cloud Storage)可以设置为单区域或多区域服务。某些服务(例如 Cloud Build)可以设置为全球服务。

Eventarc 可让您创建区域触发器,或者对于某些事件,您可以创建全球触发器并接收来自所有区域的事件。如需了解详情,请参阅了解 Eventarc 位置

您应指定 Eventarc 触发器的位置以匹配生成事件的 Google Cloud 服务的位置,并避免由全球触发器引起的任何性能和数据驻留问题。

您可以在每个命令中使用 --location 标志来指定触发器位置。对于 Cloud Run 目的地,如果未指定 --destination-run-region 标志,系统将假定服务与触发器位于同一区域。如需了解详情,请参阅 Google Cloud CLI 参考

可靠性和传送

事件传送的预期如下:

  • 使用 Cloud Audit Logs 的事件在一分钟内传送。 (请注意:尽管 Cloud Audit Logs 触发器会立即创建,但它最长可能需要两分钟才能传播和过滤事件。)
  • 使用 Pub/Sub 的事件数秒内传送。

不保证按顺序的先进先出传送。请注意,如果严格按顺序传送消息,将会影响 Eventarc 与其传输层 Cloud Pub/Sub 匹配的可用性和可扩缩性。如需了解详情,请参阅对消息排序

对于延迟时间和吞吐量,提供尽力而为的保证。它们会因多个因素而异,包括 Eventarc 触发器位置(单区域、多区域或全球)、特定服务的配置以及 Google Cloud 区域中资源的网络负载。

请注意,Eventarc 通常具有使用配额和限制。此外,Workflows 还有专门的用量配额和限制

事件重试政策

Eventarc 的重试特征与其传输层 Cloud Pub/Sub 的重试特征一致。如需了解详情,请参阅重试请求推送退避算法

Eventarc 设置的默认消息保留时长为 24 小时,具有指数退避算法延迟。

您可以通过与 Eventarc 触发器关联的 Pub/Sub 订阅更新重试政策:

  1. 打开“触发器详细信息”页面
  2. 点击主题。
  3. 点击订阅标签页。

Eventarc 自动创建的任何订阅都将采用以下格式:projects/PROJECT_ID/subscriptions/eventarc-REGION-TRIGGER_ID-sub-SUBSCRIPTION_ID。如需详细了解订阅限制,请参阅 Pub/Sub 资源限制

如果 Pub/Sub 尝试传送消息,但目的地无法确认消息,Pub/Sub 将至少以 10 秒的指数退避算法再次发送消息。如果目的地仍然不确认消息,则每次重试都会增加更多时间(直到最多 600 秒),并将消息重新发送到目的地。

请注意,Workflows 会在工作流执行开始后立即确认事件。

死信主题

如果目的地未收到消息,您可以将未传送的消息转发到死信主题(也称为死信队列)。死信主题可以存储目的地无法确认的消息。您必须在创建或更新 Pub/Sub 订阅时设置死信主题,而不是在创建 Pub/Sub 主题时或 Eventarc 创建 Pub/Sub 主题时。如需了解详情,请参阅处理消息故障

无法保证重试的错误

如果应用使用 Pub/Sub 作为事件来源且未传送事件,则系统会自动重试事件,但无法保证能够重试的错误除外。如果工作流未执行,则不会重试从任何来源到该工作流目的地的事件。如果工作流执行开始但后来失败,则不会重试执行。如需解决此类服务问题,您应在工作流中处理错误重试

重复事件

重复事件可能会传送到事件处理程序。根据 CloudEvents 规范sourceid 属性的组合被视为唯一,因此任何具有相同组合的事件被视为重复事件。作为一般最佳做法,您应该实施具有幂等性的事件处理程序

可观测性

EventarcCloud RunGKEPub/Sub工作流的详细日志可从 Cloud Audit Logs 中获取。

灾难恢复

您可以利用可用区和区域来实现可靠性,以防服务中断。如需详细了解如何确保使用 Eventarc 时满足备份和恢复时间的 RTO(恢复时间目标)和 RPO(恢复点目标),请参阅针对云基础架构服务中断设计灾难恢复架构

后续步骤