1. 事件驱动集成工程导论

在传统请求—响应式集成中，调用方必须知道被调方在哪里、何时可用，并主动发起请求；一旦下游变慢或失败，调用链就会被拖住。事件驱动架构（Event-Driven Architecture，EDA）把这一关系倒过来：产生变化的一方只负责把“发生了什么”发布出去，关心这件事的一方自行订阅并处理。生产者与消费者在时间、空间和实现语言上解耦，系统因此获得更好的弹性、可扩展性与可演进性。

理解 EDA，关键是分清三个概念。事件是对已发生事实的不可变描述，例如“订单 20240612-0087 已支付”，用过去时表达，不包含“请做什么”的指令；命令是希望对方执行某动作的请求，如“请为该订单开票”，通常只有一个接收者；消息是传输载体，可以是事件也可以是命令。把事件误当命令用，是初学者最常见的建模错误——一旦事件里塞进“请扣减库存”这类指令，生产者就重新耦合了下游逻辑，解耦收益随之消失。

EDA 的核心价值可以归纳为四点：一是解耦，生产者无需感知消费者数量与位置；二是削峰，突发流量先进入消息中间件缓冲，消费者按自身能力消费；三是可扩展，新增业务只需新增订阅者，无需改动上游；四是可追溯，事件流天然形成业务审计轨迹，可用于回放与重建状态。代价同样存在：最终一致性取代强一致、重复投递要求消费端幂等、链路变长后需要可观测性支撑。工程上通常用“至少一次投递 + 幂等消费”来换取可用性。

Google Cloud 事件源与接收器全景

在 Google Cloud 上做事件驱动集成，可以把组件分成三层来看：事件源负责产生事件，传输与路由层负责可靠投递与分发，接收器负责消费并落地业务逻辑。

常见事件源包括：Cloud Storage 的对象创建/删除、Pub/Sub 主题消息、Cloud Pub/Sub 之外的 Cloud Scheduler 定时触发、Firestore 文档变更、Cloud SQL 与 BigQuery 的变更、以及通过 Eventarc 接入的 90 多个 Google Cloud 服务审计日志与直接事件。第三方 SaaS（如 GitHub、Shopify）可通过 Webhook 或 Partner Topic 接入。

传输与路由层的核心是 Pub/Sub：主题（Topic）接收发布，订阅（Subscription）承载消费，支持推送与拉取两种模式，并通过死信主题（Dead Letter Topic）与重试策略处理失败消息。Eventarc 则把各类 Google Cloud 事件统一标准化为 CloudEvents 格式，按条件过滤后路由到 Cloud Run、Cloud Functions、GKE 或 Workflows。Eventarc Advanced 进一步提供基于消息总线的多对多路由能力。

接收器侧常见形态有：Cloud Run 服务（HTTP 推送端点）、Cloud Functions（函数即服务）、GKE 上的消费者 Deployment、Workflows 编排、以及 Dataflow 做流式聚合。选择依据主要是并发模型、运行时长、依赖复杂度与成本。

课程实战项目介绍

本课程围绕一个贯穿始终的实战项目展开：电商订单事件处理流水线。业务场景是——用户在电商平台下单并支付后，系统需要依次完成库存扣减、发票生成、物流通知、数据入仓与实时看板更新。若用同步调用串联，任一环节抖动都会阻塞主流程；我们改用事件驱动方式重构。

项目的事件流设计如下：订单服务在支付成功后向 Pub/Sub 主题 order-events 发布一条 order.paid 事件，事件体采用 CloudEvents 1.0 格式，包含 id、source、type、time 与 data 字段，其中 data 携带订单号、商品明细、金额与用户标识。示例事件如下：

{
  "specversion": "1.0",
  "id": "evt-20240612-0087",
  "source": "//ecommerce/order-service",
  "type": "com.example.order.paid",
  "time": "2024-06-12T10:23:41Z",
  "data": {
    "orderId": "20240612-0087",
    "amount": 299.00,
    "currency": "CNY",
    "items": [{"sku": "A1001", "qty": 2}],
    "userId": "u-88213"
  }
}

围绕这条事件，我们建立三个订阅：inventory-sub 由 Cloud Run 服务消费，执行库存扣减并保证幂等（以 event.id 作为去重键写入 Firestore）；invoice-sub 由 Cloud Functions 消费，生成发票记录；analytics-sub 由 Dataflow 消费，将事件写入 BigQuery 供实时看板查询。每个订阅都配置死信主题 order-events-dlq，重试 5 次后转入死信，便于人工排查。

项目将分阶段推进：先打通“发布—订阅—消费”最小闭环，再引入 Eventarc 接入 Cloud Storage 与审计日志事件，随后加入幂等、重试、死信与可观测性（Cloud Logging + Trace），最后用 Workflows 编排跨服务的长流程，并做成本与性能调优。完成本项目后，你将掌握在 Google Cloud 上设计、实现、调试与运维事件驱动集成链路的完整能力。