能否为含数百万Blob的容器用BlobTrigger？300万Blob处理方案咨询

是否继续使用当前的BlobTrigger函数？ #

可以临时用它处理现有文件，但绝对不适合长期运行。核心问题：

• 高规模容器下，BlobTrigger的初始全量扫描会持续占用大量存储API配额，你碰到的9分钟启动延迟就是典型表现，Blob数量越多，这个启动时间只会越长，且每次函数冷启动都会重复这个耗时的扫描过程。
• 海量Blob场景中，BlobTrigger容易出现漏触发、重复处理的情况，排查和调优成本极高，官方也明确不推荐这种高规模场景下的用法。

换用事件型方案的完整流程 #

事件型方案（Event Grid + Azure Function）是长期处理新Blob的最优解，但需要额外补充批量逻辑覆盖现有文件，具体步骤如下：

1. 先完成现有300万Blob的批量迁移 #

编写一个一次性的批量处理任务（可以是定时触发的Azure Function，或者本地Python/Shell脚本）：

• 使用Azure.Storage.Blobs SDK的分页查询能力遍历源容器，过滤出带有目标标签的Blob；避免一次性拉取所有Blob，可按Blob前缀分批次处理，或设置合理的分页大小（比如每页1000条），防止内存过载。
• 直接调用存储服务的StartCopyFromUriAsync API完成跨账户复制，这种方式比通过Function的Blob输出绑定更高效，能利用存储服务的原生复制能力，无需自行下载再上传Blob。
• 添加进度追踪机制：将已处理的Blob路径存入队列或表格存储中，若任务中断，可从断点继续处理，无需从头开始。

2. 部署事件流处理新生成的Blob #

• 为源存储账户配置Event Grid订阅，将Blob创建/修改事件推送到Azure Function。
• 编写一个Event Grid触发的Function，仅处理新产生的带标签Blob，复制逻辑与批量任务保持一致即可。
• 这种方式不存在初始扫描开销，新Blob生成后数秒内就能触发处理，完全适配长期的增量迁移需求。

3. 过渡阶段的衔接 #

在批量处理现有Blob期间，可暂时禁用原BlobTrigger函数，避免与批量任务抢占存储API资源。等批量处理完成后，再切换到Event Grid方案处理增量Blob，实现无缝衔接。

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