熔断降级概述
什么是熔断降级
熔断降级，说白了就是给分布式系统装一个“保险丝”。
你想想看，微服务之间互相调用，一个服务挂了，调用方还在傻等，结果线程池占满，整个链路拖垮。这就是我常说的“雪崩效应”。熔断降级要解决的就是这个——当下游服务不行了，上游主动切断调用，快速失败，而不是死撑。
我个人习惯把熔断降级拆成两层看：
- 熔断：开关。达到阈值就断开，阻止流量继续流入故障节点。
- 降级：兜底。熔断后执行备选逻辑（比如返回缓存、默认值、错误提示），保证系统整体可用。
我记得有一次在生产环境里，一个第三方支付接口突然超时，没有熔断降级，结果调用方线程池撑爆，连带订单服务、用户服务全挂了。嗯，那次之后我强制团队每个依赖都配了熔断器。
应用场景
什么时候该上熔断降级？我总结了三类典型场景：
- 跨服务调用：微服务间RPC、HTTP调用，尤其是依赖外部不可控服务时。
- 资源密集型操作：数据库连接池、消息队列、慢查询，容易把线程或连接耗尽。
- 突发流量毛刺：瞬时高并发，比如秒杀、热点数据刷新，熔断能保护后端不被冲垮。
用表格对比一下更清楚：
| 场景 | 典型问题 | 熔断降级怎么做 |
|---|---|---|
| 外部API依赖 | 接口超时、返回异常 | 设置超时阈值+错误比例，快速降级返回兜底数据 |
| 数据库慢查询 | 连接池占满，其他请求也拿不到连接 | 监控查询耗时，熔断后走缓存或限流 |
| 突发流量尖刺 | 单节点被打爆，影响其他节点 | 根据QPS或错误数动态熔断，半开试探恢复 |
避坑指南：我曾经见过一个团队把熔断阈值设得太保守，几秒就断一次，业务频繁降级导致体验崩溃。熔断不是越灵敏越好，一定要结合业务容忍度调优。
核心原理
熔断降级的核心是一个**三态状态机**：关闭 → 打开 → 半开。我用一段代码先粗略展示一下配置思路：
// 伪代码：Resilience4j 熔断器配置
CircuitBreakerConfig config = CircuitBreakerConfig.custom()
.failureRateThreshold(50) // 错误率50%触发打开
.waitDurationInOpenState(Duration.ofSeconds(10)) // 打开后等10秒
.slidingWindowSize(100) // 统计最近100次请求
.build();实际运行时的流转逻辑我画了一张图，你一看就懂：
三个状态和工作机制我拆开来细说：
- CLOSED（关闭）：正常状态。每次请求都通过，同时统计最近窗口内的错误数/错误率。当错误率超过阈值，就切换到 OPEN。
- OPEN（打开）：拒绝所有请求，直接返回降级响应（我习惯抛一个自定义异常或返回缓存数据）。同时启动一个计时器，等时间到了自动进入 HALF_OPEN。
- HALF_OPEN（半开）：允许少量试探请求通过。如果试探请求成功，认为下游已恢复，切回 CLOSED；如果依然失败，回到 OPEN，重新计时。
我踩过的一个坑：半开状态下试探次数设置太多，导致一次恢复试探直接把本来苟延残喘的下游打挂了。你想想看，半开本意是“轻量探测”，如果允许10个并发试探，就等于把压力又引入，可能再次触发熔断。我的建议是试探次数设为1，最多2。
还有一个容易忽略的点：超时和异常要分开统计。我见过不少配置只统计异常，忽略了超时。其实超时比异常更致命，它占着线程不放。我个人习惯把超时也映射成异常，统一算进失败率。
熔断降级的决策数据
要把熔断做准，数据源很关键。我列一个常用的采集维度：
| 指标 | 典型来源 | 阈值参考 |
|---|---|---|
| 请求错误率 | HTTP 5xx、RPC异常码 | 50% |
| 平均响应时间 | 客户端埋点 | 超过300ms可考虑 |
| 慢调用比例 | 自定义耗时分桶 | 比如P95 > 1s 触发 |
| 并发活跃线程数 | 连接池/线程池指标 | 接近池上限时报警 |
注意：不要直接在生产环境调参数。我建议先在预发环境用流量回放测试熔断效果。有一次我在预发测出一个半开恢复逻辑 bug，避免了线上故障。嗯，这件事让我养成了“熔断参数灰度上线”的习惯。
其实熔断降级没那么神秘。你只要把握住 统计窗口 → 状态切换 → 快速失败 这条线，配合业务兜底逻辑就能撑住大部分场景。后面几章会深入代码细节，但概念上这块一定要吃透。