首先通过 Google Pub/Sub 发送发往 Google Cloud Functions 的请求，将其转换为 GCF 可以执行的事件/消息队列，而不是直接将请求直接发送到 GCF，这是否会带来显着的性能优势？比如说，HTTPS 可调用？
我不太熟悉谷歌在后端通过其云功能进行的扩展，例如，随着流量的增加或流量的急剧增加——据我所知，GCF 可能正在使用某种消息我不知道内部队列，使得添加显式发布/订阅层变得多余。无论哪种情况，仍然需要从客户端向 GCP 发出 HTTP 请求，无论是在 Pub/Sub 队列中创建消息/事件还是直接调用 GCF，所以我只是想知道是否在客户端之间添加 Pub/Sub云功能只是增加了延迟，以及什么时候真正的性能优势会发挥作用 - 例如，在什么级别的活动中，这样的架构是必要的（如果有的话）？
基本上，我有一个移动应用程序的后端，该应用程序严重依赖 GCF 进行数据库和 Elasticsearch（由 GCP 托管）搜索和摄取，以及一些身份验证功能，并且我正在考虑是否需要在两者之间添加消息传递层客户端和 GCF 支持最终的生产负载。
抛开使用 PubSub 作为调用者和云函数之间的中介的所有额外 CAPEX（开发）和 OPEX（运营和支持），我还会考虑其他一些方面。
问题没有详细描述上下文和非功能性需求，所以我不得不猜测很多。从我的角度来看，还不清楚问题中的“性能”是什么意思。
无论如何。我想到了一些事情。
如果调用者进行云函数调用，则必须等待返回答案。调用者可能会聪明地在单独的“运行流程”中进行此类调用（无论如何实现），因此这可能不是什么大问题。如果不是，对于调用者来说，PubSub 调用可能会更快（从而降低延迟）。缺点 - 如果调用者期望从云函数调用中得到某种结果/结果，则该结果应该在云函数执行其应该执行的操作后以某种方式传递给调用者。并且事先可能不清楚，什么时候会发生，以及调用者如何使用结果。
我想到的下一件事 - 向 PubSub 发送消息比云函数调用更（宽松地说）可靠。考虑云函数调用。如果云函数调用不成功（出于任何业务或基础设施原因），调用者该怎么办？另一方面（通过PubSub传递），如果PubSub中的消息无法处理，云函数该怎么办？ “死信”主题？监控？将未处理的消息作为对象保存在存储桶中以供调查？所以，这里有很多值得思考的地方。
如果调用者位于“外部互联网”，那么直接公开云函数可能不是一个好主意。因此，我们可能会开始考虑某种负载均衡器等等......或者可能是其他东西。我不想在这里讨论安全问题，但这个主题可能会显着影响设计选择。
结束语。我认为做出选择时应考虑更广泛的背景和非功能性要求，而不仅仅是“性能”标准。这里有很多值得思考的地方。
如今，我认为 Cloud Run 通常是无服务器的首选解决方案。 它可以像 CF 一样扩展到 0，但它也可以更可靠地执行其他操作。
特别是因为 Cloud Functions v2 也在底层使用了 Cloud Run。