9.服务容错：构建高可用微服务的核心防御
微服务架构通过拆分和解耦带来了灵活与可扩展性，但它也引入了天然的“脆弱性”——当某个服务不可用、网络延迟突增或流量突然飙升时，系统就可能陷入连锁失败，引发雪崩效应，最终导致整体服务瘫痪。
在这样的架构背景下，熔断（Circuit Breaker）、服务降级（Fallback）和流量控制（Rate Limiting） 成为构建高可用系统的三大核心防御机制。而随着 Hystrix 的落幕，现代微服务开发者需要掌握并善用更先进的替代方案——Sentinel 和 Resilience4j。
本文将从原理剖析出发，结合实战案例，帮助你全面掌握这些容错机制，并在 Spring Cloud 微服务中高效落地。
1. 为何容错是微服务生存的刚需？
1.1 雪崩效应：脆弱链式反应的代价
想象一个场景：电商核心下单服务依赖库存服务。某日库存服务因数据库故障响应变慢：
- 下单服务线程因等待库存响应而被大量阻塞；
- 线程池耗尽，新下单请求被拒绝；
- 用户无法下单，前端显示错误；
- 依赖下单服务的其他服务（如订单查询、支付）也开始受到影响；
- 雪崩效应形成，整个系统陷入瘫痪。
在微服务架构中，服务之间高度依赖。如果一个下游服务响应变慢或失败，调用它的上游服务可能被阻塞。此阻塞会传导给上游的上游……最终整个系统因资源耗尽或线程堆积而崩溃。
示意图：
用户请求↓
服务A → 服务B → 服务C （服务C响应变慢）↑
阻塞 ↑ 堆积 ↑ 崩溃 ↑
1.2 流量洪峰：瞬时流量如何击垮服务
促销秒杀等突发场景下，请求量暴增，服务来不及处理，线程/连接池迅速耗尽，导致大量请求超时或失败。
1.3 三大机制是核心诉求的回应
| 核心挑战 | 防御机制 |
|---|---|
| 服务调用失败 | 熔断 |
| 服务响应变慢 | 降级 |
| 流量过载 | 限流 |
2. 熔断器：服务的“自动保险丝”
2.1 熔断模式原理剖析
熔断器的设计灵感来自电路保险丝。当故障请求频率过高时，熔断器“跳闸”，短期阻止请求，避免资源浪费。
状态转换图：
Closed → Open → Half-Open → Closed
- Closed：正常通过，统计错误率；
- Open：达到阈值后直接拒绝请求；
- Half-Open：试探性放通少量请求，若恢复则闭合熔断器。
关键参数：
- 请求阈值：如 10 秒内 50 次请求；
- 错误率阈值：如 50%；
- 熔断时间窗口：如 10 秒；
- 恢复探测阈值。
2.2 服务降级：熔断后的“Plan B”
降级的目标是优雅失败：即便后端异常，也尽可能保证核心功能可用，提升系统韧性。
常见策略：
- 快速失败：直接返回异常或友好提示；
- 默认值：返回静态数据或缓存值；
- 备用服务：调用降级链的其他服务；
设计原则：
- 可用性优先，牺牲一致性；
- 保留“关键路径”功能；
- 降级逻辑应可监控、可恢复。