背压要给出明确信号
系统过载时应该返回明确信号，而不是无限排队等着：限流或过载用 429，可带等待时间提示让客户端退避；实例不可用或正在摘除用 503，客户端可以改投其它实例。让客户端知道该等还是该换，是有序退化的前提。
基本信息
| 429 | 限流或过载，退避后重试 |
|---|---|
| 503 | 实例不可用，可换实例 |
| Retry-After | 建议等待时间 |
| 队列 | 必须设有上限 |
| 原则 | 宁可明确拒绝，不要无限排队 |
典型使用场景
- 设计网关的过载保护策略
- 实现客户端 SDK 的退避逻辑
- 多实例环境下引导重试到健康实例
- 事故复盘时判断是否缺少背压机制
- 在客户端文档里写明哪些状态码该重试、哪些该放弃
- 把过载触发的频率纳入监控，长期偏高说明容量确实不足
状态码语义
状态码语义
# 429 Too Many Requests：限流/过载，退避后重试
# 503 Service Unavailable：实例不可用或摘除中，可重试其它实例
# Retry-After：建议等待秒数（秒或 HTTP 日期）
# 客户端侧：分别识别 429 与 503，做退避与切换客户端该怎么做
| 状态码 | 语义 | 客户端动作 |
|---|---|---|
| 429 | 限流或过载 | 按提示退避后重试 |
| 503 | 实例不可用 | 换实例重试 |
| 500/502 | 服务侧失败 | 有限重试并告警 |
网关队列必须有上限：无界排队会把长尾拖成全员超时，阈值按排队时长的 P95 目标设定。
退避要带随机抖动：所有客户端按同一节奏重试，会在已经过载的服务上形成整齐的冲击波。
过载保护要分层：网关先挡粗粒度的突发流量，应用层再按调用方限制并发，两层都设上限才不会互相推高。
健康检查要与背压配合：实例被摘除期间应快速返回 503 而不是让连接超时，客户端才有机会尽快切换。
把重试与退避行为写进接入规范：每个客户端各写一套，过载时会出现互相矛盾的退避节奏。