一、什么是服务雪崩，怎么产生的
1. 定义
多个微服务存在依赖调用链，下游服务出现故障（宕机、超时、高延迟），大量请求堆积、线程耗尽，故障逐级向上扩散，最终所有关联服务线程池打满，整个微服务集群全部不可用，这就是服务雪崩。
2. 完整雪崩产生流程
- 下游服务 B 数据库慢、机器宕机，接口大量超时；
- 上游服务 A 调用 B 的请求全部阻塞，Tomcat 线程持续占用无法释放；
- A 线程池快速耗尽，新请求排队等待，A 自身接口全部卡死；
- 依赖 A 的网关、前端服务也跟着阻塞，连锁故障扩散；
- 所有关联服务线程打满，整个业务集群瘫痪。
3. 放大雪崩的关键因素
- 无超时控制：调用下游无限等待，线程长期占用；
- 无线程隔离：所有接口共用一个线程池，一个接口故障拖垮全部；
- 失败无兜底：调用失败不停重试，成倍放大请求量；
- 无流量控制：高并发下故障请求持续涌入。
二、核心防护手段：熔断 CircuitBreaker
1. 熔断核心思想
类似家里保险丝，下游服务失败率达到阈值，直接切断调用链路，不再发起远程请求，快速返回兜底数据，避免持续占用线程。
2. 熔断三状态（循环流转）
- 关闭 Closed 正常状态，正常发起远程调用；框架统计成功、失败、超时请求比例。
- 打开 Open 短时间内失败率超过设定阈值，熔断器打开；此时所有调用直接走降级兜底，不请求下游，给故障服务留出恢复时间（休眠窗口期）。
- 半开 Half-Open 休眠时间结束，熔断器进入半开状态；放行少量探测请求试探下游是否恢复。
- 探测请求成功 → 熔断器切回关闭，恢复正常调用；
- 探测请求依旧失败 → 重新切回打开，继续休眠。
3. 熔断解决的问题
避免故障服务持续占用上游线程，阻断雪崩扩散，给下游故障服务自愈窗口。
三、核心防护手段：降级 Fallback
1. 降级定义
当远程调用失败、超时、熔断打开时，不抛出异常，执行预设兜底逻辑，返回友好默认数据。
2. 两种降级场景
- 调用降级（远程服务故障） 依赖的下游挂了，直接返回缓存、默认空数据、提示文案，不阻塞等待。 例：商品详情推荐服务故障，兜底返回热门固定商品列表。
- 业务主动降级（流量高峰） 大促、秒杀流量突增，主动关闭非核心业务接口，释放服务器资源保障核心流程。 例：大促暂时关闭商品评价、历史订单查询，只保留下单、支付核心链路。
3. 熔断和降级的核心区分
- 熔断是机制开关：判断要不要调用下游服务；
- 降级是兜底方案：调用失败后返回什么数据； 二者配合：熔断打开 → 直接执行降级逻辑。
四、配套补充：线程隔离 & 请求重试（配套防雪崩能力）
- 线程池隔离 不同下游服务分配独立线程池，某一个下游故障只会耗尽自己的线程池，不会占用其他服务线程，实现故障隔离。Hystrix 默认线程池隔离；Sentinel 支持信号量隔离、线程池隔离。
- 请求重试 少量瞬时失败自动重试，但必须限制重试次数、间隔；无限制重试会成倍放大流量，加重雪崩。
五、两大主流框架：Hystrix vs Sentinel
1. Hystrix（Netflix，旧版 SpringCloud）
- 实现：线程池隔离、熔断三状态、注解 @HystrixCommand 配置降级；
- 缺点：官方停止维护，功能单一，无流量控制、无控制台，运维麻烦。
2. Sentinel（阿里，现在主流推荐）
- 轻量级，支持信号量 / 线程池两种隔离；
- 熔断降级规则可视化控制台，动态实时修改规则无需重启服务；
- 额外集成限流、热点限流、授权规则、系统自适应保护；
- 支持流控效果：快速失败、排队等待、预热冷启动，企业新项目首选。
六、完整防雪崩落地方案（实战加分）
- 远程调用统一设置超时时间，避免无限阻塞；
- 使用 Sentinel/Hystrix 做线程隔离，故障互不影响；
- 配置熔断规则，失败比例触发熔断切断调用；
- 所有远程接口编写降级兜底逻辑，保证接口不报错；
- 流量高峰配置限流、主动降级非核心业务；
- 限制重试次数，禁止无限重试下游接口。
简短总结
服务雪崩是下游故障连锁扩散拖垮整个微服务集群；熔断通过熔断器三状态切断故障调用，阻断故障蔓延；降级是调用失败后的兜底返回逻辑；熔断是开关，降级是兜底；线上使用 Sentinel 实现线程隔离、熔断、降级、限流，全方位预防雪崩。