Cloud FaaS中冷启动与缩放到零的权衡

在我开始之前，我会说我不是100%确定这是否是这个问题的合适的SX。如果我要问其他SX的问题，请告诉我

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

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

第1点和第2点被认为是好处——你得到的正是你所需要的（如果适用，不包括任何东西），你得到的正是你所得到的 第3点被认为是一个缺点-完成请求需要相当多的时间。我见过一些作者将冷启动描述为FaaS平台尚未成熟的标志。我见过一些实践者说，他们设置定期请求只是为了防止其功能变得不活跃和“失效”，从而在下次调用时触发冷启动

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

---

b） 发送定期请求（如上所述）肯定会让您付出代价，对吗？

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

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

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

Azure函数根据所消耗的资源（以GB为单位的平均内存大小乘以执行函数所需的时间（以毫秒为单位）以及点击次数向用户收费。

---

因此，是的，为使函数保持温暖而创建的ping函数确实成本更高，但成本并不是切换到FaaS模型的主要因素。FaaS模型主要用于创建容错服务，因此，如果API的一部分出错，则不需要关闭整个应用程序

谢谢你的回答！因此，基本上这是一个成本/可用性的权衡，只是一个用户会严重依赖可用性的方面。知道了！然而，您提到了热/冷启动的5/50秒延迟，这让我感到惊讶，因为它们似乎太长了。AFAIU FaaS的主要优点之一是提供高度灵活（接近实时）的可伸缩性。这可能是一个区域/配置/依赖性问题，还是这些只是正常的数字？它高度依赖于导入的模块以及特定时间的服务器负载，下面是一个很好的解读