消息队列与事件驱动——Pub/Sub和Eventarc让“异步”变得简单

“同步调用”是大多数初学者写代码的第一反应——A调用B，B返回结果，A继续。但现实中，很多场景根本不需要同步等待。

用户注册 → 发送欢迎邮件（用户不需要等邮件发完）

订单支付 → 更新库存（库存更新慢一点没关系）

文件上传 → 生成缩略图（用户不需要等缩略图生成）

这些场景用事件驱动架构（Event-Driven Architecture） 来解决最合适。而谷歌云上实现事件驱动的两个核心工具是：Pub/Sub和Eventarc。

Pub/Sub：消息队列的“万金

Pub/Sub：消息队列的“万金油”

Pub/Sub的核心概念只有三个：

主题（Topic） ：消息的“分类标签”。发布者把消息发到某个主题。

订阅（Subscription） ：主题的“消费者入口”。订阅者从订阅拉取消息。

消息（Message） ：实际传输的数据，包含属性（attributes）和数据体（payload）。

Pub/Sub的特点：

至少一次投递：消息不会丢，但可能重复投递（消费者需要做幂等处理）

顺序不保证：同一主题的消息可能乱序到达（如果需要顺序，用有序订阅）

全球分布：主题和订阅可以跨区域，自动扩缩

Eventarc：事件路由的“智能交换机”

如果说Pub/Sub是“消息的高速公路”，那Eventarc就是“事件的智能交换机”。

Eventarc做的事情是：监听各种事件源，把事件路由到不同的目标。

事件源包括：

谷歌云服务事件（Cloud Storage文件上传、BigQuery作业完成、Firestore数据变更等）

第三方事件（通过Pub/Sub接入）

自定义事件

目标包括：

Cloud Run

Cloud Functions

Workflows

Pub/Sub主题

Eventarc的典型场景：

用户上传图片到Cloud Storage → Eventarc触发Cloud Run函数 → 生成缩略图

数据库变更 → Eventarc触发Workflows → 执行一系列后续操作

定时任务 → Cloud Scheduler发消息到Pub/Sub → Eventarc触发数据处理

一张表看懂Pub/Sub vs Eventarc

事件驱动架构的四个最佳实践

实践一：消息设计要“自包含”

每条消息应该包含消费者需要的所有信息，而不是让消费者再去查数据库。比如订单消息应该包含订单ID、用户ID、金额、商品列表——而不是只包含一个订单ID让消费者自己去查。

实践二：消费者要做幂等

Pub/Sub保证“至少一次投递”——意味着同一条消息可能被投递多次。消费者的处理逻辑必须幂等：处理多次和一次的结果一样。

实现幂等的常见方式：

用消息ID做去重（Redis或Bigtable存已处理的消息ID）

用业务唯一标识做幂等（比如用订单ID作为唯一键）

实践三：设置合理的retry策略

消息处理失败怎么办？Pub/Sub支持重试。但要设置合理的重试策略：

重试次数（别无限重试）

退避时间（指数退避，别疯狂重试把下游打垮）

死信队列（重试失败后放到死信主题，人工介入处理）

实践四：监控消息积压

“未确认消息数”是Pub/Sub最重要的监控指标。设置告警——超过阈值意味着下游处理不过来，需要扩容或排查问题。

真实案例

一家做在线教育的公司，用户提交作业后需要做：存储作业文件、更新作业状态、通知老师、更新学习进度、生成学习报告——5个步骤串行执行，用户要等好几秒。

改造为事件驱动后：

用户提交作业 → 作业服务把“作业提交事件”发到Pub/Sub

立即返回“提交成功”（用户不用等）

5个消费者并行处理（各自订阅同一主题的不同订阅）

全部完成后发通知

结果：用户等待时间从5秒降到0.5秒，系统吞吐量提升了3倍。

事件驱动架构的核心思想是 “让事情在合适的时间发生，而不是在必须的时间发生” 。同步调用是“你必须等我”，事件驱动是“你忙你的，完事了告诉我”。选对了场景，事件驱动能让你系统的弹性和吞吐量上一个台阶。

如果需要更深入咨询了解可以联系全球代理上TG:jinniuge  他们在云平台领域有更专业的知识和建议，他们有国际阿里云，国际腾讯云，国际华为云，aws亚马逊，谷歌云一级代理的渠道，客服1V1服务，支持免实名、免备案、免绑卡。开通即享专属VIP优惠、充值秒到账、官网下单享双重售后支持。不懂找他们就对了。