微服务系统最怕的不是一个服务失败，而是一个服务失败后，调用方一直等待、重试、堆积线程，最后把整条链路拖垮。这就是服务雪崩。
一句话概括：服务雪崩是故障沿调用链扩散；服务降级是给用户一个兜底结果；服务熔断是当失败达到阈值后，暂时不再调用故障服务，直接快速失败或走降级。
正常
超时或异常
否
是
服务 A 调用服务 B
服务 B 是否正常
返回真实业务结果
调用失败累积
失败率是否超过阈值
继续尝试调用
打开熔断器
快速失败或执行降级逻辑
保护调用方线程资源
什么是服务雪崩
服务雪崩是指一个服务失败，导致整条链路上的服务都失败。
典型场景：
- 服务 D 响应变慢或不可用。
- 服务 C 调用 D 时大量等待。
- 服务 C 的线程池被占满。
- 服务 B 调用 C 也开始超时。
- 服务 A 调用 B 继续堆积。
- 整条链路不可用。
所以雪崩的本质不是"某个服务挂了"，而是故障没有被隔离，资源被持续拖住。
服务降级是什么
服务降级是兜底策略。
比如用户访问文章保存接口，下游服务异常时，不一定要让请求一直卡住，可以返回一个可接受的提示：
您的网络有问题，请稍后再试。
或者在一些非核心场景中，返回默认值、空结果、缓存结果。
降级的目标不是修复下游，而是保护当前服务和用户体验。
常见降级场景：
- 下游服务超时。
- 下游服务异常。
- 当前服务压力过大。
- 非核心功能临时关闭。
服务熔断是什么
熔断器可以理解成电路里的保险丝。下游持续失败时，熔断器打开，后续请求不再真正调用下游，而是直接快速失败或走降级。
是
否
是
成功
失败
Closed
正常调用
失败率超过阈值
Open
打开熔断器
请求快速失败
走降级
熔断时间结束
Half-Open
放行少量请求
试探请求成功
课程中提到的 Hystrix 规则是：
- 默认需要手动开启熔断。
- 10 秒内请求失败率超过 50%，触发熔断。
- 熔断后快速失败。
- 每隔 5 秒尝试放行一次请求。
- 如果下游恢复，就关闭熔断器。
- 如果下游仍不可用，继续熔断。
降级和熔断有什么区别
| 对比点 | 服务降级 | 服务熔断 |
|---|---|---|
| 关注点 | 返回兜底结果 | 暂停调用故障服务 |
| 触发原因 | 异常、超时、限流、压力过大 | 失败率达到阈值 |
| 目标 | 保护用户体验和当前服务 | 隔离下游故障 |
| 结果 | fallback 逻辑 | 快速失败或 fallback |
降级是结果策略，熔断是保护机制。实际项目里二者常常配合使用。
限流、降级、熔断的边界
限流、降级、熔断经常一起出现，但它们不是一回事。
| 手段 | 发生位置 | 解决什么问题 | 典型例子 |
|---|---|---|---|
| 限流 | 请求入口 | 请求太多，系统扛不住 | 每秒只允许 1000 个请求进入 |
| 降级 | 调用失败或压力过大时 | 给用户一个兜底结果 | 返回默认数据、缓存数据、友好提示 |
| 熔断 | 远程调用链路中 | 下游持续失败，避免拖垮上游 | 失败率超过阈值后不再调用下游 |
是
否
是
否
请求进入系统
流量是否超过阈值
限流
拒绝部分请求
调用下游服务
下游是否持续失败
熔断
暂停真实调用
降级
返回兜底结果
正常返回
可以这样记：限流挡在入口，熔断挡在调用链，降级负责兜底返回。
面试回答模板
可以这样答：
服务雪崩是一个服务失败后，导致整条调用链上的服务都失败。比如下游服务超时，调用方线程一直阻塞，线程池被占满后，上游服务也会被拖垮。解决方式主要有降级、熔断和限流。服务降级是下游不可用时返回兜底结果，保护用户体验；服务熔断是监控调用失败率，当失败率达到阈值后打开熔断器，后续请求不再真正调用下游，而是快速失败或走降级，过一段时间再进入半开状态试探恢复。
小结
服务保护这块可以按这条线记：
雪崩是故障扩散，降级是兜底返回，熔断是暂停调用，限流是入口预防。
这几个词看起来像一锅粥，按"故障发生前、发生中、发生后"拆开，就清楚多了。