Azure Functions：生命周期如何运作？
Dou*_*oug 0 architecture lifecycle azure-functions
我遇到了 Azure Functions 的一些问题，其中一个 Function App 部署正确且运行良好，现在声称缺少依赖项 (NodeJS) 并在第二天测试时出错。如果我了解 Azure Functions 工作方式的生命周期，我想我可以更轻松地进行故障排除和修复。
任何人都可以解释生命周期或指向我似乎找不到的文档吗？
例如，我正在使用持续部署。使用这种方法，似乎有一个默认的 deploy.cmd 用于：
- Git 克隆/将存储库拉到 D:\Site\repository
- 在存储库上运行 npm install。
- Kudosync（不管这意味着什么）这些文件到 D:\Site\wwwroot
这一切都很好。我想知道接下来会发生什么。
例如，该功能在一段时间内未使用，因此我认为它已停止运行并“无序”？
当它再次访问时，它需要再次启动一些东西。
- 它是否再次经历了部署过程（似乎不像）。
- 什么/在哪里/如何将文件恢复到实例？
- 这与扩展应用程序时使用的过程相同吗？
将某些内容部署到 Azure Functions 时，有几个选项，但大多数都通过 .scm 站点（又名 Kudu）。Kudu 为您与文件系统交互，这通常是某种网络共享（对于消费计划，它是 Azure 文件；对于应用服务计划，它内置于应用服务中）。
因此，假设我git push通过 Kudu 向我的 Function App 发送内容，在内容更新后，Kudu 将获取存储库中的内容，并./site/wwwroot在运行您拥有的任何部署脚本后将其“部署”到文件夹中。
然后，函数应用程序的主机会看到文件更改，并获取对函数的更改。如果给定实例上的函数将任何内容写入磁盘，其他实例也会看到它。
这是一个非常简化的外观图：
正如 Fabio 所提到的，我们现在有一个未解决的问题，因为函数有大量需要加载的文件（即使它只是 1 个 require 语句，它可能依赖于数百个文件）导致它们由于 Azure 文件处理大量请求的速度很慢，尤其是在缩放负载下，因此首次加载需要异常长的时间。我们有一个计划在不久的将来解决这个问题。同时，您可以使用应用服务计划或减少依赖文件的数量（即使内容大小大致相同）。