采用无服务器的最大缺点之一，并使其适合您。

什么是冷启动？

如果您花费大量时间来构建无服务器功能，您可能会开始认为它们实在太好了。 该代码更易于管理和维护。 Azure的耐用功能通过为您提供开箱即用的复杂管道系统，帮助您成功获得成功。 此外，它们都是荒谬便宜。

我内心的怀疑者一直想知道，有什么收获？ 必须付出一些。 毫无疑问，无服务器并不是一个完美的世界，当然还有一些不足之处需要考虑。 最大的缺点之一就是冷启动。

冷启动是一个术语，用于描述未使用过一段时间的应用程序启动时间较长的现象。 （ MSDN ）

上面的MSDN文章很好地解释了冷启动是什么，它们如何工作以及为什么有必要。 为了降低成本，闲置了一段时间的无服务器应用程序将被释放。 这意味着用户第一次调用释放的函数可能会在函数加载时产生延迟。

在每个无服务器环境（Azure，AWS，Google Cloud）中，冷启动的工作方式略有不同。 但是概念是相同的。 Mikhail Skilkov在冷启动方面有很多文章。 这一个冷启动行为在每个平台上进行比较。

让我们面对现实吧，对于大多数应用而言，冷启动问题更多的是轻微的不便。 对于大多数应用程序而言，偶尔会出现几秒钟的罕见延迟并不是什么大问题。 但是对于某些用例，它可能是绝对的破坏者。 所以，我们能做些什么？

解决方案

普遍的共识是，要减少冷启动，您首先要确保应用程序永远不会“变冷”。 通常，这是通过创建一个单独的函数来完成的，该函数每隔X分钟向您的应用发出一次请求。 我将提出一种非常相似的模式，但它可以提供一些附加的业务价值。

计时器功能应用

久经考验的方法是创建一个可在计时器上运行的单独的功能应用程序。 您将计时器设置为每隔一定时间运行一次，以知道您的应用程序不会变冷。 例如，Azure Functions“闲置大约20分钟后*分配资源* ”。

因此，最好将计时器设置为每15分钟运行一次，以确保应用永远不会变冷。 或更经常地确定！ 我将再次链接到米哈伊尔·斯基尔科夫（Mikhail Skilkov）。 他还有另一篇很棒的文章，展示了这种方法的有效性。 这并不完美，但是它是掷骰子并希望您的用户不受冷启动影响的绝佳选择。

第三方监控器

如果冷启动是一个真正的问题，那么这是一个非常关键的应用程序。 对于这些应用程序，您需要获得所有保证，以确保您的应用程序不仅性能良好，而且性能出色。

无服务器功能具有很高的正常运行时间。 如果Azure的功能正常运行时间低于99.95％，它将为您带来一些荣誉。 但这并不是说它们永远不会下降或减速。 对于任务关键型应用程序，短暂的停机会造成很大的损失。 即使只有几分钟的时间，也能获得警报是一个巨大的胜利。

这就是诸如RunScope和Assertible之类的API监视工具发挥作用的地方。 这些服务使您可以设置时间表，以每隔一定的时间访问API。 他们可以对结果进行测试，并在出现任何异常情况时提醒您。 这是一个完美的冷启动器！

它与您自己的功能应用程序具有相同的概念，但具有更多优点。 首先，存在关注点分离。 如果您的功能应用程序已关闭，那么冷启动器功能（也已关闭）将无济于事。 这使您可以公正地使用第三方，以确保一切正常。

您还可以查看您的功能随着时间的推移表现如何。 既然您如此频繁地测试应用程序，您将开始看到模式。 应用程序变慢了吗？ 新功能是否增加了加载时间？ 我们可以确定生产中没有冷启动问题吗？

我没有从属关系，但是我一直是RunScope的忠实拥护者 。 而且我强烈建议您，不仅要冷启动功能应用程序，还要对所有API进行监控。 上面的概述非常不错。 另外，基于RunScope警报响应下降（例如图中的10月10日），而不是激怒用户，是无价的。

也就是说，如果您只是冷门，那么最便宜的计划每月79美元的价格可能有点高。 断言是另一个不错的选择，它甚至有免费的使用计划。 您可以使用免费套餐每30分钟发送一次请求。 消除冷启动的频率通常不够高，但是它可能会降低用户体验冷启动的频率。 另外，您还将获得所有其他好处。 如果发现用户仍然有问题，则可以升级到更合理的计划。 每月25美元的计划可让您每5分钟或更短的时间运行一次。 非常适合保持这些功能应用程序的温暖。

包起来

无论您选择做什么，很明显，在无服务器的情况下，冷启动问题都值得考虑。 毫无疑问，Azure正在致力于提高冷启动性能。 曾经有一段时间每五分钟一次，现在我们可以达到20分钟了。 但是在问题解决之前，请您自己（和您的用户）帮个忙，并使应用程序保持温暖。 在此过程中，您甚至可以从中受益。

From: https://hackernoon.com/serverless-cold-starts-using-them-to-your-advantage-3dfdf9a0bc66