Firebase中云函数的最有效结构

对于实时数据库触发功能，以下两个选项之间是否存在性能差异

一个云函数，侦听所有子节点并根据路径决定执行什么

每个子节点都有一个完全独立的云函数

---

这是假设函数执行的总数保持相等。

如果同时发生多个事件，则可能是一个问题（来自：

云函数可以启动多个函数实例来扩展您的应用程序 功能正常，以满足当前负载。这些实例并行运行， 这会导致执行多个并行函数

但是，每个函数实例每次只处理一个并发请求 一段时间。这意味着当您的代码处理一个请求时 不可能将第二个请求路由到同一功能 实例，并且原始请求可以使用 您请求的资源（CPU和内存）

---

除此之外，单独云函数的逻辑应该比为每个触发器检查一个单一函数简单得多。

也许我没有正确解释这一点，但没有看到这将是一个问题，因为如果函数是单独的函数，那么每个请求的实例也会不同。除非每个函数名都有一个配额？抱歉，我应该更清楚地说明，我的理解是，从性能角度看，一个大型云函数应该比多个云函数慢（需要根据每个事件进行决策逻辑），因为决策逻辑已经存在。如果有99个事件没有被频繁触发，但有一个事件触发了，那么我猜一个大型云函数会变得浪费吗？我明白了，尽管我的决策逻辑并不复杂，因为它只需要路径名并将其路由到正确的文件，然后需要正确的包。只是不确定是否有更重要的事情发生，这将保证时间切换回单独的功能。当我们在Spark计划中时，我将它们合并在一起，这样我们就可以用一行代码部署函数。你能澄清一下用一行代码部署函数是什么意思吗？这仅仅是

firebase部署--仅功能
？现在我们在blaze计划中，是的，但在spark计划中，它不允许我们一次部署多个功能，因此我们必须分批进行部署，将许多（不是全部）功能放在一个功能中有助于我们节省部署时间