Azure Functions：生命周期如何工作？答案

【问题标题】：Azure Functions: How does the life-cycle work?Azure Functions：生命周期如何工作？
【发布时间】：2017-01-20 08:48:28
【问题描述】：

我在使用 Azure Functions 时遇到了一些问题，其中一个正确部署且运行良好的函数应用程序现在声称缺少依赖项 (NodeJS)，并在第二天测试时出错。如果我了解 Azure Functions 工作原理的生命周期，我想我可以更轻松地进行故障排除和修复。

谁能解释一下生命周期或指向我似乎找不到的文档？

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

Git 克隆/拉取存储库到 D:\Site\repository
在存储库上运行 npm install。
Kudosync（无论这意味着什么）这些文件到 D:\Site\wwwroot

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

例如该函数在一段时间内未使用，因此我假设它已停止运行并“无序”？

当它再次访问时，它需要再次启动。

它是否再次通过部署过程（看起来不像）。
什么/在哪里/如何将文件恢复到实例？
这与扩展应用程序时使用的过程相同吗？

【问题讨论】：

您能否提供一些详细信息，例如您看到的错误消息？部署发生一次，然后各个实例使用网络共享来访问内容。因此，如果它工作一次，那么它应该会再次工作，直到下一次部署。
这绝对不是我的经验。有人告诉我，前一天安装并运行的 npm 模块丢失了。
是否有任何错误情况会导致不同的结果？
您可能会遇到此问题：github.com/Azure/azure-webjobs-sdk-script/issues/298 但我在推测。如果您可以分享有关您看到的错误的详细信息，那将有所帮助。
@ChrisAnderson-MSFT 如果你想写一个网络共享/等的概述，我肯定会接受它作为这个答案（因为这是我的问题）。

标签： architecture lifecycle azure-functions

【解决方案1】：

当您将某些内容部署到 Azure Functions 时，有几个选项，但大多数都通过您的 .scm 站点（又名 Kudu）。 Kudu 为您与文件系统交互，这通常是某种网络共享（对于消费计划，它是 Azure 文件；对于应用服务计划，它内置在应用服务中）。

假设我通过 Kudu 将 git push 内容添加到我的 Function App，内容更新后，Kudu 将获取存储库中的内容并在运行您的任何部署脚本后将其“部署”到 ./site/wwwroot 文件夹'有。

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

这是一个非常简化的图表，它看起来如何：

正如 Fabio 提到的，我们现在有一个 open issue 用于需要加载大量文件的函数（即使它只有 1 个 require 语句，它也可能依赖于数百个文件）这导致它们在第一次加载时花费异常长的时间，因为 Azure 文件处理大量请求的速度很慢，尤其是在缩放负载下。我们计划在不久的将来解决这个问题。同时，您可以使用应用服务计划或减少依赖文件的数量（即使内容大小大致相同）。

【讨论】：