在分布式系统设计中，熔断（Circuit Breaking） 和 降级（Degradation） 是两种关键的服务保护机制，它们的核心区别体现在 触发场景 、保护目标 和 实现方式 上。以下通过多维度对比揭示二者的本质差异：
一、核心概念对比
| 维度 | 熔断（Circuit Breaking） | 降级（Degradation） |
|---|---|---|
| 本质 | 故障隔离机制 | 资源分配策略 |
| 触发条件 | 依赖服务连续失败率/超时率超过阈值 | 系统负载过高（CPU、线程池、响应时间等） |
| 保护目标 | 防止故障扩散导致雪崩效应 | 优先保障核心业务可用性 |
| 恢复机制 | 半开状态试探恢复 | 负载降低后自动恢复 |
| 实现层级 | 通常作用于服务调用链路（如RPC框架集成） | 可作用于业务逻辑层或全局系统 |
二、典型场景示例
1. 熔断场景
当支付服务在5分钟内错误率超过60%时，触发熔断：
- 立即行为：后续请求直接返回"服务暂不可用"错误，不再调用真实服务
- 后续处理：10秒后进入半开状态，尝试放行部分请求探测恢复情况
2. 降级场景
电商大促期间，系统检测到CPU使用率超过90%：
- 立即行为：关闭商品详情页的推荐模块、简化用户评论展示
- 后续处理：当CPU回落至70%以下，逐步恢复非核心功能
三、技术实现差异
1. 熔断器实现原理（以Hystrix为例）
kotlin
// 熔断器状态机
enum CircuitBreakerState {
CLOSED, // 正常状态
OPEN, // 熔断状态
HALF_OPEN // 半开试探状态
}
// 触发条件判断
if (failureRate > threshold) {
circuitBreaker.open();
// 开启熔断，后续请求快速失败
}2. 降级策略类型
| 降级类型 | 实现方式 | 适用场景 |
|---|---|---|
| 静态降级 | 提前配置兜底数据（如默认推荐列表） | 已知高风险功能 |
| 动态降级 | 实时计算降级开关（基于指标阈值） | 突发流量冲击 |
| 柔性事务降级 | 将同步调用改为异步队列处理 | 高并发写操作 |
四、协同工作模式
在实际系统中，熔断和降级常形成 立体防护网：
- 第一层熔断：当依赖服务不可用时，快速切断调用链
- 第二层降级：在自身服务过载时，主动缩减功能范围
- 第三层限流：配合限流（Rate Limiting）控制入口流量
五、配置参数对比
| 参数 | 熔断典型值 | 降级典型值 |
|---|---|---|
| 触发阈值 | 错误率 > 50%（持续10秒） | CPU > 80% 或 RT > 2000ms |
| 恢复检测间隔 | 5-30秒（半开状态探测） | 实时监控（秒级） |
| 影响范围 | 单个依赖服务 | 单个功能模块或全局 |
| 响应方式 | 快速失败（Fail Fast） | 返回兜底数据或简化流程 |
六、选型决策树
总结：熔断 vs 降级的本质区别
- 熔断 是 防御型策略 ，针对 外部依赖故障，通过断路避免连锁反应
- 降级 是 收缩型策略 ，应对 自身资源瓶颈，通过舍弃次要功能保住核心业务
- 组合使用原则：先熔断防止外部冲击，再降级缓解内部压力，最后限流控制全局流量