速率限制、429 与升级套餐
更新于 September 1, 2026 · 首次发布 September 1, 2026
服务开始返回 429 时，人们的本能反应是把它当作可用性事故处理：提高限额、升级套餐、增加重试，尽快恢复吞吐量。这种做法有时是对的。但它也是失控循环变成五位数账单的途径，因为刚刚被移除的，正是唯一在阻止它的东西。
429 实际上在告诉你什么
它表示系统想花钱的速度超过了自己的额度。造成这种情况的原因有两种截然不同，需要的应对也完全相反。真实的需求增长，例如用户增加、产品上线、季节性高峰，说明限额确实太低，提高它能换来真实的收入。失控行为，例如重试风暴、循环运行的智能体、没有限流的回填任务、指向生产密钥的测试套件，说明限额正在恰当地履行它的职责。
仅凭错误率无法区分这两者。但如果看每单位工作的成本，就很容易分辨：真实增长时，随着量上升，比率大致保持不变；失控时，比率被打破，每完成一个任务的花费远高于前一天。这个比率应当作为每一次套餐升级的门槛。
重试会悄悄让情况更糟
遇到 429 时，如果重试没有指数退避和抖动，就会把一次超限变成同步的风暴。成功的请求会被计费，而许多失败的请求其实也已经消耗了输入处理资源。而且重试通常在客户端库中实现，而不是在应用代码里，因此这种放大效应不会出现在功能的设计文档中。
有意识地使用限额
为每个环境和每项功能设置低于服务商上限的自有限额，这样最先触发的是你自己的限额，后续如何处理也由你掌控。非生产环境要严格封顶：一次失败的测试构建成本很低，而被限流的客户路径则不然。告警应基于每任务成本比率，而不只是错误数量。升级套餐时，要把它当作一项有明确负责人的支出决策，因为它本质上就是这样的决策。
相关阅读
相关文章
想将这些方法用于您的技术栈吗？ 请准备好供应商账单、网关日志和主要工作流；我们会梳理成本驱动因素与节省空间。 预约免费审查 →