3、降级策略详解：超时降级、失败率降级、限流降级、人工降级

降级策略是服务熔断的前置动作，也是系统在压力下保持基本可用性的最后防线。不同的降级策略针对不同的异常场景，选择合适的策略组合直接决定了系统的弹性边界。本节将深入剖析四种核心降级策略的原理、适用场景与配置要点。

3.1 降级策略全景对比

四种降级策略在触发条件、影响范围和恢复机制上存在显著差异。下表从关键维度进行横向对比：

3.2 超时降级

超时降级是最轻量、最常用的降级手段。当依赖的服务在指定时间内未返回结果，调用方立即执行降级逻辑，避免线程长时间阻塞。

核心配置参数

• 超时阈值：通常设置为P99延迟的1.5~2倍，例如P99为200ms，则超时设为300~400ms。
• 超时粒度：连接超时（ConnectTimeout）与读取超时（ReadTimeout）应分别配置，连接超时一般较短（500ms~1s），读取超时根据业务复杂度设定（1s~5s）。
• 降级响应：返回默认值、缓存数据或错误提示，避免抛出异常导致调用链断裂。

// 超时降级示例（使用Resilience4j）
@CircuitBreaker(name = "userService", fallbackMethod = "getUserFallback")
@TimeLimiter(name = "userService")
public CompletableFuture<User> getUser(String userId) {
    return CompletableFuture.supplyAsync(() -> userClient.fetchUser(userId));
}

public CompletableFuture<User> getUserFallback(String userId, TimeoutException ex) {
    // 返回缓存用户或默认用户
    return CompletableFuture.completedFuture(new User(userId, "default"));
}

3.3 失败率降级

失败率降级基于滑动窗口统计，当一段时间内的请求失败比例超过阈值时触发。它比超时降级更宏观，能有效防止局部故障扩散为全局雪崩。

统计窗口设计

• 窗口大小：建议10~30秒，过短容易误判，过长则响应迟钝。
• 最小请求数：设置触发统计的最小请求量（如5次），避免低流量时因少量失败误触发。
• 失败率阈值：通常设为50%~80%，核心服务建议50%，非核心服务可放宽至80%。

// 失败率降级配置（Hystrix风格）
circuitBreaker:
  requestVolumeThreshold: 20      # 10秒内至少20次请求才触发统计
  errorThresholdPercentage: 50    # 失败率超过50%开启降级
  sleepWindowInMilliseconds: 5000 # 半开探测等待5秒

3.4 限流降级

限流降级从请求速率维度控制流量，当请求量超过系统处理能力时，直接拒绝部分请求并返回降级响应。它与超时/失败率降级互补，前者控制入口流量，后者控制内部故障。

常用限流算法

3.5 人工降级

人工降级是自动化降级的最后补充，用于处理自动化策略无法覆盖的紧急场景。运维人员通过管理平台手动关闭非核心功能，保障核心链路稳定。

典型触发场景

• 发布回滚：新版本出现严重Bug，手动降级受影响的服务。
• 数据迁移：数据库主从切换期间，手动降级写入接口。
• 依赖故障：第三方服务大面积宕机，手动降级所有依赖该服务的功能。
• 流量突增：自动化限流仍无法控制流量时，手动关闭非核心功能（如评论、推荐）。

人工降级管理要点

3.6 降级策略协同流程

在实际生产环境中，四种降级策略并非独立运行，而是形成分层协同的防御体系。下图展示了从请求入口到服务内部的完整降级决策流程：

3.7 策略选型建议

在实际项目中，建议按以下优先级组合降级策略：

1. 入口层：部署限流降级（令牌桶+滑动窗口），控制整体流量水位。
2. 调用层：部署超时降级，为每个远程调用设置合理的超时阈值。
3. 统计层：部署失败率降级，基于滑动窗口监控服务健康状态。
4. 管理层：提供人工降级开关，作为应急兜底手段。