在 Spring Cloud 微服务架构中，
熔断（Circuit Breaker）和降级（Fallback / Degradation）
是保障系统高可用、防止雪崩的核心机制。
- 熔断：当下及服务不可用时，暂时不调用下级服务，并触发降级逻辑（一般是返回预设结果），避免故障蔓延
- 降级：服务中一部分功能暂时不提供服务，以保全主体服务可用。
熔断 vs 降级
| 维度 | 熔断（Circuit Breaker） | 降级（Fallback） |
|---|---|---|
| 目的 | 防止故障扩散，保护调用方 | 保证基本可用，提升容错性 |
| 触发条件 | 失败率/慢调用达到阈值 | 熔断、超时、异常、手动开关 |
| 是否调用下游 | 熔断期间不调用 | 可能调用（失败后才降级） |
| 关注点 | 系统稳定性 | 用户体验 & 功能可用性 |
| 关系 | 熔断后通常执行降级 | 降级可独立于熔断存在 |
💡 简单说：熔断是“断”，降级是“退”；熔断防系统崩，降级保用户体验的底。
实践建议
- 核心链路必加熔断（如支付、库存）。
- 非核心功能主动降级（如推荐、广告）。
- 降级返回要合理：避免空指针、误导用户。
- 监控熔断状态：通过
/actuator/sentinel或 Dashboard。 - 规则动态化：结合 Nacos 持久化熔断规则，支持运行时调整。
一、熔断（Circuit Breaker）
熔断是什么？
熔断是一种自动保护机制：
当某个下游服务调用失败率过高（如超时、异常），就“断开”对该服务的调用，
直接拒绝请求或快速失败，避免资源耗尽和故障蔓延。
类比：家庭电路中的保险丝——电流过大时自动断开，防止火灾。
解决了什么问题？
- 1、雪崩效应：一个服务慢 → 调用方线程阻塞 → 资源耗尽 → 整个系统瘫痪。
- 2、无效重试：明知服务已宕机，仍不断重试，浪费资源。
- 3、级联故障：A 调 B，B 调 C，C 挂了 → B 和 A 全挂。
怎么解决的？
- 1、监控调用状态（成功/失败/超时）。
- 2、当失败比例/慢调用比例超过阈值 →进入“熔断（Open）”状态。
- 3、熔断期间，所有请求不再真正调用下游，直接失败或走降级。
- 4、经过一段时间（如 5s），进入“半开（Half-Open）”状态，尝试放行少量请求：
- 4.1、成功 → 关闭熔断；
- 4.2、失败 → 继续熔断。
典型应用场景
| 场景 | 说明 |
|---|---|
| 支付服务不可用 | 订单服务调支付超时，触发熔断，避免订单服务线程池打满 |
| 第三方 API 响应慢 | 如短信、物流查询接口延迟高，熔断后走本地缓存或跳过 |
| 数据库连接池耗尽 | 下游 DB 响应慢，上游服务熔断保护自身 |
二、降级（Fallback / Service Degradation）
降级是什么？
降级是有损服务策略：
在系统压力大或依赖服务不可用时，主动返回简化结果或默认值，保证核心功能可用，牺牲非核心体验。
类比：电商大促时关闭“商品评论”“推荐列表”，只保留“下单”功能。
解决了什么问题？
- 1、用户体验崩溃：完全报错 vs 返回“暂无数据”。
- 2、资源争抢：非核心功能占用 CPU/内存/网络，影响主流程。
- 3、系统过载：高并发下，通过降级释放资源。
怎么解决的？
- 1、在代码中预设兜底逻辑（Fallback）。
- 2、当发生以下情况时执行降级：
- 2.1、熔断触发
- 2.2、调用超时
- 2.3、异常抛出
- 2.4、主动开关降级（如配置中心控制）
典型应用场景
| 场景 | 降级方案 |
|---|---|
| 用户头像服务挂了 | 显示默认头像 |
| 推荐系统不可用 | 不显示“猜你喜欢”模块 |
| 库存服务超时 | 先下单，异步扣库存（柔性事务） |
| 日志上报失败 | 丢弃日志，不影响主业务 |
三、通过 Sentinel 实现熔断与降级
Sentinel 是阿里巴巴开源的流量治理组件，支持熔断（降级规则）+ 降级逻辑（fallback）。
| 机制 | 核心思想 | Sentinel 实现方式 |
|---|---|---|
| 熔断 | 快速失败，防止雪崩 | DegradeRule（异常比例/慢调用） |
| 降级 | 有损服务，保障核心 | @SentinelResource的fallback/blockHandler |
一句话记住：
熔断是“我不调你了”，降级是“我给你个备用答案”。
完整工作流程（Sentinel 场景）
用户请求 → @SentinelResource("createOrder") ↓ [正常调用] → 成功？→ 返回结果 ↓ 否（异常/超时） [是否触发熔断规则？] ↓ 是 → 抛出 DegradeException → 执行 blockHandler ↓ 否 → 执行 fallback注意：blockHandler 优先级高于 fallback。只有未触发 Sentinel 规则但发生异常时，才走 fallback。
实现示例：
1、 添加依赖（Spring Boot 2.7 + Spring Cloud Alibaba）
<dependency><groupId>com.alibaba.cloud</groupId><artifactId>spring-cloud-starter-alibaba-sentinel</artifactId><version>2021.0.5.0</version></dependency>2、定义资源并配置 fallback
@RestControllerpublicclassOrderController{@GetMapping("/createOrder")@SentinelResource(value="createOrder",fallback="createOrderFallback",// 降级方法（处理异常/熔断）blockHandler="createOrderBlockHandler"// 规则触发处理（如熔断、流控）)publicStringcreateOrder(){// 模拟调用库存服务（可能超时或异常）if(Math.random()<0.6){thrownewRuntimeException("库存服务异常");}return"订单创建成功";}// fallback：处理业务异常publicStringcreateOrderFallback(Throwableex){return"【降级】订单创建失败，请稍后重试。原因："+ex.getMessage();}// blockHandler：处理 Sentinel 规则触发（如熔断）publicStringcreateOrderBlockHandler(BlockExceptionex){return"【熔断】当前服务繁忙，请稍后再试。";}}3、配置熔断规则（代码方式）
@ComponentpublicclassSentinelRuleConfigimplementsCommandLineRunner{@Overridepublicvoidrun(String...args){DegradeRulerule=newDegradeRule().setResource("createOrder")// 资源名.setGrade(RuleConstant.DEGRADE_GRADE_EXCEPTION_RATIO)// 异常比例熔断.setCount(0.5)// 异常比例阈值 50%.setMinRequestAmount(5)// 最小请求数.setStatIntervalMs(1000)// 统计窗口 1s.setTimeWindow(10);// 熔断时长 10sDegradeRuleManager.loadRules(Collections.singletonList(rule));}}其他熔断策略：
DEGRADE_GRADE_RT：慢调用比例（需配合setCount(响应时间ms)）DEGRADE_GRADE_EXCEPTION_COUNT：异常数（如 5 秒内异常 ≥ 3 次）
使用 Sentinel Dashboard 图形化配置（可选）
- 启动控制台：
java -jar sentinel-dashboard.jar - 访问
http://localhost:8088 - 在“降级”页面为
createOrder添加规则
