使用 Firebase Cloud Functions 实施 Cloud Run答案

【问题标题】：Implementing Cloud Run with Firebase Cloud Functions使用 Firebase Cloud Functions 实施 Cloud Run
【发布时间】：2020-02-21 05:47:18
【问题描述】：

阅读有关 Cloud Run 和 Firebase Cloud Functions 的文档后，我有几个问题想要澄清：

Cloud Run 是否基本上充当容器映像存储/部署机制？如果我有 2 个网站并将它们作为单独的容器化映像，Cloud Run 是否只部署指定的一个给定触发器？
将 Cloud Run 与 Firebase Cloud Functions 集成为触发器，是否会增加一层延迟？虽然延迟时间是未知的，但 FCF 因冷启动而固有地具有预热时间，是否会因 Cloud Run 冷启动图像而增加延迟？
Cloud Run 图像是否通过 FCF 传递给用户。还是 FCF 只是将用户直接重定向到 Cloud Run 映像？

基本上是这样的
```
Client -> FCF -> Image -> FCF -> Client
```
或
```
Client -> FCF -> Image -> Client
```

【问题讨论】：

我通常认为 Cloud Functions 提供微服务，您在其中提供代码，而 Google 提供运行代码的环境。我认为 Cloud Run 是 Cloud Functions 的更新替代品，但本质上执行的是相同的任务。区别在于运行代码的框架更受您的控制，并且比 Cloud Functions 更“丰富”。我没有看到为什么/如何通过首先通过 Cloud Functions 路由来执行 Cloud Run（作为所需的端点）。您认为原因/好处是什么？
据我了解，Cloud Run 基于触发器部署镜像，所以我假设需要 FCF 作为一种“路由器”来根据路由触发不同的镜像。给定一个域，它将重定向到 FCF“路由器”，然后为 Cloud Run 图像提供服务。

【解决方案1】：

通常在 Stack Overflow 上，每个帖子应该限制为一个问题（以避免因“过于宽泛”而被关闭），但我会在这里尝试。请将后续问题作为新帖子解决。

是的，它只是一种服务 HTTP 请求的容器化方式。
Cloud Run 与 Cloud Function 没有直接关系，除非您编写代码来连接它们。如果您编写代理到 Cloud Run 的 Cloud Function 触发器，它将根据需要产生两种产品的所有延迟成本（并非所有调用都需要冷启动）。所有“无服务器”计算选项都有一个冷启动时间，因为它们都缩小到零（基于当前负载），而且您无需为虚拟服务器实例的分配和随时可用的时间付费。
同样，它们不相关。您可以使用其中一个而不使用另一个。

【讨论】：

感谢道格的第二次回复。我不想在 2 小时内用 4 个问题向 Firebase stackoverflows 发送垃圾邮件，所以我尝试压缩我的帖子。为了澄清问题 3，我想具体了解我的用例，或者更确切地说是 FCF 用例。一起使用 Cloud Run 和 FCF 时，FCF 基本上会向 Cloud Run 发送调用吗？还是告诉 Cloud Run 部署映像，然后返回映像中的任何数据？
正如我所说，产品根本没有直接关系。
On 3) 如果您使用 Cloud Functions（来自 Firebase 或单独），Cloud Run 不会以任何方式参与。