调试 HTTP 503 与 Retry-After 退避

目标

当上游返回 503 时，很多客户端会立即重试，反而把恢复中的服务压垮。本配方演示如何抓取 503 与 Retry-After，把服务端的建议延迟写进客户端退避计划，并用抖动避免重试风暴，从而在高峰期保护双方。

步骤要点

1. 用 curl 复现 503，保留响应头并记录状态码与 Retry-After 的值。
2. 判断 Retry-After 是秒数还是 HTTP 日期，据此计算下一次尝试时间。
3. 在指数退避中加入抖动，并保证退避上限不超过服务端给出的值。
4. 用压测复现故障，确认请求不再集中爆发、恢复更快。

curl -sS -D - -o /dev/null -w 'status=%{http_code}\n' \
  -H 'Accept: application/json' \
  https://api.staging.example.com/v1/reports

排错提示

• Retry-After 可能是 HTTP 日期而非整数秒，需解析后与当前时间相减。
• 把 503 当作可立即重试的错误会导致重试风暴。
• 重试必须配合幂等键，否则可能重复写入。

适用边界

• 只覆盖 HTTP 层的重试信号，业务错误码需要单独策略。
• 依赖服务端确实返回 Retry-After，否则退化为普通指数退避。