GCP PubSub触发Cloud Functions随机静默失败故障排查咨询

核心问题定位 #

你遇到的问题90%以上是发布消息的代码逻辑缺陷导致的：publisher.publish() 是异步方法，返回一个 Future 对象，你没有等待异步发布操作完成，函数就执行结束了。GCF在函数返回状态ok后会立即冻结/销毁运行环境，未完成的异步请求直接被丢弃，所以会出现日志显示函数执行成功，但消息实际没发出去的情况。

问题1：极低频率的短消息出现投递失败属于正常情况吗？ #

• 正常的PubSub投递可用性在99.95%以上，你遇到的随机丢失概率远高于这个指标，不属于PubSub本身的预期故障，几乎都是使用方式不正确导致的。
• 只有极端场景下（比如区域级故障）才会出现极低概率的投递失败，且这类故障GCP都会有服务状态告警。

问题2：publisher.publish()调用环节需要做什么配置来提升投递可靠性？ #

你只需要修改发布消息的代码，等待异步操作完成即可：

from google.cloud import pubsub_v1

publisher = pubsub_v1.PublisherClient()
topic2 = publisher.topic_path('my-project-name', 'topic2_id')
publish_message = '{short json message to be published}'
print('sending message ' + publish_message)
# 调用.result()等待发布操作完成，有错误会直接抛出异常
future = publisher.publish(topic2, publish_message.encode("utf-8"))
message_id = future.result()
print(f"message published successfully, id: {message_id}")

额外可以加异常捕获逻辑，发布失败时直接抛出函数执行失败的错误，方便你从GCF日志里发现问题：

try:
    future = publisher.publish(topic2, publish_message.encode("utf-8"))
    message_id = future.result()
except Exception as e:
    print(f"publish failed: {str(e)}")
    raise e

不需要额外的复杂配置，只要确保发布操作同步完成即可。

问题3：有没有直观的方案可以定位消息丢失环节？ #

有两种简单方案配合使用即可：

• 首先按照上面的代码修改后，所有发布失败的场景都会在GCF的运行日志里直接报错，能先确认是不是发布环节的问题。
• 给每个topic新增一个拉取类型的订阅，不需要消费，保留消息时长设为最长的7天，一旦出现下游函数没触发的情况，直接去这个订阅的控制台看有没有未消费的消息：
  • 如果订阅里有消息，说明是topic到GCF触发器的环节出问题，可以去对应函数的触发器配置页检查状态，也可以看PubSub的订阅指标里有没有投递错误。
  • 如果订阅里没有消息，说明就是发布环节的问题，回到函数日志查发布报错即可。
• 死信主题是用来处理下游消费失败的场景，你这个场景如果确认是发布环节的问题暂时用不上，如果要配置的话直接在对应GCF触发器的订阅里开启死信策略即可，投递失败的消息会自动转发到你指定的死信主题里留存。

问题4：需要接近100%的运行可靠性，是否需要放弃GCF和PubSub的方案？ #

不需要，你当前的问题是使用方式错误导致的，修复后可靠性完全能满足要求。如果要更适合串行工作流的方案，可以用Cloud Workflows，专门用来编排多个GCF函数的执行顺序，不需要自己用PubSub串流程，自带重试、错误处理、执行日志全链路追踪，比你自己用PubSub串联的方案更省心，故障率更低。

内容的提问来源于stack exchange，提问作者John F