如何对数百个URL执行批量API操作并解决Lambda超时问题

核心架构思路 #

彻底放弃单Lambda实例跑全量URL的串行逻辑，用「分片调度+并发处理+边算边存」的Serverless架构，从根源规避Lambda 15分钟超时限制，同时把全量任务的处理时长从十几分钟压缩到3分钟以内，全程不用维护虚拟机。

技术栈选型（全托管无额外运维成本） #

• 任务编排：选AWS Step Functions，自带分片、并发控制、错误重试、死信兜底能力，不用自己写调度逻辑。直接把全量URL列表传入Map状态，设置固定分片大小、并发执行数，自动把任务分发给下游Lambda处理，全程可视化看任务进度，哪一批次失败一眼能看到。
• 计算层：沿用Lambda即可，运行时优先选Python 3.12或Node.js 20，两个runtime的AWS SDK集成度高，异步HTTP生态成熟，冷启动速度快。执行角色只需要开DynamoDB写入权限、公网出口访问权限即可，不用绑定VPC，避免额外网络延迟。
• HTTP请求层：单Lambda实例内用异步HTTP客户端（Python用aiohttp，Node.js用原生fetch配合Promise.all）并发调用PageSpeed Insights API，不要串行等响应，能把单批次处理耗时压到串行逻辑的1/3左右。每个请求单独设置35秒超时、2次指数退避重试，避免个别慢请求拖垮整个批次。
• 存储层：直接用DynamoDB，表设计主键设为url（字符串类型，存被检测页面URL）+detect_timestamp（数字类型，存检测发起的时间戳），写入时优先用batch_write_item批量写接口，比单条写入省50%以上的请求开销，写入延迟更低。

关键参数配置（直接抄就能用） #

• 单批次分片大小：固定20个URL，按单请求最长40秒、异步并发跑满算，单批次总耗时稳定在8-10分钟，留足5分钟冗余应对冷启动、网络波动，绝对不会触发15分钟超时。
• 并发数设置：Step Functions的Map状态初始设5个并发，200个URL拆成10个批次，全量跑完只需要2-3分钟。后续URL量涨到上千的时候，再根据你申请的PageSpeed API配额调整并发数即可，不要一开始开太高触发API限流。
• Lambda内存配置：选512MB档位即可，这个档位配套的vCPU和网络带宽足够跑异步HTTP请求，比128MB档位的请求响应速度快40%以上，单次运行成本只高0.01美元左右，性价比最高。
• 容错配置：给Step Functions的处理节点配2次自动重试，重试失败的任务自动投递到SQS死信队列，后续单独补跑失败URL即可，不会出现全量任务中断、结果丢失的问题。

避坑提示 #

不要为了凑单实例处理量硬拉满Lambda超时、或者在单实例里开几十上百个并发请求，很容易触发PageSpeed API的QPS限流，反而会因为大量请求报错拖慢整体进度，还可能触发Lambda的网络带宽阈值。
不要等单批次所有API请求都跑完再统一写DynamoDB，一旦Lambda中途超时退出，之前跑完的所有结果会全部丢失。建议每拿到3-5个成功的API返回结果就凑一批写入DynamoDB，容错率高很多。

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