熔断与降级的核心区别在于触发条件和应用目标，具体差异及使用场景如下：
一、核心区别
| 对比维度 | 熔断 | 降级 |
|---|---|---|
| 触发原因 | 下游依赖服务故障（如超时、异常率过高）触发 | 系统整体负载过高或流量洪峰 |
| 管理目标层级 | 框架级保护（无业务优先级区分） | 业务级调整（需区分核心/非核心功能） |
| 实现方式 | 自动触发（如Hystrix断路器模式） | 手动配置或自动触发（需预设fallback逻辑） |
| 恢复机制 | 自动探测依赖恢复后逐步放量（半开状态） | 需人工介入或负载降低后恢复 |
| 影响范围 | 仅针对特定依赖服务（如订单服务依赖的支付接口） | 全局性调整（如关闭评论、推荐等非核心功能） |
二、具体使用场景
1. 熔断适用场景
- 依赖服务不稳定：下游服务频繁超时或报错（如第三方API不可靠、数据库响应慢）。
- 防止雪崩效应：避免故障扩散（如A→B→C调用链中，B故障时熔断A对B的调用）。
- 示例：
- 支付接口异常率超过50%时，触发熔断返回默认支付失败提示。
- 商品库存服务响应超时1秒，自动熔断并缓存请求至队列稍后重试。
2. 降级适用场景
- 流量洪峰应对：大促期间保障核心功能（如电商保留下单、支付，关闭积分兑换）。
- 资源争抢缓解：CPU/内存不足时关闭次要功能（如关闭实时数据分析页面）。
- 示例：
- 双11期间关闭商品评论和推荐模块，优先处理交易请求。
- 系统CPU使用率超过80%时，降级为静态页面返回简化数据。
3. 结合使用场景
- 熔断触发降级：当熔断开启后，可联动降级策略（如熔断商品详情页的库存查询接口，直接展示缓存数据）。
- 预案式降级：提前配置降级规则（如秒杀活动开始前关闭非核心服务）。
三、技术实现对比
| 技术点 | 熔断（Hystrix示例） | 降级（Spring Cloud示例） |
|---|---|---|
| 配置方式 | @HystrixCommand(fallbackMethod="fallback") | @FeignClient(fallback=FallbackClass.class) |
| 核心参数 | 错误率阈值、探测恢复时间窗口 | 流量阈值、资源使用率阈值 |
| 监控指标 | 断路器状态（Open/Half-Open/Closed） | 服务QPS、线程池利用率、响应时间 |
四、设计原则
- 熔断优先于降级：依赖故障应优先熔断避免资源耗尽，再通过降级提供有损服务。
- 降级需业务容忍：牺牲的功能必须是用户可接受的非核心服务（如关闭个性化推荐）。
- 动态调整能力：通过配置中心（如Apollo）实时修改阈值，无需重启服务。
