Azure队列触发器启动Durable Orchestration后如何等待其执行完成？

• 执行时长超限风险：Azure 函数消费计划下单实例默认最大执行时长为5分钟，最高可配置到10分钟，若Orchestration执行时长超过该阈值，队列触发函数会被强制回收，对应队列消息会被重新放回队列，导致重复触发Orchestration的问题。就算使用支持无限制执行时长的专用计划/弹性Premium计划，队列消息的不可见期续租也存在上限，长时间挂起会导致消息被其他实例重新拾取。
• 不必要的性能开销：自行实现的do-while轮询没有退避策略，会频繁调用Durable任务状态查询接口，产生多余的API开销，同时长时间挂起的队列触发函数会占用执行资源，挤占其他函数的运行配额。
• 并行度控制不彻底：存储队列默认并行拾取16条消息的逻辑不会因为单实例挂起而改变，初始仍然会同时启动16个Orchestration，无法实现自定义更低并行度的需求。

场景1：Orchestration执行时长不超过10分钟 #

直接调整队列触发配置+使用Durable客户端内置等待方法即可：

1. 首先在host.json中配置队列并行度，按你需要的最大同时运行Orchestration数量设置batchSize：

{
  "version": "2.0",
  "extensions": {
    "queues": {
      "batchSize": 1, // 示例为串行处理，需要2个并行就设为2，以此类推
      "newBatchThreshold": 0
    }
  }
}

2. 优化队列触发函数代码，替换自行实现的轮询逻辑，WaitForCompletionAsync内置指数退避策略，可大幅降低不必要的查询开销：

public class QueueTrigger
{
    [FunctionName(nameof(QueueTrigger))]
    public async Task Run([QueueTrigger("queue-processing-test", Connection = "AzureWebJobsStorage")]Activity activity, [DurableClient] IDurableOrchestrationClient starter, ILogger log)
    {
        log.LogInformation($"C# Queue trigger function processed: {activity.ActivityId}");
        string instanceId = await starter.StartNewAsync<Activity>(nameof(ActivityProcessingOrchestrator), activity);            
        log.LogInformation($"Started orchestration with ID = '{instanceId}'.");
        // 第一个参数为实例ID，第二个为初始轮询间隔，第三个为最长等待时间
        await starter.WaitForCompletionAsync(instanceId, TimeSpan.FromSeconds(2), TimeSpan.FromMinutes(10));
    }
}

场景2：Orchestration执行时长超过10分钟 #

不要在队列触发函数中做等待逻辑，改用Durable Entity作为调度器控制并行数：

• 队列触发函数仅负责将待处理的Activity信息写入Durable Entity的内部待处理队列
• Durable Entity维护当前运行中的Orchestration计数，当计数低于设定的并行阈值时，自动从待处理队列中取出任务启动Orchestration
• 每个Orchestration执行完成后回调通知Durable Entity，减少运行计数并触发下一个任务的启动
  该方案完全避免了长时间挂起函数实例的问题，可支持超长运行任务的并行度管控。

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