依赖韧性：超时重试、熔断降级与舱壁隔离

网络抖动、服务宕机、过载——远程依赖永远无法保证百分百可用。超时预算决定慢请求挂多久；重试把瞬态故障变成成功率；熔断在下游持续异常时主动插断；降级保住核心可用；集群容错与舱壁隔离把故障关在局部。五道防线各有分工，合在一起才能挡住从单点失败演变成雪崩的连锁崩塌。

本篇将超时重试、熔断降级、集群容错与舱壁隔离三个互相关联的话题合并为一条防线完整讲清，并给出叠加配置样例。

TL;DR

• 雪崩本质：线程池耗尽的级联传播；防线目标是在链路中插断点、设上限。
• 超时五类：connect / read / write / pool-acquire / deadline，需按场景选配；调用链上每跳超时必须严格小于上游超时。
• 重试：只重试可重试错误（5xx / 超时 / 连接重置）；次数 ≤3；梯度退避 + 抖动；非幂等写必须携带幂等键。
• 熔断三态：Closed → 错误率超阈值 → Open（直接 fallback）→ Half-Open 试探 → 恢复 Closed；阈值从 50% 开始调。
• 降级：熔断是降级的一种实现手段；降级预案需提前设计，临时决策来不及。
• 集群容错：Failover 用于幂等读，Failfast 用于非幂等写，Failsafe 用于旁路，Failback 用于异步补偿。
• 舱壁隔离：线程池隔离是防雪崩扩散最直接的手段；阻塞 I/O 用线程池，快速降级用信号量。
• 叠加顺序：限流 → 超时 → 熔断 → 隔离 → 降级；顺序不能颠倒。

Table of contents

1. 雪崩从何而来，防线如何分层

调用链任一节点故障，都可能沿依赖向上游扩散成雪崩。

分布式调用链上，C 慢下来 → B 的线程等待 C 堆积 → B 的线程池耗尽 → B 请求开始失败 → A 等待 B 也开始堆积 → A 跟着不可用。雪崩的底层机制不是 Bug，而是线程这种共享资源的级联耗尽。

单靠某一手段无法解决所有场景：超时能让慢请求快速失败，但不能让系统在大量失败后自动恢复；熔断能阻止对故障依赖的持续调用，但无法防止故障在线程维度跨依赖扩散；隔离能限制扩散半径，但无法自动从错误中恢复业务。因此防线的设计是分层叠加，各管一段：

2. 超时：分类、取值与调用链预算

2.1 五种超时类型

“超时”不是一个单一概念，一次完整远程调用有多个阶段都可能卡住：

• 连接超时（ConnectTimeout）：完成 TCP 三次握手的最长等待，通常 1–5s；超时说明网络不通或对端无法接受新连接（端口未监听、连接队列满）。
• 读取超时（ReadTimeout）：连接建立后等待服务端返回响应的最长时间——这是生产中最需关注的超时类型，直接决定慢请求能堆积多久。读超时太长，慢请求持续占满线程池；太短，正常处理耗时较长的接口频繁误触发。
• 写超时（WriteTimeout）：将请求体写入连接的最长时间，仅在发送大 body（如文件上传）时才需单独配置。
• 连接池获取超时（Pool-Acquire Timeout）：从连接池取可用连接的最长等待；超出则快速失败，避免请求在内存中堆积。
• 总体截止时间（Overall Deadline）：含重试在内的端到端最长允许时间；一旦到达 deadline 立即放弃，不再发新请求。

建连与等响应是两段超时；不设上限，连接和请求就会堆成山。

2.2 超时值怎么定

一句话：超时太高等于没设；太低会触发重试风暴——先给普适值，再按监控动态调。

• 读取超时：以 1500ms 为基准；延迟敏感场景可缩短，处理本身耗时长的接口可适当延长，但不建议超过 10s。
• 连接超时：1000ms–5000ms，通常可比读取超时略宽。
• 最佳实践：超时值做成可配置参数（放入配置中心），而非硬编码——可按实时状态动态调整，无需重新发布服务。

2.3 调用链上的超时预算（Deadline Propagation）

客户端（5s）→ 网关（4s）→ 服务 A（3s）→ 服务 B（2s）→ 服务 C（1s）

规则：每跳超时必须严格小于上游超时。 若 A 和网关超时相同，网关先超时断连后 A 仍在等 B，这段等待成了无人接收的僵尸请求，白耗下游资源。

