在 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添加规则