微服务调用链上超时和重试应该怎么配？什么是重试风暴？

结论：核心原则：超时必须小于上游等待预算并逐层递减（入口 3s → 服务 A 2s → 服务 B 1s），否则上游已放弃下游还在白算；重试要带指数退避 + 抖动、限制总次数（2–3 次），且只对幂等或明确可重试的接口重试。重试风暴是下游已过载时各层重试叠加放大流量（两层各重试 2 次，流量放大 9 倍），把局部慢变成整体雪崩。

展开：配置方法论：1）超时从分位数定——按 P99 延迟 ×2 起步，依赖 SLA 逐层收敛；全链路用 deadline 传播（gRPC 的 deadline、HTTP 的 X-Timeout header 或 baggage），下游感知剩余预算主动放弃；2）重试与熔断配合——重试治瞬时抖动（网络闪断、单实例重启），熔断治持续故障（错误率超阈值直接快速失败，半开试探恢复），二者不可缺一；3）retry budget 概念：客户端限制重试流量占比（如重试不超过总请求 10%），防止重试本身成为放大器，Envoy 默认有此机制。易错点：1）POST 无幂等键直接重试造成重复下单——写接口重试必须配幂等键；2）连接超时 vs 读超时混为一谈，连接池耗尽常因读超时缺失；3）SDK 默认重试策略（AWS SDK 默认 3 次）叠加自己写的重试层，层数失控。

# Envoy 示例
timeout: 2s
retry_policy:
  retry_on: connect-failure,refused-stream,5xx
  num_retries: 2
  retry_budget: { budget_percent: { value: 10 } }

追问方向：hedged request（对冲请求）与重试的区别、服务内队列隔离（bulkhead）如何限制故障爆炸半径。