实践建议：网关维护全局请求 deadline，通过请求头（如 X-Request-Deadline 或 gRPC Deadline）向下游传播；每个下游从剩余 budget 中扣除自身处理预算；若剩余 budget 不足，直接拒绝而非带负预算发出注定超时的请求。这是 Google gRPC 内部基础设施的核心设计原则，能有效防止调用链末端的慢服务耗光全链路时间。

3. 重试：瞬态故障的对冲

3.1 可重试与不可重试错误

重试是用额外资源换更高成功率，只对瞬态/偶然性故障有意义。

可重试：HTTP 503 / gRPC UNAVAILABLE、网络超时（ConnectTimeout / ReadTimeout）、TCP 连接重置、HTTP 429（配合退避）。

不可重试：HTTP 4xx（参数错误、认证失败、资源不存在）、业务层拒绝（余额不足、订单已关闭）、无幂等保护的非幂等写操作。

核心判断：重试能否改变结果，且重试是否安全（不产生副作用）——两者同时满足才应重试。

3.2 退避策略与抖动

固定间隔：每次间隔相同（如 1.5s），实现简单，适合恢复时间稳定可预期的场景。

梯度退避（Exponential Backoff）+ 抖动（Jitter）：第 1 次等 1s±300ms，第 2 次等 2s±600ms，第 3 次等 4s±1200ms。指数增长避免持续冲击下游；随机抖动把多个客户端的同步重试打散，防止”惊群效应”形成新的流量尖峰——AWS Builder’s Library 明确将带 jitter 的退避列为生产最佳实践。

固定间隔简单；梯度退避更柔——次数建议 ≤3，并配合幂等。

3.3 重试次数与幂等

次数：建议不超过 3 次——下游持续不可用时，无限重试只会放大故障。

幂等键：超时后服务端可能已成功处理请求，只是响应在传输中延迟或丢失。naive 重试会导致重复扣款、重复发货。解法是在请求中携带全局唯一的 requestId（idempotency key），服务端执行前先查询该 key 是否已处理：已处理则直接返回上次结果；处理中则返回处理中状态；未处理则正常执行，并原子地持久化 key 与结果。

幂等键通常存入 Redis（TTL 设为最大重试周期的 2–3 倍），检查与写入需在分布式锁或事务中完成，防止并发竞态的 check-then-act 问题。

超时后服务端可能已成功；带 requestId 做幂等，重试才安全。

3.4 对冲请求（Hedged Requests）

对冲是更激进的尾延迟优化：第一个请求发出后，若在 P95 阈值内未返回，立即向另一个实例发出同样请求，取最先返回的结果，忽略较慢的那个。与重试的区别在于：重试在失败后等待再发，对冲在超时前并发发出，用额外资源换更低尾延迟。对幂等要求更严格（两个请求可能同时被处理），适合只读查询、缓存读取等资源充裕场景。Google Spanner 和 Bigtable 内部广泛使用此技术压制尾延迟。

4. 熔断：三态断路器

4.1 Closed / Open / Half-Open

熔断来源于电子工程断路器：下游持续失败时，上游暂停对其调用，直接走本地 fallback，待下游恢复后重新接通。

Closed → Open → Half-Open：错误率超阈值就断，试探成功再合上。

• Closed（正常）：请求正常转发，熔断器持续统计成功/失败比率，不影响业务调用。
• Open（熔断）：错误率达阈值后进入，后续请求不过网络，直接走本地 fallback，线程瞬间释放，不再堆积。
• Half-Open（试探）：Open 持续一段时间后自动进入，放行少量请求探测下游；成功率达标则回到 Closed，否则重回 Open。

一句话：熔断不是永久关掉下游，而是先快速失败释放资源，再周期性试探，好了再接回来。

4.2 关键参数

统计使用滑动窗口（通常无锁循环队列），按成功、失败、超时、拒绝分类计数；只计 5xx/超时，不计 4xx——4xx 是调用方 Bug，不代表下游故障，混入统计会用调用方的错误逻辑触发熔断。

4.3 Fallback 设计模式

熔断 Open 后请求直接走 fallback，fallback 设计决定降级体验：

• 默认值/空响应：返回预设安全默认值（空列表、0、null），实现最简单，适合对结果不敏感的场景（如推荐列表）。
• 缓存快照：返回本地缓存或 Redis 中上次成功的结果，适合时效性要求不极端的场景（商品价格、配置项）；下游恢复后需及时失效缓存。
• 降级 UI：前端/API 层隐藏该功能入口，或显示”功能暂时不可用”；适合独立功能模块（评论区、活动弹窗）。
• 异步队列写入：写操作先写入消息队列，待下游恢复后消费处理；适合对实时性要求不高的写入（日志上报、非关键事件）。

