GCP PubSub 使用 Cloud Functions 神秘/无声地失败

Question

我有大约十几个 GCF 函数 (Python)，它们每天运行一次。为了保持正确的顺序，我使用 PubSub。比如：

topic1 触发 function1 -> function1 运行 -> function1 向 topic2 写入消息 -> topic2 触发 function2 -> function2 运行 -> 等等。

这个用例是低吞吐量和一种非常简单（我认为）将 GCF 和 PubSub 一起使用以相互优势的方式。这些函数使用 Python 中的pubsub_v1 来发布消息。 IAM、权限等没有问题。代码如下：

from google.cloud import pubsub_v1

# Publish message 
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)
publisher.publish(topic2, publish_message.encode("utf-8"))

我使用以下方法部署 function1 和其他功能：

gcloud functions deploy function1 --entry-point=my_python_function --runtime=python37 \
--trigger-topic=topic1 --memory=4096MB --region=us-central1 \
--source="url://source-repository-with-my-code"

但是，最近我开始看到一些非常奇怪的行为。基本上，function1 运行，日志看起来很棒，消息似乎已发布到 topic2 ......然后什么都没有。 function2 不会开始执行或在日志中显示任何内容以表明它已被触发。没有提示成功或失败的日志。所以本质上似乎是：

• 从 function1 到 topic2 的消息没有被发布，尽管 function1 以Function execution took 24425 ms, finished with status: 'ok' 结束
• 正在发布从 function1 到 topic2 的消息，但 topic2 没有触发 function2。

这是 PubSub 的预期行为吗？这些失败似乎完全是随机的。我花了几个月的时间，一切工作都非常可靠，现在突然间我不知道消息是否会被传递。似乎也很难跟踪这些 PubSub 消息的生命周期，以查看它们究竟在哪里丢失。我在文档中阅读了有关死信主题等的内容，但我真的不明白如何设置易于跟踪的内容。

1. 频率极低的短消息“失败”传递是否正常？
2. 是否有什么我遗漏或我应该做的事情，例如。在publisher.publish() 电话中以确保更可靠的交付？
3. 是否有一种透明的方式来查看正在发生的事情并查看这些消息丢失的位置？设置一个新订阅，我可以在控制台中查看并查看哪些消息正在传递，哪些消息失败，类似这样的事情？
4. 如果我需要 100%（或接近）的可靠性，我应该放弃 GCF 和 PubSub 吗？什么更好？

Answer 1

这里的问题是您没有等待publisher.publish 真正成功。此方法返回一个未来并且可能不会同步完成。如果你想确保发布成功完成，你需要在publish返回的值上调用result()：

future = publisher.publish(topic2, publish_message.encode("utf-8"))
future.result()

您还需要通过将--retry 参数传递给gcloud functions deploy 来确保在云功能上启用了“失败时重试”。这样，如果发布失败，来自 topic1 的消息将被重新发送到云函数再次尝试。