Azure功能：生命周期如何运作？

Question

我遇到了Azure功能的一些问题，其中功能应用程序部署得很好并且运行良好，现在声称缺少依赖项（NodeJS）并且在测试时第二天出错。如果我了解Azure Functions如何工作的生命周期，我想我可以更轻松地解决这个问题。

任何人都可以解释生命周期或指出我似乎无法找到的文档吗？

例如，我正在使用持续部署。使用此方法，似乎有一个默认的deploy.cmd用于：

1. Git clone /将存储库拉到D：\ Site \ repository
2. 在存储库上运行npm install。
3. Kudosync（无论这意味着什么）这些文件到D：\ Site \ wwwroot

这一切都很美妙。我想知道接下来会发生什么。

e.g。该函数在一段时间内未被使用，因此我认为它被旋转并被“无序”？

当它再次访问时，它需要再次旋转一些东西。

• 是否再次完成部署过程（看起来不像）。
• 将文件还原到实例的内容/位置/方式是什么？
• 这是缩放应用程序时使用的相同过程吗？

Answer 1

当您向Azure Functions部署某些内容时，有一些选项可供选择，但大多数选项都会通过您.scm site（aka.Kudu）。 Kudu为您与文件系统进行交互，通常是某种类型的网络共享（对于消费计划，它是Azure文件;对于App Service计划，它已内置到App Service中）。

所以，让我们通过Kudu向我的功能应用程序说明git push内容，在内容更新后，Kudu将获取存储库中的内容并且＆＃34;部署＆＃34;在运行您已经拥有的任何部署脚本后，它到./site/wwwroot文件夹。

然后，Function App的主机会看到文件更改，并获取对您的功能的更改。如果给定实例上的函数将任何内容写入磁盘，则其他实例也会看到它。

这是一个非常简化的图表：

正如Fabio所提到的，我们现在有一个open issue用于需要加载大量文件的函数（即使它只需要1个语句，也可能有数百个由于Azure文件处理大量请求的速度很慢，特别是在扩展加载时，由于Azure文件处理大量请求的速度很慢，因此导致它们第一次加载的时间非常长。我们已经有计划在不久的将来解决这个问题。与此同时，您可以使用App Service计划或减少相关文件的数量（即使内容大小大致相同）。