关键原则：fallback 里绝对不能再调故障依赖——否则等于把熔断器绕过去了，防护形同虚设。

静默熔断风险：熔断 Open 后 fallback 默默返回默认值，系统表面”正常运行”，监控无告警——下游宕机无人知晓，根因长期得不到处理。熔断状态变更本身就应该是一个告警触发条件，建议在监控中单独暴露”当前处于 Open 状态的熔断器数量”指标，并对非零值告警。

4.4 Sentinel vs Resilience4j

5. 降级：用功能完整性换稳定性

服务降级指在系统压力剧增时，选择性延迟或暂停非核心功能，将资源集中保障核心能力的可用性。降级本质是取舍：用功能完整性换稳定性。

5.1 分类

• 按自动化程度：自动降级（监控指标触发）、人工降级（运维手动操作）。
• 按功能维度：读服务降级（返回缓存或默认值）、写服务降级（异步化或暂时拒绝）。
• 按粒度：服务级（对某下游所有调用走 fallback）→ 功能级（只降级出问题的具体接口）→ 请求级（按用户优先级选择性降级）。粒度越细对用户影响越小，实现成本越高；建议先做服务级降级（门槛最低），再按实际需要细化。

5.2 常见降级策略

• 限流降级：超额请求返回固定降级响应，而非直接报错。
• 熔断降级：熔断 Open 后调用直接走本地 fallback，是熔断作为降级手段的典型体现。
• 页面降级：向用户展示”服务繁忙，请稍后重试”，暂停非关键功能。
• 延迟持久化：页面展示照常，数据变更先写异步队列，服务恢复后批量处理。

5.3 降级预案与告警分级

降级预案需要在故障发生前就设计好：明确哪些服务可降级、降级后的 fallback 是什么、用户看到什么。临时决策往往来不及也容易出错。

5.4 熔断与降级的关系

6. 集群容错：失败后去哪

集群提供冗余的物质基础；容错策略决定「失败后去哪」。

6.1 Failover：失效转移

调用异常时，自动切到集群中下一个可用实例重试，重试次数通常 ≤3。适合幂等读操作（查询用户信息、获取商品详情、状态查询）。

对无幂等键保护的非幂等写操作，Failover 在”请求已被服务端处理但响应丢失”的场景下会导致重复扣款、重复创建——此类操作应优先选 Failfast。

失败后切下一个实例，并限制最大重试次数，避免无限重试。

6.2 Failback / Failsafe / Failfast

Failback 记后重试，Failsafe 忽略记日志，Failfast 立即报错。

• Failback（失败后异步补偿）：请求失败时将失败记录下来，通过定时任务周期性重试直到成功；不阻塞当前请求。适合时效性要求不高的旁路操作（通知发送、CRM 同步）。
• Failsafe（失败可忽略）：调用异常直接忽略，写入审计日志，不中断主流程、不重试。适合埋点上报、审计日志记录、监控打点——此类操作失败不应影响主业务。
• Failfast（立即失败）：调用异常立即报错，不做任何重试。理念是宁可明确报错让上层处理，也不用重试掩盖问题。适合非幂等写操作（创建订单、支付扣款）及熔断 Open 状态下的快速拒绝。

6.3 Forking 与 Broadcast

• Forking（分支调用）：同时向多个实例发出请求，取最先成功的结果。用额外资源换极低延迟，适合实时性要求极高、资源充裕的读场景（实时推荐排序，同时打 3 个实例取最快响应）。
• Broadcast（广播调用）：向所有实例发请求，全部成功才返回成功。常用于需要所有节点同步更新的场景（清除所有节点本地缓存、推送配置变更）。

7. 舱壁隔离：把故障关在局部

**舱壁隔离（Bulkhead Isolation）**名称来自船舱设计：一艘多舱室的船，某舱室破损进水，隔舱壁阻止海水蔓延到其他舱室，保全整船。

船舱进水只淹一间：隔离把故障关在局部。

一句话：隔离的本质不是消灭故障，而是保证出问题的服务挂了，其它服务还能活。

隔离媒介（线程/进程/集群/读写）决定故障能扩散多远。

7.1 线程池隔离

线程是执行请求的基本单位。线程池隔离将不同依赖的请求分配到独立线程池，使资源边界互相隔离。

