使用 Azure Functions 的 azure-webjobs-hosts 存储容器中的“主机”blob 的用途是什么？

Question

我有一个带有启用了服务总线触发器的 Python 函数的 Azure 函数应用程序。我注意到在与 Function App 关联的存储帐户中，有一个名为

azure-webjobs-hosts

的存储容器，其中有一个名为

locks

的文件夹。它内部有几个文件夹，其名称与我的 Function App（或我的 App Service 计划，不确定，因为它们的名称相同）完全相同，并且每个文件夹内都有一个

hosts

文件。我的函数应用程序已扩展到多个实例。每当我检查其中一个函数应用程序的

hosts

文件时，blob 的元数据始终包含单个条目，例如 。我花了无数个小时试图了解幕后发生的情况，因为我有多个实例正在运行，但只有一个“FunctionInstance”租用这个 blob。这是否会影响处理我的服务总线队列消息的其他实例？为什么这个 blob 一直只被一个实例租用？ （如果我重新启动函数应用程序，它可能会在重新启动后被另一个实例 ID 租用，所以我猜它通常是该函数应用程序的实例之一的 ID，但根据元数据，它确实由单个实例租用）即使我在这里不受影响，您能否提供一个示例，其中 Azure Functions 使用此

hosts

文件，以及为什么它会在启动时尝试锁定？

我开始在本地进行实验，以更好地了解正在发生的事情。我发现的是以下内容： 我启动的第一个函数（使用

func start

）向该 blob 发出 HEAD 请求，然后使用

comp=lease

URL 参数向该 blob 发出 PUT 请求，然后是另一个 HEAD 请求，最后在使用

comp=metadata

发出另一个 PUT 请求之后URL 参数我得到以下日志行：

Host lock lease acquired by instance ID '000000000000000000000000711A638F'.

此后，它开始处理队列中的服务总线消息。 然而，我在这台机器上启动的第二个函数永远不会收到

Host lock lease acquired by instance ID 'xxx'.

消息，它会定期向该 blob 发送 HEAD 请求，并且似乎永远不会获取该 blob 进行租赁。但是，第二个函数也由队列中的消息触发，并像第一个函数一样按预期处理它们。

请解释可租用主机文件背后的逻辑。 （PS：我的 Function App 已扩展到 3 个实例，并且我有 Azure Functions 高级计划）

Answer 1

• 主机锁租用文件保存在链接到 Function App 的存储帐户中的 azure-webjobs-hosts 容器中。

• 需要这些文件来确保您的 Function App 一次仅在一个实例中处理来自服务总线队列的消息。 Function App 实例在启动时尝试获取主机锁定文件的租约。如果成功，它将开始分析队列中的消息。如果它不起作用，它会定期检查租约的状态，并在租约可用时立即开始处理消息。

• 在 azure-webjobs-hosts 容器中，locks 文件夹包含为每个 Function App 实例命名的文件夹。每个文件夹中都存在一个包含实例租用信息的主机文件。由于函数应用程序中只有一个实例可以同时保留租约，因此 blob 的元数据始终有一个条目。

• Azure Functions 使用 locks 文件夹为您的 Function App 实现单例行为。由于单例行为，一次只有一个 Function App 实例会处理来自服务总线队列的消息。

• 主机ID冲突检测功能也是使用locks文件夹实现的。 Functions Runtime 3.x 版本及以上版本会检测主机 ID 冲突并记录警告。版本 4.x 通过记录错误并停止主机来导致硬故障。您可以在此处

  获取有关主机ID冲突的更多信息

根据这个博客：-

azure-webjobs-host容器又托管三个文件夹：-

• Heartbeats - 包含对服务执行的每个心跳检查的 0 字节日志。
• Ids - 包含具有此服务的唯一标识符的单个博客目录。
• 输出日志 - 托管每次运行的详细日志的输出。显式日志是 WebJob 开发人员添加到运行时代码中的日志。