冷启动与在FaaS中缩放为零权衡

Posted 2023-02-17

[我什至在开始之前，我不会100％地确定SO是否适合此问题。让我知道是否应该在其他SX上询问。

这个问题通常与FaaS有关，但是如果您可以在特定的FaaS平台/提供程序的上下文中更好地解释这一点，那也很好。

我目前正在阅读无服务器计算（更具体地说是FaaS），并试图使自己对这个主题有所了解。现在几乎无论到哪里，我都会遇到以下有关FaaS的陈述：1）大多数FaaS平台都支持从零扩展到零；2）FaaS提供商根据其功能执行时间向用户收费（通常以毫秒为单位）；3）潜在的冷启动（即创建新实例而不是重用现有实例）是FaaS的问题，因为它们会大大降低应用程序的性能；

第1点和第2点被认为是好处-您得到的正是您所需要的（如果有的话，什么也不收），并且为您所得到的付出。第3点被认为是一个缺点-请求花费大量时间才能完成。我见过一些作家将冷启动描述为FaaS平台尚未成熟的标志。我见过从业人员说，他们设置定期请求只是为了防止其功能变得不活动和“陷入困境”，从而在下次调用时触发冷启动。

我的问题是-为什么冷启动被视为不受欢迎而不是权衡？我的意思是，考虑到用户在FaaS中为执行时间付费，避免拥有温暖但空闲的函数实例通常不是他们的最大利益吗？在我看来，这似乎是成本与高可用性的决定。我会误会吗？具有温暖但空闲的功能实例不会计入一个人的执行时间吗？即使是这样：a）从提供商的角度（必须分配既不使用也不付费的资源）来看，这是否不受欢迎？b）发送定期请求（如上所述）肯定会花费您，对吗？

答案

对于这个答案，我将讨论Azure函数。答案将或多或少地转移到其他无服务器提供商。

冷启动问题导致特定客户端执行请求的延迟，在冷启动期间为请求提供服务的时间导致大约5秒到50秒的延迟。由于以下原因，这很糟糕：1.许多功能受时间限制，即，如果执行时间超过特定限制，则将中止其执行。因此，某些用户无法满足他们的请求。2.为特定用户提供服务的时间是可变的，并且在设计应用程序时始终不希望这样做，因为一致性是关键。

Azure Functions是更便宜的替代方案还是使用专用的App Service计划更便宜，取决于应用程序和您要服务的用户数量。

Azure函数向用户收取消耗的资源（资源消耗是通过将平均内存大小（以GB为单位乘以执行该函数所花费的毫秒数来计算的），以及命中数。因此，是的，为保持功能正常运行而创建的ping功能确实会花费更多，但是成本并不是切换到FaaS模型的重点。 FaaS模型主要用于创建容错服务，因此，如果您的API的一部分混乱了，则整个应用程序都不需要关闭。