服务雪崩与防护#

防护措施：

1. 超时控制：避免无限等待
2. 熔断器：快速失败，停止调用故障服务
3. 限流：控制进入流量
4. 降级：核心路径保障，非核心返回默认值
5. 舱壁隔离：不同服务用不同线程池

Sentinel 三板斧： 流控 + 熔断 + 系统保护

服务雪崩是微服务架构中最严重的故障模式，根本原因是一个下游服务故障导致调用方线程阻塞等待，线程池耗尽后调用方自己也无法处理请求，故障像多米诺骨牌一样沿调用链向上传播，最终整条链路崩溃。比如服务 A 调 B 调 C，C 响应变慢，B 的线程池被 C 的慢请求占满，B 无法处理 A 的请求，A 也开始超时，最终全链路雪崩。防护需要五道防线协同工作：超时控制是最基础的，给每次调用设置合理超时避免无限等待，且超时必须逐层递减；熔断器在下游持续故障时快速失败不再尝试调用，三态循环 Closed、Open、Half-Open；限流在入口控制进入的请求量，防止流量超过系统处理能力；降级在触发熔断或限流后返回兜底值而不是错误，比如关闭非核心功能只保核心链路；舱壁隔离让不同下游调用使用不同线程池，一个下游慢不会拖垮调其他下游的线程。生产中用 Sentinel 的流控、熔断和系统保护三板斧来实现。

追问方向：

• “服务雪崩和缓存雪崩区别？”→ 服务雪崩是下游服务不可用导致上游级联故障（调用链传导）；缓存雪崩是大量缓存同时过期导致请求打到数据库，两者都需要熔断/限流但根因不同
• “舱壁隔离怎么实现？”→ 线程池隔离：每个下游服务分配独立线程池，某服务慢只耗尽自己的线程池不影响其他调用；信号量隔离更轻量但无法控制超时，Hystrix/Sentinel 都支持
• “你们怎么做降级？”→ 核心链路保留、非核心功能降级返回兜底数据（如推荐服务降级返回热门榜单）；Sentinel 配置降级规则，触发后执行 fallback 方法返回缓存数据或默认值

易错点：

• ❌ 加超时就够了——还需熔断限流降级
• ❌ 降级就是返回错误——应返回兜底值