服务雪崩的防治：从线程池隔离到舱壁模式

服务端系列新篇，聊故障传播的经典话题：雪崩。一个下游服务变慢，拖垮调用方线程池，调用方再拖垮它的上游——级联故障像多米诺。这篇把防雪崩的手段按层次讲清楚，重点讲经常被低估的舱壁隔离。

雪崩的力学

标准剧本：下游 DB 慢查询 → 连接池占满 → 上游服务线程全部挂在等连接 → 上游对外无响应 → 更上层熔断失效（因为超时配置不合理）→ 全链路倒下。注意关键放大器：同步调用的线程模型——等待是占用资源的，请求数没涨，资源先耗尽。

防治的三个层次

层次一：快速失败（止损）

超时（连接/读/总）+ 重试上限 + 熔断器——这三个前几篇都展开过，它们解决「不要等死」。这是基础防线，但有个盲区：快速失败防的是「慢」，防不了「快而耗资源」的故障模式（比如下游秒回错误但你的每次处理都要分配大对象）。

层次二：资源隔离（舱壁模式 Bulkhead）

船舱的水密隔板：撞破一舱，其他舱不进水。服务间调用也一样——给每个下游依赖分配独立的资源池（线程池/连接池/信号量），某个依赖出问题时只有它的池子耗尽，不传染。

• 独立线程池：调用依赖 A 用池 1、依赖 B 用池 2——A 挂了池 1 满，B 照常服务
• 信号量隔离（轻量版）：不换线程，只用计数器限制对单个依赖的并发数——开销更小，但不能异步超时（适合本地调用和快接口）
• 池子大小：按「该依赖的正常 P99 耗时 × 可容忍并发」算，不是拍脑袋——一个 P99 为 200ms 的依赖，10 个线程就够支撑 50 QPS

层次三：负载卸载（降压）

限流（入口端）+ 降级（依赖端）+ 优先级队列——保核心弃边缘，前面聊过。舱壁和降级的分工：舱壁保住「受害面不扩大」，降级决定「损失什么保什么」。

一个真实案例的账

电商大促前压测：推荐服务依赖用户画像服务，压测到 3000 QPS 时画像服务抖动（P99 从 50ms 涨到 2s），推荐服务线程池 5 秒耗尽，连带商品详情页全挂——典型的雪崩链。

改造：对画像调用单独建 20 线程的隔离池 + 熔断阈值。再压同样的场景：画像抖动时推荐服务错误率升到 8%（依赖降级返回默认画像），但主链路商品浏览和下单全程无感。舱壁模式没有修复画像服务——它只是把事故半径从「全站」切到「8% 的推荐内容」。

实施清单（按优先级）

1. 盘点同步依赖：每个外部调用画出来，标注「挂了会拖垮谁」——依赖图是隔离设计的前提
2. 核心链路先行：给「挂了就出大事」的依赖先建池，长尾依赖共用一个兜底池即可（池子太多管理成本也高）
3. 池参数进配置中心：故障演练时能快速调整——舱壁参数没有一次到位的，要靠演练校准
4. 观测：每个池的活跃度/队列深度独立打点——隔离层的健康度要可见

常见的三个误区

• 「我们 QPS 低不需要」：雪崩和流量无关，和故障模式有关——内部工具系统一样会被一个慢 SQL 拖垮
• 「熔断了就不需要隔离」：熔断器从异常到打开有时间窗，窗口内的资源消耗就是雪崩的燃料——隔离是熔断的前置防线
• 「池越多越安全」：池的粒度过细会碎片化线程资源，20 个池各 5 线程不如 4 个池各 25 线程

（服务端系列：网关限流 → 熔断降级 → 灰度闭环 → 缓存一致性 → API 版本治理 → 本文：舱壁隔离 → 计划中：依赖治理的度量）