系统韧性工程：从被动救火到主动防御的架构演进
概述 凌晨两点，你的手机响了。支付服务超时，线程池被占满，上游订单服务开始排队，10 分钟后整个交易链路雪崩。你打开日志一看：下游一个缓存集群抖动了 3 秒，这 3 秒里上游疯狂重试，把连接数打到了上限，然后所有依赖这个连接池的服务一起挂了。 这故事不新鲜。几乎每个干过几年运维的人都经历过类似的连锁故障。问题不在于某个组件会不会挂——分布式系统里，什么都可能挂，网络会抖、磁盘会满、DNS 会抽风、机房会断电。真正的问题是：一个局部故障为什么会演变成全局灾难？ 韧性工程（Resilience Engineering）回答的就是这个问题。它不是某个具体工具或某个框架，而是一套从架构设计到运维实践的系统性方法论，核心目标只有一个：让系统在部分组件失效时仍能提供可接受的服务，而不是一路雪崩到全站不可用。 这篇文章把韧性工程拆成三块来讲：一是韧性模式——你的系统到底需要哪些容错机制，每种解决什么问题；二是实践框架——这些模式怎么组合落地，不是东拼西凑几个注解就完事；三是度量与验证——你怎么知道系统真的"韧"，而不是你以为它韧。 韧性工程到底在解决什么问题 先说清楚一件事：可靠性（Reliability）和韧性（Resilience）不是一回事。 可靠性回答的是"系统在规定条件下、规定时间内，能不能正常工作"——它关注的是正常状态。你定了 99.9% 的可用性 SLO，这衡量的是可靠性。 韧性回答的是"当条件不满足、甚至出现预期外故障时，系统能不能优雅降级而不是直接崩溃"——它关注的是异常状态。你的服务在数据库挂了 30 秒后还能返回缓存数据，延迟从 50ms 升到 200ms 但没有雪崩，这体现的是韧性。 用一个不太精确但好理解的类比：可靠性是百米短跑你能跑多快，韧性是你摔了一跤后多快能爬起来继续跑。 分布式系统天然比单机系统脆弱，因为引入了网络这个最大的不确定性来源。CAP 定理告诉我们，分区容忍（P）在网络不可靠时是无法回避的。你不可能消灭故障，只能控制故障的影响范围和传播速度。韧性工程本质上就是在做两件事：缩小爆炸半径（一个故障不要扩散到其他组件）和缩短恢复时间（出问题后尽快回到正常状态）。 五大韧性模式 熔断器（Circuit Breaker） 熔断器解决的问题是：当一个下游服务持续故障时，不要继续向它发请求。 道理很直白。如果支付网关已经挂了，你的订单服务每笔请求还在傻等 30 秒超时，100 个并发请求瞬间就把线程池占满了。这时候不光支付不行，连查订单、查库存一起死掉。熔断器的作用就是当失败率达到阈值时，直接切断这条调用链路——后续请求不再访问故障服务，而是立即返回降级响应或报错。 熔断器有三个状态，跟家庭配电箱的空气开关一样： 状态 行为 类比 Closed（闭合） 正常放行请求，记录失败率 开关正常通电 Open（断开） 拒绝所有请求，直接走降级 开关跳闸断电 Half-Open（半开） 放行少量探测请求，试探恢复 试探性恢复供电 状态转换的核心逻辑： Closed → Open: 滑动窗口内失败率超过阈值（如 50%） Open → Half-Open: 经过冷却时间（如 30s）后自动转换 Half-Open → Closed: 探测请求成功率达标 → 恢复正常 Half-Open → Open: 探测请求仍然失败 → 重新断开 实测中有个坑要避：阈值别定太敏感。我见过有人设 10% 失败率就熔断，结果正常的一次 GC 停顿（偶尔 1-2 秒延迟升高）就触发熔断，服务在 Open 和 Closed 之间来回弹跳。建议初始配置失败率阈值 50%、最小调用次数 20、滑动窗口 10 秒，然后根据实际数据调。...