firebase - 为什么小型 Firebase Functions 应用程序不使用单个 Function 来处理逻辑？

...除了单独的性能监控和日志记录的好处。

对于日志记录，我相信我可以通过手动将“例程”的名称添加到每个调用来获得粒度。这就是现在系统不同部分的几个离散函数的情况：

有多个自动日志：例如，例程的开始和结束。找出某些例程有多昂贵将更具挑战性，但这并非不可能。

我希望应用程序的整个逻辑由单个handle函数处理的原因是为了减少冷启动：一个函数意味着只有一个容器可以在应用程序的用户很少时持续保持活动状态。

如果一个月是 ~2.6m 秒，我们假设系统始终使用 1 GB RAM 和 1 GHz CPU 频率，那就是：

2600000 * 0.0000025 + 2600000 * 0.000001042 = USD$9.21 a month

...至少有一个例子。

我还应该声明，我的所有函数都具有最低限度的全局范围代码；它只是设置 Firebase 资产（RTDB 和 Firestore）。

从计费、性能（基于用户等待时间）和用户/开发人员体验的角度来看，是否有任何理由让我的所有功能保持独立是明智的？

只要有理由，我也会接受“所有逻辑的单一功能是合理的”的答案。

谢谢！

标签： firebasegoogle-cloud-functions

如果您的应用程序非常小，大约 5 个端点且流量非常低。当然你可以做这样的事情。但为什么不这样做：

要意识到的重要一点是，每次请求都会创建一个新的函数实例。这意味着可能有 10 个它们同时运行。

如果您只想让 1 个实例处理所有流量，您应该探索GCP Cloud run，其中您有 1 个容器处理多个请求并仅在不够时进行扩展。

想象一下，您有多个端点，每个端点都有不同的性能要求。

（仅供参考：您也可以通过 RAM 设置控制函数的 CPU MHz - 在某些情况下可以加快执行速度）

如果您只有 1 个功能和 1GB 内存。每个请求都会分配这样的功能，在某些情况下，大部分内存可能会浪费掉。

但是，如果您将其拆分为多个，则某些请求将需要更少的资源，并且当我们谈论每月执行的更大数量时可以为您节省美元。（数万+）。

让我们想象一下函数，3 秒执行，10k 执行/月：

如您所见，使用小型应用程序，差异可能没有。但如果你扩大规模，这很重要。（*费用可能因数据中心而异）

至于日志，我认为这并不重要。通常在更大的系统中，消息可能会通过几个函数传播，所以无论如何你都必须处理它。

至于冷启动。你只需要好的用户界面来促进这一点。起初我在我们的应用程序中担心它，但后来，你习惯了一些动作可能需要大约 2 秒才能执行（冷启动）。无论如何，您都应该让 UI “加载”，因为您不知道该功能是否由于连接不良而需要约 100 毫秒或 3 秒。