什么是服务雪崩？熔断和降级怎么做？

服务雪崩是强依赖链上一个服务变慢，拖垮调用方线程池，进而扩散到整条链路。防御三件套：舱壁隔离——每个依赖独立线程池或信号量，故障不传染；熔断——错误率超阈值打开断路器，快速失败一段时间后半开试探恢复；降级——熔断期间返回兜底数据或友好提示，有损但可用。

我讲一次实战：推荐服务抖动导致商品页大量超时。当时线程池被推荐调用占满，连核心的库存查询都被拖死——这就是没有舱壁隔离的代价。整改：按依赖拆线程池配独立队列与超时；推荐调用加熔断，异常比例超 50% 三秒内打开，走静态推荐兜底；再加接口级限流保护。之后同类故障影响面从整站缩小到单个模块。

我按三态模型讲原理：closed 正常统计请求；错误率或慢调用比例越阈、或达到最低请求数后 open，直接拒绝不再发请求；休眠期后 half-open 放少量试探请求，成功恢复、失败回到 open。工程上强调参数联动：熔断阈值、统计窗口、半开请求数、恢复策略要一起调；以及手动熔断开关作为运维预案。治理层面要把熔断配置纳入服务治理平台统一管理。

追问『熔断和限流的区别』：限流是防过载控制入口量，熔断是故障时切断出口调用，常配合使用；『降级数据怎么来』：缓存快照、默认值、静态配置、异步刷新的简化结果，要向用户明示『部分数据』；『重试和熔断冲突吗』：重试放大流量，必须有重试预算，熔断优先级高于重试。