如何限制Logic App (Standard)工作流实例的并发运行数量

1. 修复host.json配置不生效的问题 #

你之前调整host.json没达到效果，基本都是配置路径写错导致的。非会话模式Service Bus触发器+工作流编排（带延迟、Compose节点的Durable Task/Logic Apps Standard编排）的正确配置必须同时覆盖触发器层和编排层两个维度，参考如下：

{
  "version": "2.0",
  "extensions": {
    // Service Bus触发器层并发控制
    "serviceBus": {
      // 单实例同时拉取并启动处理的最大消息数，默认值为16，这就是你发10条消息立刻启动10个实例的原因
      "maxConcurrentCalls": 2,
      // 预取数必须小于等于maxConcurrentCalls，避免提前拉取过多消息堆积在本地缓存
      "prefetchCount": 2,
      "autoCompleteMessages": true,
      "maxAutoLockRenewalDuration": "00:05:00"
    },
    // 工作流编排层并发控制
    "durableTask": {
      // 单实例同时运行的最大编排实例数，如果你流程里有内置延迟（持久化定时器实现的等待），必须配置这个参数
      // 持久化延迟不会占用触发器的并发配额，不配置的话触发器拉取消息启动编排后就会释放配额拉取下一条，还是会出现大量实例同时运行的情况
      "maxConcurrentOrchestratorFunctions": 2,
      "maxConcurrentActivityFunctions": 4
    }
  }
}

注意：所有并发相关配置必须放在extensions对应子节点下，不要写在根节点、logging、functionTimeout等无关节点下，否则配置完全不生效。配置修改后必须重启应用实例才会加载。

2. 全局总并发控制（避免多实例扩容后总并发过高冲垮SQL） #

• 如果你用的是专用计划/Premium计划部署：直接配置应用的横向扩容规则，设置最大实例数即可。比如单实例配置maxConcurrentCalls=4、maxConcurrentOrchestratorFunctions=4，要把总并发控制在20以内，就把最大扩容实例数设为5，总并发就会稳定在阈值内。
• 如果你用的是无服务器消费计划：无法直接限制最大扩容实例数，建议把prefetchCount和maxConcurrentCalls设为一致的较小值，同时给Service Bus队列配置消息限流规则，避免短时间内大量消息同时涌入分发通道。

3. 硬限流兜底方案 #

如果需要严格的并发数控制（比如总并发必须固定为N，不允许任何突发流量超过阈值），建议把非会话模式切换为会话模式Service Bus触发：

• 给消息分配固定数量的会话ID，比如要限制总并发为10，就给所有消息循环分配10个固定的SessionId值
• 在host.json中配置serviceBus.maxConcurrentSessions为你需要的总并发数
  这种模式下Service Bus会以会话为粒度加锁，同一时间最多只会有配置数量的消息被处理，属于硬限流，完全不会出现并发突增的问题，最适合下游SQL DB抗压能力弱的场景。

验证方法 #

配置完成后，你可以用之前的测试流程复现：提交10条测试消息，不会再出现10个实例同时激活的情况，会按照你配置的并发阈值逐步启动实例处理，等运行中的实例完成（或进入持久化等待状态但占满编排并发配额）后才会启动下一批实例。

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