共享线程池的问题：服务 A、B、C 共用 300 线程，A 出问题持续阻塞，耗尽 300 线程后 B、C 也无法获得线程——雪崩就此形成。

多服务共用一个池：一处阻塞，可能抽干全部线程。

服务 A 抽干共享池后，B、C 跟着不可用——典型雪崩。

独立线程池：为三个服务各分配 100 个线程，A 的 100 线程全部耗尽，B 和 C 的线程池不受任何影响，业务处理照常进行。

各服务独立配额：A 耗尽也不拖垮 B、C。

线程池大小怎么定：根据 Little’s Law，稳定系统中线程池大小 ≈ RPS × 平均响应时间（秒）。例如 500 RPS、平均 50ms → 理论 25 线程，加 1.5 倍冗余约 40 线程。以 P99 而非平均响应时间为参考基准，并将线程池大小做成可动态修改的参数，上线后持续观察活跃线程数、队列长度、拒绝率调优，而非一次性确定永久值。

7.2 信号量隔离 vs 线程池隔离

选择建议：调用阻塞 I/O（HTTP、JDBC、RPC）→ 线程池隔离；本地缓存查询、快速降级逻辑 → 信号量隔离。

7.3 进程、集群与读写隔离

• 进程隔离：将资源边界从线程上升到 JVM 进程——微服务架构本质上就是进程隔离的工程化实践。引入网络通信开销，拆分粒度需权衡：通常先按业务域粗粒度拆分（核心域 vs 支撑域），再根据故障蔓延情况细化。
• 集群隔离：核心业务（支付、下单）与旁路业务（推荐、评论）部署在不同集群；推荐服务的大促流量洪峰不影响支付链路。SaaS 多租户场景下将大租户的批量操作路由到独立集群/队列，不影响普通租户的正常 API。
• 读写隔离：读写操作分别路由到不同节点/集群。离线报表的全表扫描不冲击在线写入性能；结合主从分离（写主读从）和热冷库分层，精细控制读取资源瓶颈。

7.4 核心与非核心资源隔离矩阵

以典型电商系统为例，说明如何在实践中决定隔离粒度：

关键是先识别故障传播路径，再选最低成本的隔离手段。不是所有服务都需要独立集群，但所有服务都至少应该有一道资源边界。

8. 五层防线如何叠加

8.1 叠加顺序：限流 → 超时 → 熔断 → 隔离 → 降级

入口限流 → 超时预算 → 熔断 → 隔离 → 降级兜底

顺序不能颠倒，每层的前提是上一层已就绪：

1. 限流（服务限流）：在入口拦截超额流量，超额请求直接拒绝，不进入业务逻辑——下游不承压。
2. 超时：每次远程调用设 connect / read 超时，慢请求快速失败，线程即时释放，防止堆积。超时统计也是熔断的”原料”——超时设置过长，熔断器无法及时感知故障；超时设置过短，海量重试反压下游。
3. 熔断：错误率持续超阈值时，后续请求直接 fallback，不再消耗网络和线程资源。熔断 Open 状态下不应再触发重试（Resilience4j 的 Retry + CircuitBreaker 组合默认支持此行为：Open 时抛 CallNotPermittedException，Retry 识别后不再重试）。
4. 隔离：独立线程池确保某一下游异常不能耗尽全局资源，限制单点故障扩散半径。没有隔离支撑，熔断 Open 后的 fallback 调用仍会占用共享线程；只有限流没有隔离，一个依赖仍可在限流通过的流量下把自己分配到的线程池打满。
5. 降级（兜底）：任意上层防线触发后，fallback 提供降级响应，保证核心能力可用。

8.2 同一依赖的配置样例

以调用”商品推荐服务”为例（Resilience4j 风格 YAML），展示五层防线在同一依赖上的具体配置：

resilience4j:
  timelimiter:
    instances:
      recommendation:
        timeoutDuration: 1500ms          # ReadTimeout：超过 1.5s 即失败

  retry:
    instances:
      recommendation:
        maxAttempts: 3                   # 最多重试 3 次（含首次）
        waitDuration: 500ms
        enableExponentialBackoff: true
        exponentialBackoffMultiplier: 2  # 梯度退避
        retryExceptions:
          - java.net.SocketTimeoutException
          - feign.RetryableException
        ignoreExceptions:
          - com.example.BusinessRejectException  # 业务拒绝不重试

  circuitbreaker:
    instances:
      recommendation:
        failureRateThreshold: 50                  # 错误率阈值 50%
        minimumNumberOfCalls: 20                  # 最小样本量
        waitDurationInOpenState: 10s              # sleep window
        permittedNumberOfCallsInHalfOpenState: 5  # 试探请求数
        slidingWindowSize: 30                     # 滑动窗口 30 次

  thread-pool-bulkhead:                # 商品推荐服务是阻塞 I/O 调用，按 §7.2 选线程池隔离而非信号量
    instances:
      recommendation:
        maxThreadPoolSize: 40      # 独立线程池上限 40，与共享池彻底隔离
        coreThreadPoolSize: 20     # 核心线程数，日常按此规模常驻
        queueCapacity: 20          # 队列容量；排满后快速拒绝，不无限堆积等待

