无服务器冷启动不是问题-这就是为什么（对于大多数应用程序）

从无服务器开始时，您很快就会学习/听到有关函数冷启动的信息（我相信无服务器=云功能+ API ）。 首次调用云功能时或长时间不调用后会发生冷启动。 基本上，服务器（是的，有服务器！）需要一点点时间才能使功能首次就绪，因此可以接受和处理请求。 如果第二次调用一个函数，它将执行得更快。 在一段时间内功能会保持温暖。 如果在该时间段内再次调用某个函数，它将很快执行。

如果某个函数在一段时间内没有被调用，它将再次变冷，而在下次被调用时，它将再次变慢（冷启动）。

这很有道理。 首次在手机或计算机上启动应用程序时-第一次需要花费更长的时间。 当您很快再次启动它时，它通常会启动得更快。

对于许多应用而言，冷启动不是问题。 考虑正在构建的应用程序的类型非常重要。 如果我们要构建业务应用程序或内部后端应用程序，那么冷启动就不是问题。 如果应用程序的启动速度慢了几分之一秒，或者响应请求的速度降低了几分之一秒，那将不会有所作为。 在谈论冷启动时，应用程序的类型很重要。 对于某些应用程序来说这只是一个问题，在这种情况下，无服务器并不是最合适的选择。

我相信大多数应用程序不会受到冷启动的影响。 即使对于大多数消费者应用程序，冷启动也不应该成为问题。 大多数移动应用程序也是如此。 同样，大多数移动应用程序不太可能会受到后端（功能）执行速度降低几分之一秒的影响。

例如，现在，如果您正在构建一个应用程序，将火箭发射到太空中，每一秒钟都可以计算在内，那么是的，冷启动是一个问题，无服务器可能不是最合适的选择。 医疗应用也可能属于此类。 我敢肯定还有其他例子，但希望您能理解。

基于无服务器方法的现代应用程序具有云功能以及各种托管服务和API。 例如，如果您需要发送短信，则可以使用Twilio或Nexmo 。 如果您需要添加付款，则可以使用Stripe或PayPal 。 如果您需要地图/位置服务，则可以使用Google Maps API或HERE 。 您可以使用成千上万的其他API来构建应用程序。 基于无服务器架构的现代应用程序将包含云功能和API。

您在应用程序中使用的外部API必须是高质量的并且来自信誉良好的供应商。 但是，您通常不必担心API背后的服务是冷启动还是热启动。 原因再次是，如果API执行速度慢了几分之一秒，那将不会有什么不同。 与我们通常不担心外部API的方式相同，在云函数的上下文中几乎没有理由担心此问题。

最后，云功能供应商很有可能在改进/升级服务时完全不做任何冷启动。

总而言之，对于大多数应用程序而言，基于无服务器的应用程序中的冷启动不是问题。 对于每一分之一秒都很重要的应用程序，无服务器方法可能不是最佳选择。

翻译自: https://www.javacodegeeks.com/2018/11/cold-start-problem-applications.html