在我开始之前，我会说我不能100%确定SO是否是这个问题的合适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的一部分出错，则不需要关闭整个应用程序。