推荐服务降级 fallback：返回空列表（默认值模式），用户看不到推荐但核心购物流程不中断。熔断 Open 时监控告警触发，运维介入排查下游根因。

9. 反模式

9.1 反模式

超时：

• 每一跳超时值相同——网关和下游都设 3s，网关先超时断连后下游仍在等，成了消耗资源的僵尸请求。
• 读超时设成”安全的大值”（如 30s）——每个慢请求占用线程 30s，高并发下等于没有设超时。
• 没有抖动的梯度退避——1000 个客户端同时超时，1 秒后同时重试，惊群效应再次打垮下游。

重试：

• 重试非幂等 POST 而不带幂等键——超时后直接重试，等于把数据正确性交给运气。
• 无限重试——下游持续不可用时重试无穷无尽，本服务和下游都被打垮。
• 把所有 4xx 都重试——400/401/403/404 是确定性错误，重试不会改变结果，只是徒增压力和延迟。

熔断：

• 阈值设置过低（如 5%）——偶发抖动频繁触发，系统在正常状态下”自断臂膀”，用户感受到的不可用反而增加。
• Fallback 仍调故障依赖——等于绕过熔断器，线程继续堆积。
• Half-Open 放行请求过多——下游恢复期间再次压垮，熔断震荡循环。
• 熔断 Open 无告警——静默降级，根因长期得不到处理。

隔离：

• 一个大共享线程池——任意依赖慢下来都能耗尽全部线程，是雪崩最常见的放大器。
• Failover 用于非幂等写——无幂等键保护时导致重复扣款。
• 信号量隔离阻塞 I/O（如 JDBC）——信号量无法中断正在阻塞中的线程，慢查询仍占用调用方线程直到超时。
• 隔离线程池上限过大（如每个依赖 500 线程，30 个依赖共 15000 线程）——线程调度开销反而拖垮 CPU，未达满负载就已退化。

小结

• 雪崩的底层是线程池耗尽的级联传播；防线的目标是把故障关在局部，而不是消灭故障。
• 超时是所有防线的基础原料——设得太高，熔断器感知不到故障；设得太低，重试风暴反压下游。调用链上的超时预算传播（Deadline Propagation）是防止链路末端拖垮全局的关键。
• 重试解决瞬态故障，必须与幂等设计绑定；对冲请求是压制尾延迟的进阶手段，代价是更严格的幂等要求。
• 熔断的核心价值是在下游持续异常时主动插断，并通过 Half-Open 机制自动恢复——fallback 质量决定降级体验，熔断告警决定根因能否被及时处理。
• 降级是比熔断更广义的策略，需提前规划：哪些服务可降级、降级后的 fallback 是什么、用户看到什么。
• 集群容错（Failover/Failfast/Failsafe/Failback）和舱壁隔离（线程池/进程/集群/读写）是同一目标的两条实现路径：前者决定”失败后去哪”，后者决定”故障能扩散多远”。
• 五层防线的叠加顺序：限流 → 超时 → 熔断 → 隔离 → 降级，顺序不能颠倒，每层前提是上一层已就绪。

系列其他篇：

• 高可用系统设计 — 高可用的定义、度量与设计原则
• 冗余与容灾 — 冗余模式、故障切换与 RPO/RTO
• 服务限流 — 令牌桶、漏桶、固定/滑动窗口
• 幂等与一致性 — 重试安全、分布式事务与最终一致
• 发布与变更安全 — 灰度发布、功能开关与变更回滚
• 混沌工程 — 故障注入、爆炸半径与稳态验证

参考

• 超时、重试和抖动退避（AWS Builder’s Library）
• 微服务之间调用超时的设置治理
• Sentinel 官方文档
• Resilience4j 官方文档
• The Tail at Scale（Dean & Barroso，对冲请求与尾延迟）
• 美团 Java 线程池参数动态配置