Azure消耗计划函数解压超时，如何重路由至独立应用服务计划？

这个场景我之前帮团队踩过坑，消耗计划的10分钟超时（最多能拉到60分钟但还是有天花板）确实搞不定大文件解压。其实核心思路是把触发入口和长时任务执行解耦，下面给你拆解几种可行方案，还有最靠谱的实践方式：

消耗计划的超时是平台层面强制终止的，有时候你的代码还没来得及捕获异常就被kill了，所以更实用的方式是提前预判任务时长，而不是等超时发生再补救：

• 在触发解压的入口函数里，先获取归档文件的大小、类型（比如zip/rar的压缩比），如果预估解压时间会超过消耗计划的超时上限（比如文件大于1GB），就把任务元数据（比如Blob存储路径、目标解压位置、自定义参数）发送到Azure Storage Queue或者Service Bus Queue。
• 然后直接返回给调用方“任务已转后台处理，请稍后查看状态”，避免卡在超时上。
• 要是你非要尝试捕获超时异常，可以在代码里加CancellationToken监听取消信号（平台超时会触发这个），但成功率不高，因为平台会直接终止进程，留给你处理的时间很短。

举个简单的C#代码片段示例：

public async Task<IActionResult> Run(
    [HttpTrigger(AuthorizationLevel.Function, "post", Route = null)] HttpRequest req,
    [Queue("long-unzip-tasks")] IAsyncCollector<UnzipTask> queueCollector,
    CancellationToken cancellationToken)
{
    // 获取归档文件信息
    var fileInfo = await GetArchiveFileInfo(req);
    // 预判时长：比如超过1GB的文件走队列
    if (fileInfo.Size > 1024 * 1024 * 1024)
    {
        await queueCollector.AddAsync(new UnzipTask
        {
            BlobUri = fileInfo.BlobUri,
            TargetPath = fileInfo.TargetPath
        }, cancellationToken);
        return new OkObjectResult("任务已转后台处理，ID：XXX");
    }
    // 小文件直接在消耗计划处理
    await UnzipFile(fileInfo);
    return new OkObjectResult("解压完成");
}

用定时器定期扫待处理任务列表，然后把长任务丢到独立计划的函数——这种方式最大的问题是延迟不可控，比如定时器5分钟跑一次，任务可能要等很久才被处理，而且空跑的时候纯浪费资源，除非你有特殊的业务约束，否则完全不建议选这个。

这是Azure函数处理长时任务的标准实践，完全规避消耗计划的超时限制，还能保证可靠性：

1. 拆分函数职责：
   • 消耗计划部署「入口函数」：只做任务校验、参数解析和分流，不执行实际解压。可以是Blob触发（当有新归档文件上传时触发）、HTTP触发（用户调用触发）等。
   • 独立App Service Plan部署「解压执行函数」：专门监听队列消息，执行长时解压任务。因为App Service Plan可以配置更长的超时（默认最高120分钟，还能通过修改web.config调整更久，只要你的实例资源足够）。
2. 用队列做中间层：
   • 入口函数把长任务丢到Queue后就结束，完全不会触发超时。
   • 队列自带消息持久化和重试机制，即使解压函数挂了，消息也不会丢失，会自动重试（你可以配置重试次数和间隔）。
3. 补充细节优化：
   • 状态跟踪：如果需要给用户反馈任务状态，可以把任务ID和状态（待处理/处理中/完成/失败）存在Azure Table Storage或者SQL里，再写一个简单的HTTP函数让用户查询状态。
   • 成本优化：独立App Service Plan可以配置弹性缩放规则，比如当队列消息数超过5条时自动扩容到2个实例，空闲时缩到1个实例，避免闲置浪费。
   • 死信队列：配置队列的死信规则，把多次重试失败的任务放到死信队列，方便后期排查问题。

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