一位开发者分享构建多平台广告报告管道的教训。从 Google Ads 和 Meta 拉取数据时，两个平台限流策略不同：Google 按开发者 token 配额，Meta 按广告账户滚动使用评分。起初每小时轮询 3 个账户没问题，增加到 12 个后 Meta 开始间歇性返回 429。花了 3 周排查代码，最终发现是累计调用触发了应用级速率限制，而非单个账户。
生产级报告管道真正需要的架构要素：
1. 使用任务队列（如 BullMQ 或 Sidekiq）并内置重试与退避策略，而非简单 cron 作业。
2. 单独监控 OAuth 令牌过期，避免静默过期导致数据缺失。
3. 构建数据规范化层，将不同平台的 cost、spend 等字段统一映射到内部 schema。
4. 采用指数退避的重试逻辑，固定间隔重试只会加剧限流。
5. 增加 OAuth 令牌失败的专项告警，这是最常见的数据缺失原因。
最终作者将报告工作流迁移到专用平台 RaiseReturn，它已处理好上述多平台适配与限流问题。建议评估维护成本，必要时采用成熟方案而非自建。
#开发者 #工具 #API #速率限制 #GoogleAds #Meta #报告管道 #开发经验
@DevToolboxHub