Azure Function App长时间运行编排器停滞问题咨询

1. 是否有人遇到过类似情况？ #

很多运行长时间Durable编排的开发者都碰到过这类问题，尤其是编排持续超过1小时后出现无响应、日志停滞的情况。常见诱因包括Durable扩展包的旧版本bug、存储账户的连接/节流问题，以及Premium Plan的资源或配置限制。

2. 是否应将扩展包更新至[4.0.0, 5.0.0)？ #

强烈建议优先尝试更新到这个版本区间。3.x及更早的Durable扩展包在处理长时间编排的心跳续约、存储锁机制上存在稳定性缺陷，会导致编排器运行一段时间后失去与存储账户的同步，进而停滞。4.x版本修复了大量这类问题，优化了重试逻辑和心跳超时处理。
更新前注意：

• 确认Node.js版本符合要求（4.x扩展包支持Node.js 14及以上）
• 检查代码中是否使用了已废弃的API
• 先在测试环境验证，避免影响生产

3. 存储账户是否可能是问题所在？是否需要创建新的存储账户？ #

存储账户是Durable Functions的核心依赖（用于队列、表存储管理编排状态），大概率是潜在诱因之一。可以从以下方面排查：

• 查看存储账户的Azure Monitor指标：重点看队列消息处理延迟、表存储请求失败率、节流错误数，如果出现频繁节流或请求失败，说明存储性能不足或连接异常。
• 检查表存储的分区策略：如果大量编排实例使用相同的分区键，会造成热点问题，导致存储操作阻塞。
  如果排查到是存储账户的问题：
• 先尝试升级存储账户的性能层级（比如从标准存储转为高级存储），提升吞吐量
• 如果是存储账户本身存在未知的连接故障，可以创建新的高级存储账户，重新配置Function App的AzureWebJobsStorage连接字符串，测试是否解决问题

4. Premium Plan是否触碰到了限制？具体是什么，该提升哪些配置？ #

Premium Plan确实存在几个可能导致停滞的限制，对应调整配置如下：

• 编排锁自动续约超时：Durable Functions默认的maxAutoRenewDuration是1小时，你的编排运行2小时已超过这个时间，会导致编排器的存储锁过期，无法继续调度活动。需要在host.json中调整该参数：

{
  "extensions": {
    "durableTask": {
      "maxAutoRenewDuration": "03:00:00"
    }
  }
}

• 实例资源不足：Premium Plan的每个实例有CPU、内存限制（比如EP1实例是1vCPU、3.5GB内存），如果活动函数占用资源较高，并行5个可能耗尽实例资源。查看Azure Monitor中Function App的CPU、内存使用率，若持续超过80%，建议：
  • 提升实例SKU（从EP1升级到EP2/EP3）
  • 增加实例计数，或开启自动缩放规则
• 实例空闲误判：如果编排的心跳间隔过长，可能被Premium Plan的缩放机制误判为空闲而回收实例。可以调整durableTask的heartbeatInterval参数缩短心跳间隔，同时设置Premium Plan的实例保留时间（避免warm-up实例被快速回收）

内容的提问来源于stack exchange，提问作者WillD