Azure Logic Apps解析大JSON文件（最大300MB）的最佳实践咨询

• 替换有状态工作流为无状态+高规格缩放层
  有状态工作流会持久化每一步的运行状态，处理30万条级别的数据时，状态持久化的开销会严重拖慢性能。换成无状态工作流后，无需存储中间状态，运行效率大幅提升。同时将WS1升级至WS2/WS3层，这类层级提供更高的CPU和内存配额，能更快完成大JSON的解析与遍历操作。

• 手动拆分数组+并行执行，替代单线程遍历
  数据源无法拆分的话，就在Logic Apps内部处理：用split()函数结合数组索引，将30万对象的大数组拆分为多个小批次（比如每批次1000条）。接着用Parallel Branch组件对这些小批次并行处理，分支数量根据缩放层调整——WS2可设置10-20个，WS3设置20-30个，能把整体处理时间压缩到原有的几分之一。

• 优化JSON解析与转换逻辑
  避免在遍历的每一步重复解析整个JSON，在工作流开头就用json()函数一次性将下载内容转换为数组，后续直接操作数组元素即可。如果转换逻辑复杂，将其封装到Azure Function（用C#或Python编写）中，让Logic Apps将批次数据传给Function处理——Function的计算性能远优于Logic Apps的低代码步骤，能减少大量不必要的开销。

• 批量推送至Service Bus，避免单条发送
  单条推送消息会产生大量网络请求，改为批量推送：每收集100-500条转换后的数据，调用Send Batch Messages操作，大幅降低请求次数。同时确保Service Bus为Premium层，它提供更高的吞吐量和更低的延迟，不会成为流程瓶颈。

• 用Blob Storage做中间缓冲，配合流式处理
  先将下载的JSON保存到Azure Blob Storage，再用消费计划的Logic Apps触发，读取Blob时开启流式处理选项——无需将300MB的完整文件加载到内存，可边读边拆边处理。若Logic Apps性能仍不足，换成Azure Data Factory处理大JSON：它的Lookup活动支持分页和批量读取，拆分后可直接推送至Service Bus或转给Logic Apps，ADF在处理大数据集上天生更高效。

• 调整工作流超时与重试策略
  将工作流超时时间调整至合理范围（比如8小时），避免处理中途因超时终止。对Service Bus推送步骤设置指数退避的重试策略，结合批量处理可减少重试次数，降低重复推送的风险。

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