在FaaS中冷启动与零交换

Question

在我开始之前，我要说的是，我还不能百分之百确定这个问题是否适合SX。如果我应该在其他的SX上问这个问题，请告诉我。

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

目前，我正在阅读无服务器计算(更具体地说，是FaaS)，并试图让自己对这一主题感到满意。现在，几乎在我转向的任何地方，我都会遇到以下关于FaaS的声明：

1)大多数FaaS平台支持从下到零的扩展；

2) FaaS提供者根据用户的功能执行时间(通常以ms来衡量)向用户收费；

3)潜在的冷启动(即创建新实例而不是重用现有实例)是FaaS中的一个问题，因为它们大大降低了应用程序的性能；

第1点和第2点被认为是好处--你完全可以得到你需要的东西(如果不包括任何东西，如果适用的话)，安迪会为你得到的东西付钱。

第3点被认为是一个缺点--请求需要相当长的时间才能完成。我曾见过一些作者将冷启动描述为FaaS平台尚未成熟的标志。我见过从业者说，他们建立周期性的请求，只是为了防止他们的功能变得不活跃和“陷入”，从而触发冷启动下一次被调用。

我的问题是-为什么冷的开始被认为是不受欢迎的，而不是作为一个权衡的。

我的意思是，考虑到用户在FaaS中支付执行时间，避免使用温暖而空闲的函数实例不是通常符合他们的最佳利益吗？在我看来，这似乎是一个成本和高可用性的决定。我是不是误解了什么？是否有一个温暖的，但空闲的函数实例不计入一个人的执行时间？即使是这样：

( a)从提供者的角度来看，这不是不可取的(必须分配既不使用也不付费的资源)？

(如上文所述)定期发送请求一定要花费你的钱，对吗？

Answer 1

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

冷启动问题导致特定客户端执行请求的延迟，在冷启动期间服务请求的时间导致大约从5秒延迟到50秒延迟。这是不好的，因为这些原因：

1. 许多函数都是有时间限制的，即如果执行时间超过某一特定限制，它们的执行就会停止。因此，一些用户没有得到他们的请求的服务。
2. 为特定用户服务的时间是可变的，这在设计应用程序时总是不可取的，因为一致性是关键。

Azure函数是一种更便宜的选择，还是使用专门的are计划更便宜，取决于应用程序和您想要服务的用户的数量。

Azure函数向用户收取所消耗的资源(资源消耗是通过将平均内存大小(以千兆字节为单位)乘以执行该函数所需时间(毫秒)以及命中次数来计算的。因此，是的，为保持函数的温暖而创建的point函数确实成本更高，但成本并不是切换到FaaS模型的主要内容。FaaS模型主要用于创建容错服务，因此，如果您的API的某一部分搞砸了整个应用程序，就不需要崩溃。