什么是服务雪崩？
- 标签：服务容灾、Spring Cloud、微服务、后端
🏛 业务架构师
服务雪崩是故障的级联放大：一个下游服务变慢 → 调用方线程池被慢请求占满 → 调用方自身不可用 → 更上游接连倒下，像雪崩一样一层层把整个链路埋掉。
放大机制两个：线程池耗尽（同步调用阻塞等待，资源被慢请求占死）和重试风暴（超时触发重试，流量翻倍砸向已经病危的下游）。
防护体系按层布防：
- 超时：每个调用设明确超时（预算逐层递减：网关 1s → 服务 800ms → DB 100ms）——没有超时的依赖等于把全站稳定性押给别人；
- 熔断：失败率/慢调用超阈值自动跳闸，快速失败止损（Sentinel/Resilience4j）；
- 舱壁隔离（线程池/信号量隔离）：不同下游用独立线程池——推荐服务挂了不能拖垮订单服务，故障被隔离在舱室内；
- 限流：入口限流保证系统只接收扛得住的量——过载时拒绝一部分，好过全部死掉；
- 降级：熔断后的业务兜底（缓存快照、默认值、异步补偿）；
- 异步化：非核心链路同步改异步（MQ 削峰），把"必须同时活着"的依赖关系拆掉；
- 重试纪律：仅幂等接口可重试、指数退避 + 抖动、预算上限——防重试风暴是设计出来的。
业务视角的本质：雪崩防护是业务连续性的保险投资——平时每层多写的超时、熔断代码看似冗余，故障时它是"局部失血"与"全身瘫痪"的区别。没有演练的防护体系不算存在：定期故障注入（kill 掉下游、注入延迟），验证每道闸门真的会关。
一句话：雪崩不是单一故障，是故障在同步依赖链上的传染——架构的任务是把传染病隔离在第一排。
🏗 系统架构师
服务雪崩是故障沿调用链向上传导放大，最终拖垮整个系统的过程，因果链很清晰：
演化路径：下游服务 D 变慢（DB 慢查询/FullGC/网络抖动）→ 上游 C 调用 D 的线程阻塞堆积 → C 的线程池耗尽，自身接口不可用 → B 调 C 也开始超时阻塞 → 逐层向上，所有服务线程池被拖死 → 全站不可用。放大的机制是资源占用传播：一个下游的 1 秒慢，会占住上游 N 倍的并发线程。
我的四层防御体系：
- 超时：每个 RPC/HTTP/DB 调用必须有超时（且上游超时 < 下游超时总和，避免无效等待），没有超时的依赖就是雪崩引信；
- 线程池/信号量隔离：按依赖划分独立线程池（舱壁模式），下游 D 故障只烧掉它自己的池子，核心链路存活；
- 熔断：错误率/慢调用超阈值直接拒绝（Sentinel/Resilience4j），把不可控等待变可控失败，快速失败保护上游；
- 限流 + 降级：入口限流挡住超额流量；降级给兜底数据，让核心业务在残局中可用。
配套机制：异步化（MQ 解耦同步依赖）、重试要有上限与退避（盲目重试在故障时是 DDoS）、容量规划与全链路压测、混沌演练验证。
一句话：雪崩的本质是资源被慢依赖占满，防御的本质是让故障"局部化、快速化"。
💻 全栈开发专家
服务雪崩 = 一个下游服务的故障，沿着调用链逐级向上拖垮整个系统的过程：
text
积分服务慢（GC/DB 慢）
→ 订单服务调它的线程全部阻塞等待（默认无超时或超时太长）
→ 订单服务线程池/连接池耗尽
→ 订单服务自身无响应
→ 上游商品、购物车服务同样被拖住
→ 全站不可用放大器通常有三个：无超时的同步调用、失控的重试（超时 × 重试次数叠加）、线程池/连接池不隔离（一个慢依赖吃光全部资源）。
四层防线（我按处理顺序答）：
- 超时：每个 RPC/HTTP 调用必设超时，且上游超时 < 下游超时（否则上游已放弃、下游还在跑，白白浪费）；重试要克制（只重试幂等接口，次数 1~2 次）。
- 线程池/信号量隔离：不同依赖用独立线程池（舱壁模式），积分挂了只烧光积分池，不碰主链路。
- 熔断：失败率超阈值自动跳闸，快速失败保住资源（Sentinel/Hystrix）。
- 降级 + 限流：熔断后走兜底数据；入口限流保证过载时"部分可用优于全部不可用"。
复盘经验：我处理过的雪崩，根因 80% 是"新接的依赖没配超时"。所以规约第一条：任何远程调用上线前，超时和降级预案是硬性检查项。