降级（Fallback）和熔断（Circuit Breaker）是微服务容错中两个相关但不同的概念，它们通常结合使用，但解决的问题和触发机制不同。以下是详细对比：

1. 核心区别

2. 典型场景

降级（Fallback）

• 案例：查询商品详情时，若主服务超时，降级返回缓存中的旧数据或默认值。
• 代码示例（Spring Cloud + Sentinel）：

  @GetMapping("/product/{id}")
  @SentinelResource(value = "getProduct", fallback = "getProductFallback")
  public Product getProduct(@PathVariable Long id) {
      // 主逻辑（可能抛出异常或超时）
      return productService.getDetail(id);
  }
  
  // 降级方法
  public Product getProductFallback(Long id) {
      return ProductCache.getDefaultProduct(); // 返回兜底数据
  }
  

熔断（Circuit Breaker）

• 案例：支付服务连续失败率超过50%，熔断器打开，后续请求直接拒绝，避免拖垮系统。
• 配置示例（Sentinel规则）：

  // 规则：5秒内异常比例>50%，熔断10秒
  DegradeRule rule = new DegradeRule("payService")
      .setGrade(RuleConstant.DEGRADE_GRADE_EXCEPTION_RATIO)
      .setCount(0.5)  // 阈值50%
      .setTimeWindow(10); // 熔断10秒
  

3. 协同工作流程

1. 正常请求：调用主逻辑，成功返回结果。
2. 部分失败：触发降级（返回备选结果），但不会熔断。
3. 持续失败：达到熔断条件（如异常比例阈值）→ 熔断器打开 → 后续请求直接走降级逻辑，不再调用主逻辑。
4. 恢复试探：熔断时间过后，进入半开状态，尝试放行少量请求，若成功则关闭熔断器。

4. 常见误区

• 误区1：认为降级必须依赖熔断。
  → 实际上，降级可以单独使用（如手动配置兜底逻辑）。
• 误区2：熔断后一定会降级。
  → 熔断后可以直接拒绝请求（如返回429 Too Many Requests），未必需要降级。

5. 如何选择？

• 优先降级：对用户体验要求高（如电商页面需展示兜底内容）。
• 优先熔断：对后端保护要求高（如支付服务不可用时应快速失败）。

最佳实践：通常同时配置，例如：

1. 单次失败 → 降级。
2. 持续失败 → 熔断 + 降级。

总结：降级是“温柔妥协”，熔断是“果断止损”，两者互补而非等同。