Azure Functions（Python）长时间任务超时问题排查与解决

一、当前操作的疏漏点 #

你遇到的300秒超时，核心是专用应用服务计划下，除了Function的超时设置，还有App Service层面的两个关键限制没调整：

1. HTTP请求超时限制
   对于HTTP触发的函数，App Service本身的请求超时默认是5分钟（300秒），这个优先级高于AzureFunctionsJobHost__functionTimeout。你需要在Azure门户的应用服务→配置→常规设置中，把「请求超时」调整为你需要的时长（最大支持23:59:59）。

2. WebJobs idle/hang超时
   专用计划下，WebJobs（Azure Functions本质是WebJobs）的默认空闲超时和挂起超时都是5分钟，需要通过应用设置添加以下配置：

   • WEBJOBS_IDLE_TIMEOUT：设置为86399（对应23小时59分59秒，单位是秒）
   • WEBJOBS_HANG_TIMEOUT：同样设置为86399

3. 确认functionTimeout配置正确性
   检查应用设置的键是否是AzureFunctionsJobHost__functionTimeout（注意是双下划线），值的格式是否为23:50:00，避免拼写错误。

二、是否需要切换到Durable Functions或消耗计划？ #

• 消耗计划不建议：消耗计划的函数超时最大只能设置为10分钟，远不足以处理7万个Blob的批量任务，直接排除。
• Durable Functions是更优解，但非必须：
  如果你调整了上述专用计划的配置，理论上可以完成任务，但单次长时间运行的HTTP触发函数存在风险（比如中途网络波动、应用重启都会导致任务失败，且无法断点续跑）。
  Durable Functions可以把大任务拆分为多个小的活动函数（比如每次处理100个Blob），通过编排器函数协调执行，支持自动重试、断点续跑，即使出现异常也能从失败点继续，稳定性更高。

三、额外优化建议 #

• 控制Blob处理并发数：用Parallel.ForEachAsync处理Blob时，设置合理的MaxDegreeOfParallelism（比如20-50，根据Blob Storage的配额调整），避免触发限流。
• 改用队列触发模式：HTTP触发函数只负责把要处理的Blob列表（或Blob前缀）写入队列，然后用队列触发函数批量处理，这样HTTP请求可以快速返回，避免长时间占用HTTP连接导致超时。
• 启用SDK重试策略：使用Azure.Storage.Blobs SDK时，配置BlobClientOptions.Retry策略，应对临时的网络或服务错误。

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