为什么使用 Pub/Sub？ 用例：有一个 http 触发的“云功能”，一些数据被发送到它上面。 此函数处理数据后，将数据发布到 Pub/Sub 主题。
然后还有另一个 Cloud 函数，它基于发布到该 Pub/sub 主题而触发。 因此，此 Cloud 函数从发布/订阅中获取已发布的数据并将其插入到 BigQuery 表中。
所以在这个用例中，为什么使用 pub sub，为什么我们不能只拥有一个从 http 命中中获取数据并将其插入到 BigQuery 的云函数。 在这里选择发布/订阅的设计思路是什么？
还有一般为什么使用 Pub/sub 架构？
答案 0 :(得分：2)
在此架构中使用 Cloud Pub/Sub 可能有多种原因。一个原因是如果有任何扇出或计划扇出，发布的数据不仅会在 BigQuery 中结束，还会在其他地方。如果没有 Pub/Sub，http 触发的云函数必须知道所有感兴趣的数据接收者并将其发送给每个接收者。借助 Pub/Sub，任何对传入数据感兴趣的附加服务都可以针对数据创建单独的订阅并独立于 BigQuery 使用它。
另一个原因是能够将数据批量插入到 BigQuery 中，而不会增加对初始 Cloud Function 的 http 请求的延迟。这可能是为了提高效率或对传入的数据进行某种跨事件预处理。通过使用 Pub/Sub，一旦成功发布到 Cloud Pub/Sub，第一个 Cloud Function 可以响应请求，无需等待任何其他请求，并且可以确保请求最终会得到处理。
如果现在或将来都没有这两个，直接写入 BigQuery 可能是有意义的。