降级

概述 凌晨三点，手机狂震。打开一看，告警群已经炸了——支付服务 P99 延迟从 50ms 飙到 12 秒，错误率突破 80%。更要命的是，故障像多米诺骨牌一样连锁反应：用户服务超时 → 鉴权失败 → 库存服务重试风暴 → 消息队列阻塞 → 支付回调全部超时。监控大屏上三十秒内全部变红。 这不是某家公司独有的惨案。微服务拆得越细，服务间调用链越长，一个局部故障就越容易演变成全局雪崩。我曾在某新能源物流平台治理 50+ 微服务时，亲历过三次类似事故，最后一次最严重——一个下游搜索服务的数据库连接池打满，导致上游所有依赖搜索结果的服务线程池连锁耗尽，整条交易链路瘫痪 17 分钟。 那次事故后我们花了两周时间重做限流熔断降级体系。最终把 P99 从 200ms 压到 170ms，更重要的是，之后再没出现过级联故障。这篇文章把我踩过的坑、做过的架构选型、以及生产环境真正有效的配置经验一次讲透。 先说清楚三者的关系——很多人混着用，但它们解决的问题不同： 防护手段 解决什么问题 类比 作用位置 限流（Rate Limiting） 流量超过系统承载能力 超市收银台只开 3 个窗口，排满了就不让进了 入口处 熔断（Circuit Breaking） 下游服务故障，防止故障蔓延 保险丝，电流过大自动断电 调用链中间 降级（Degradation） 核心功能不可用时提供替代方案 停电了用应急灯，虽然不亮但能看见 业务逻辑层 三者配合使用：限流挡在前面控制输入，熔断在中间切断故障传播，降级在尾部保证用户体验不至于完全崩溃。 雪崩效应：为什么微服务比单体更容易崩 单体应用里，方法调用是进程内函数调用，微秒级完成。微服务拆开后，每次调用都变成了网络请求——网络可能抖动、DNS 可能解析慢、TCP 三次握手有开销、序列化反序列化要时间。一个用户请求从网关进来，经过 5-7 层服务调用是常态。 故障传播路径 看一个真实的调用链： 用户请求 → API Gateway → 订单服务 → 用户服务（鉴权） → 库存服务（扣减） → 优惠券服务 → 支付服务 → 第三方支付网关 假设第三方支付网关变慢了（比如响应从 100ms 变成 5 秒），会发生什么？...