1

在我开始之前，我会说我不是 100% 确定 SO 是否适合这个问题的 SX。让我知道我是否应该在其他 SX 上问这个问题。

问题一般是关于 FaaS 的，但如果您可以在特定 FaaS 平台/提供商的上下文中更好地解释这一点，那也很好。

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

第 1 点和第 2 点被认为是福利——您得到的正是您所需要的（如果适用，什么也不包括），并且您只需为您得到的东西付费。
第 3 点被认为是一个缺点 - 请求需要更多时间才能完成。我见过作者将冷启动描述为 FaaS 平台尚未成熟的标志。我见过从业者说他们设置周期性请求只是为了防止他们的功能变得不活跃和“陷入困境”，从而在下次调用时触发冷启动。

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

4

1 回答 1

1

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

冷启动问题导致延迟执行特定客户端发出的请求，在冷启动期间为请求提供服务的时间导致大约 5 秒到 50 秒的延迟。由于以下原因，这是不好的：
1. 许多功能是有时间限制的，即如果执行时间超过特定限制，它们的执行就会停止。所以一些用户没有得到他们的请求服务。
2. 为特定用户服务的时间变化很大，这在设计应用程序时总是不可取的，因为一致性是关键。

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

Azure 函数向用户收取资源消耗（资源消耗的计算方法是将平均内存大小（以 GB 为单位）乘以执行该函数所需的时间（以毫秒为单位））以及点击次数。所以，是的，为保持功能温暖而创建的 ping 功能确实成本更高，但成本并不是切换到 FaaS 模型的重点。FaaS 模型主要用于创建容错服务，因此如果您的 API 的一部分出现问题，整个应用程序不需要停机。

于 2020-04-11T13:22:08.690 回答