3. 降级策略设计：服务降级分类与回退逻辑

降级是分布式系统在过载或故障时，通过主动放弃非核心功能或使用简化版逻辑，来保障核心链路可用性的关键手段。设计不当的降级策略会导致“雪崩”或“假死”，而设计良好的降级则能实现“优雅地变慢，而不是彻底崩溃”。本节从分类、回退逻辑与数据兜底三个维度展开。

3.1 服务降级分类：静默降级 vs 主动降级

根据触发方式与执行时机，降级可分为两大类。理解其差异是制定策略的第一步。

3.2 降级回退逻辑（Fallback）

Fallback 是降级策略的执行体。当主逻辑被降级后，系统必须返回一个“有意义的响应”，而不是直接抛出异常或返回空指针。常见的 Fallback 模式包括：

• 返回静态默认值：适用于配置类、字典类数据。例如：return "0"、return new ArrayList<>()。
• 返回缓存数据（Stale Data）：允许返回过期的但可用的数据。例如：展示 5 分钟前的库存数量。
• 执行本地逻辑：从远程 RPC 降级为本地 Mock 或简化计算。例如：推荐算法降级为“热门榜”。
• 抛出业务异常（快速失败）：对于写操作或强一致性要求场景，直接告知用户“服务繁忙，请稍后重试”。

// 示例：使用 Resilience4j 的 Fallback 方法
@Degrade(name = "userService", fallbackMethod = "getUserFallback")
public User getUser(Long userId) {
    // 远程调用
    return userRpcClient.getUser(userId);
}

// Fallback 方法：返回本地缓存或默认用户
public User getUserFallback(Long userId, Throwable t) {
    log.warn("getUser degraded for userId: {}, reason: {}", userId, t.getMessage());
    // 1. 尝试从本地缓存获取
    User cached = localCache.getIfPresent(userId);
    if (cached != null) {
        return cached;
    }
    // 2. 返回默认匿名用户
    return User.defaultAnonymous();
}

3.3 降级数据兜底方案

降级后返回的数据质量直接影响用户体验。数据兜底方案需要根据数据一致性等级（CAP 权衡）来设计。

在实现层面，推荐使用“多层缓存 + 降级开关”的组合：

1. 第一层：实时远程数据（正常情况）。
2. 第二层：分布式缓存（Redis，降级时优先读取）。
3. 第三层：本地堆内缓存（Caffeine，作为最后兜底）。
4. 第四层：静态默认值（保底）。

3.4 降级策略设计总览

下图展示了从降级分类到 Fallback 执行，再到数据兜底的完整决策流程。

3.5 降级策略配置化实践

为了快速响应业务变化，降级策略不应硬编码在代码中，而应通过配置中心动态管理。推荐使用以下配置结构：

# 降级策略配置示例（YAML 格式）
degradation:
  rules:
    - resource: "userService:getUser"
      enabled: true
      degradeType: PASSIVE  # 静默降级
      fallbackMode: CACHE_THEN_DEFAULT
      cacheTtlSeconds: 30
      defaultResponse: '{"code":200,"data":null,"msg":"service busy"}'
      timeoutMs: 100
      minCalls: 10
      errorThreshold: 0.5
      
    - resource: "searchService:recommend"
      enabled: true
      degradeType: ACTIVE   # 主动降级
      fallbackMode: STATIC_LIST
      staticList: '[{"id":1,"name":"热门商品1"},{"id":2,"name":"热门商品2"}]'
      effectiveTime: "2025-06-18T00:00:00Z"
      expireTime: "2025-06-19T00:00:00Z"