2. Google Cloud事件基础设施概览
在Google Cloud上构建事件驱动应用，最容易混淆的不是API怎么写，而是“哪个组件负责哪一段”。Eventarc、Pub/Sub、Cloud Functions、Cloud Run、Workflows和Event Grid这六个名字经常同时出现在架构图里，但它们的职责边界其实相当清晰：Eventarc负责事件的路由与投递，Pub/Sub负责事件的缓冲与分发，Cloud Functions和Cloud Run负责事件的处理，Workflows负责多步骤编排，Event Grid则是跨云事件接入的入口。理解这条分工线，比记住每个产品的功能列表更重要。
一、先分清“事件通道”和“事件消费者”
事件驱动系统可以拆成两半：一半是事件从产生到被消费的通道，另一半是真正执行业务逻辑的消费者。Pub/Sub是典型的通道型服务，它提供主题（Topic）和订阅（Subscription），发布者把消息发到主题，订阅者从订阅拉取或推送。Pub/Sub的核心价值是解耦、缓冲和至少一次投递，它不关心消息内容，也不负责调用你的代码。
Eventarc则不同。Eventarc本身不存储事件，它更像一个“事件路由器”：从Google Cloud源（如Cloud Storage、BigQuery、Firestore、Audit Logs）或自定义源接收事件，按照你定义的Trigger规则，把事件投递到目标（Cloud Run、Cloud Functions、Workflows等）。Eventarc解决的是“事件从哪来、按什么条件、送到哪去”的问题，而不是“事件怎么排队”。
Cloud Functions和Cloud Run是消费者侧的两个主要形态。Cloud Functions适合短小、单职责、事件触发的函数；Cloud Run适合容器化、需要更多运行时控制、可以同时处理HTTP和事件的服 务。两者都可以被Eventarc触发，也可以直接订阅Pub/Sub。Workflows则站在更高一层：它不处理单个事件，而是把多个步骤（包括调用Cloud Functions、Cloud Run、Pub/Sub发布、HTTP请求）串成一条有状态、可重试、可等待的编排流程。
二、Event Grid的定位：跨云事件的“接入层”
Event Grid在Google Cloud语境下容易被误解。它并不是Google Cloud原生的核心事件总线，而是Azure Event Grid的概念。在跨云或混合云架构中，Event Grid常被用作外部事件源（如Azure资源事件、SaaS事件）的接入点，再通过Webhook或Pub/Sub桥接进入Google Cloud。换句话说，Event Grid负责“把外部事件引进来”，Pub/Sub负责“在Google Cloud内部把事件分发出去”，Eventarc负责“把事件精准送到某个服务”。三者不是替代关系，而是不同层面的接力。
三、协作关系：一条事件从产生到完成的典型路径
假设一个真实场景：用户上传图片到Cloud Storage，系统需要生成缩略图、写入Firestore、并发送通知邮件。这条链路可以这样组织：
- 事件产生：Cloud Storage的
object.finalize事件被触发。 - Eventarc路由：Eventarc Trigger匹配该Bucket和事件类型，将事件投递到Cloud Run服务（或Cloud Functions）。
- 处理与分发：Cloud Run服务生成缩略图后，向Pub/Sub主题发布一条“缩略图完成”消息。
- 多消费者并行：一个Subscription推送给Cloud Functions写Firestore，另一个Subscription推送给另一个Cloud Run服务发邮件。
- 编排兜底：如果流程需要等待、重试或补偿，Workflows可以接管，按顺序调用各服务并记录状态。
这里的关键判断是：如果只需要“事件→一个处理动作”，Eventarc直投Cloud Run/Functions即可；如果需要“事件→多个消费者”或“削峰填谷”，中间加Pub/Sub；如果需要“多步骤、有状态、可重试”，用Workflows编排。Event Grid只在事件来自Google Cloud之外时介入。
四、选型对照：什么场景用哪个组件
| 场景 | 首选组件 | 理由 |
|---|---|---|
| Cloud Storage上传后触发单个函数 | Eventarc → Cloud Functions | 直投、低延迟、无需中间总线 |
| 一个事件需要被3个下游系统消费 | Pub/Sub + 多Subscription | 一对多分发、各自独立重试 |
| 容器化服务需要处理事件 | Eventarc → Cloud Run | 支持任意运行时、并发控制 |
| 订单流程：扣库存→支付→通知→补偿 | Workflows | 有状态、可等待、可重试、可回滚 |
| Azure资源事件接入GCP | Event Grid → Pub/Sub | 跨云桥接，统一进入GCP事件总线 |
五、一个可参考的配置片段
下面是一个Eventarc Trigger的示例，将Cloud Storage事件路由到Cloud Run服务。注意--event-filters用于精确匹配事件源，--destination-run-service指定目标服务：
gcloud eventarc triggers create storage-to-run-trigger \
--location=us-central1 \
--event-filters="type=google.cloud.storage.object.v1.finalized" \
--event-filters="bucket=my-image-bucket" \
--destination-run-service=image-processor \
--destination-run-region=us-central1 \
--service-account=eventarc-sa@my-project.iam.gserviceaccount.com
如果需要在事件到达Cloud Run之前先进入Pub/Sub做缓冲，则改为创建Pub/Sub Topic，并让Eventarc将事件发布到该Topic，再由Cloud Run通过Push Subscription消费。这种“Eventarc → Pub/Sub → Cloud Run”的链路适合突发流量场景，Pub/Sub会先吸收峰值，Cloud Run按自身并发能力消费。
六、常见误区与判断依据
- 误区一：Eventarc可以替代Pub/Sub。Eventarc不持久化事件，如果目标服务不可用，事件可能丢失；Pub/Sub提供持久化存储和重试，适合要求可靠性的场景。
- 误区二：Cloud Functions只能被Eventarc触发。Cloud Functions也可以直接订阅Pub/Sub Topic，或通过HTTP触发。选择哪种方式取决于是否需要Eventarc的过滤和路由能力。
- 误区三：Workflows适合所有多步骤场景。Workflows适合长流程、需要等待和补偿的场景；如果只是简单的“A调用B”，直接用Eventarc或Pub/Sub更轻量。
- 误区四：Event Grid是Google Cloud产品。Event Grid是Azure的事件路由服务，在GCP架构中通常作为外部事件接入点，不是GCP原生事件总线。
判断组件选型时，可以问三个问题：事件从哪来？（GCP内部用Eventarc，外部用Event Grid桥接）需要几个消费者？（一个用Eventarc直投，多个用Pub/Sub）流程有多复杂？（单步用Functions/Run，多步有状态用Workflows）。这三个问题回答清楚，架构基本就不会跑偏。