超时、重试、熔断与限流

分布式系统中，下游可能变慢、部分失败或返回不确定结果。容错的目标不是掩盖所有错误，而是限制等待时间、控制故障扩散，并给系统恢复空间。

一次调用的保护顺序

请求进入
  → 限流：系统是否还有容量
  → 并发/连接池隔离：最多占用多少资源
  → 超时：最多等待多久
  → 重试：失败是否安全重做
  → 熔断：持续失败时是否快速拒绝
  → 降级：能否返回缓存或部分结果

超时预算

上游超时必须大于其内部各步骤实际预算，但不能简单相加成无限等待：

客户端总预算 2s
  → Gateway 1.8s
  → 订单服务 1.5s
  → 库存调用 400ms，最多重试 1 次

连接超时、读取超时、连接池等待超时要分别设置。没有超时会让线程、连接和内存逐步耗尽。

重试原则

• 只对瞬时失败和幂等操作重试。
• 使用指数退避和随机抖动，设置次数及总时间上限。
• 不要在客户端、Gateway、服务框架和 SDK 每层同时重试。
• 写操作使用幂等键、唯一约束或业务状态机防止重复。
• 超时不代表下游未执行，尤其是支付、扣库存等操作。

熔断、隔离与限流

熔断器根据近期失败或慢调用比例暂时停止请求，经过半开探测后决定恢复。它保护上游资源，但不能修复下游。线程池、连接池、Semaphore 和 Kubernetes 资源限制用于隔离不同依赖和工作负载。

限流应明确维度：全局、租户、用户、接口或实例；明确超限返回、排队长度和重试提示。只在单实例内限流时，扩容会改变总限额。

防止级联故障

风险	保护措施
下游变慢占满线程	短超时、并发隔离、连接池监控
大量请求同时重试	统一重试层、退避抖动、重试预算
单个租户打满服务	租户级限流和配额
非核心依赖拖垮主流程	异步化、降级、缓存、独立资源池
恢复瞬间流量洪峰	慢启动、预热、逐步放量

告警应观察错误率、P95/P99、超时、重试次数、熔断状态、限流量、线程池/连接池饱和度，而不是只看进程是否存活。