2. 降级策略核心概念：服务依赖、降级阈值、降级动作、恢复机制

降级策略听起来高大上，说白了就是一套“留得青山在”的预案。系统快扛不住的时候，你主动砍掉次要功能，保住核心流程。这玩意儿我在线上验证过几十次，玩不好就是雪崩，玩好了则是续命神器。

下面我把四个核心概念揉碎了讲——服务依赖、降级阈值、降级动作、恢复机制。每块都带着血泪经验，你慢慢看。

2.1 服务依赖：先搞清楚谁离不开谁

你想做降级，首先得知道你的服务依赖了哪些东西。我见过最离谱的案例：一个订单服务直接调了十几个下游接口，连天气预报都调。结果天气预报挂了，订单也挂了——你说冤不冤？

服务依赖分两类：

我的做法是：画一张依赖图，标出每条调用的重要等级。重要等级低的服务，降级时优先砍。嗯，这里要注意——依赖关系是会演变的。产品上线一个月后，原来认为是弱依赖的东西可能变成了核心链路。所以每两周我建议复盘一次依赖图。

2.2 降级阈值：什么时候该动手？

光知道依赖还不够，你得定个“红线”。超过这条线，降级开关必须弹开。

常用的降级阈值指标：

• 错误率飙升：比如某个下游接口连续5秒错误率超过50%——直接降级。
• 响应时间超阈值：P99响应时间超过1000ms且持续10秒——降级。
• 排队长度：线程池里等待的任务数超过200——降级。
• 资源使用率：CPU、内存、连接池使用率超过80%——降级。

阈值怎么定？我习惯用“两步法”：先通过压测找到系统的极限值，然后打个7折作为初始阈值。比如压测发现1000并发时TP99是800ms，那我就把降级阈值设在600ms左右。为什么打7折？因为压测环境往往比线上干净，留点余量保险。

2.3 降级动作：砍了之后怎么办？

触发了阈值，你得执行降级动作。一共有四种典型动作，我按优先级列一下：

1. 返回默认值/缓存数据：下游挂了，直接返回静态数据或本地缓存的旧数据。比如商品详情页的销量数据，降级后显示“昨日销量”而不是实时数据。
2. 丢弃请求（限流降级）：直接返回“服务繁忙，请稍后再试”。适用于非关键请求，比如日志上报。
3. 熔断（快速失败）：连续失败n次后，熔断器打开，后面请求不再调用下游，直接返回失败响应。通常配合Hystrix或Sentinel实现。
4. 降低服务质量：比如视频从1080p降到480p，或者关闭实时推送功能。

我个人建议：优先选择“返回默认值/缓存数据”这种温和的降级方式。它起码让用户觉得系统还在工作。直接丢请求或者返回500，用户体验会很差。

2.4 恢复机制：降级了怎么回来？

降级不是终点。你总不能一直给用户返回旧数据吧？恢复机制同样重要。

• 自动恢复：持续监控降级指标，当指标连续恢复正常（比如错误率连续30秒低于5%），自动关闭降级开关。
• 半开状态（健康检查）：熔断器常见的恢复策略。熔断后进入半开状态，允许一小部分请求通过，如果成功则关闭熔断，如果失败则继续熔断。
• 手动恢复：保留一个运维入口，让人工确认后手动恢复。用于一些风险较高的场景，比如数据库挂了又恢复了，但你得先确认数据一致性。

恢复的节奏要慢。我通常让自动恢复的检查周期是降级触发周期的3倍。比如降级阈值是5秒内的错误率，那么恢复检查需要连续观察15秒。你想想看，如果刚恢复一个请求又失败了，那还不如再等一等。

2.5 四个概念如何联动？

不搞玄学，直接上一张结构图。

你看，这四个概念不是孤立的。依赖决定了阈值该设在哪，阈值决定什么时候执行动作，动作执行完之后必须考虑如何恢复。恢复后别忘了重新审视依赖关系——有些依赖可能已经弱化了，下次降级时优先级可以调低。

降级策略:
  order-detail:
    依赖等级: 强依赖
    阈值: { 错误率: 30%, 响应延迟: 800ms }
    动作: 返回本地缓存
    恢复: { 模式: 自动, 持续正常时间: 30s }