第四讲：降级响应数据模型设计——核心要素

降级响应数据模型，说白了就是给系统画一张“应急地图”。

地图上要标清楚：什么时候该降？降哪些功能？降到什么程度？数据怎么流动？

我刚开始带团队做降级设计时，踩过一个坑：只关注“降哪些模块”，完全没想过数据本身怎么变。结果生产上一触发降级，数据链路断了，下游系统全炸了。

嗯，这一讲，我们就来拆解降级数据模型的几个核心要素。

1. 核心要素概览

我个人习惯把降级数据模型拆成四层来看：

• 业务维度层 — 定义哪些业务可以降
• 环境维度层 — 定义在什么条件下降
• 预案维度层 — 定义降级后的数据策略
• 数据维度层 — 定义数据本身的形态变化

你想想看，这四层缺一个，降级方案就可能是纸上谈兵。

2. 业务维度层 — 分清主次

我遇到过很多团队，上来就画降级架构图，结果连哪些业务能降、哪些不能降都没搞清楚。

核心问题是：没按业务领域做“降级优先级矩阵”。

降级等级	业务类型	示例场景	数据要求
L0（不可降级）	核心交易、支付、登录	下单、支付扣款、用户认证	必须实时一致
L1（可降级）	非核心展示、推荐	商品详情页的“猜你喜欢”	可容忍缓存/兜底数据
L2（可抛弃）	日志、统计、埋点	用户行为上报、报表	可丢弃或延迟写入
L3（可熔断）	强依赖第三方高危服务	风控分析、外部信用查询	直接返回默认结果

举个例子。支付页面里的“推荐优惠券”模块，就算推荐算法挂了，页面也得正常展示。这时候就该给 L1 等级，准备一套默认优惠券兜底。

3. 环境维度层 — 识别真实故障

为什么会突然触发降级？不一定是流量洪峰，也可能是上游 DB 挂了，或者某个第三方接口超时。

所以，降级数据模型必须包含触发事件源。

• 流量维度：QPS 过线、响应时间飙升、线程池队列满
• 依赖维度：Redis 不可用、DB 连接超时、消息队列堆积
• 资源维度：CPU 满载、内存 OOM、磁盘空间不足
• 人工维度：运维手动拉闸、监控系统主动告警

我在项目中遇到过一种情况——流量正常、CPU 正常，就是某个下游接口间歇性超时。监控系统反复触发降级又恢复，导致数据状态来回震荡。最后加了个连续触发窗口，连续 3 次检测到超时才真正降下来。

4. 预案维度层 — 定义降级策略

一旦确认要降级，数据模型里就要明确三个问题：

1. 降级键是什么？——按用户维度降级？按接口维度降级？还是全局降级？
2. 降级到什么级别？——是返回缓存数据、静态数据、还是直接拒绝？
3. 怎么恢复？——多久检测一次上游状态？恢复后数据怎么合并？

我个人习惯用一张降级预案配置表来管理：

服务ID	降级键	降级级别	触发阀值	恢复策略	兜底数据源
user_service	全局	L2	DB 异常持续 5s	每 10s 探测一次	本地缓存用户快照
product_recommend	uid	L1	接口超时率 > 20%	静默 30s 后重试	热榜兜底数据
payment_check	接口	L3	三方响应 > 2s	熔断 60s	返回“通过默认值”

这里有个细节：兜底数据源。降级后不能空口返回，数据模型里必须指明从哪取数据。本地缓存？远端备份？静态文件？

5. 数据维度层 — 形态与生命周期

降级之后，数据不再是实时准确的。你得提前想好：

• 静态兜底数据：过期时间多长？更新机制是怎样的？
• 动态削峰数据：是否要本地缓存降级后的结果？TTL 怎么设？
• 冲突合并：降级期间用户做了操作，恢复后数据怎么合并？
• 过期清理：降级状态的标记数据，怎么自动清除？

举个例子。电商大促时流量冲垮了商品推荐系统，降级方案是返回“昨日热门”。但问题是，如果用户浏览期间主动点过某个分类，降级后的页面是否要尊重用户行为？

这就涉及到降级数据上下文的设计。我一般会在降级数据模型里加一个 ctx 字段，用于携带用户上下文，方便恢复后做数据拼接。

6. 核心模型示例（伪代码）

// 降级响应数据模型的简化定义
struct DegradationRule {
    String serviceId;          // 哪个服务
    int degradeLevel;          // L1/L2/L3
    String triggerEvent;       // 触发事件标识
    int continuousCount;       // 连续触发次数
    int timeoutMs;             // 检测超时
    boolean globalDegrade;     // 是否全局降级
    String fallbackSource;     // 兜底数据源
    int fallbackTTL;           // 兜底数据有效期(秒)
    boolean restoreAutoCheck;  // 是否自动恢复
    List excludeUids;  // 白名单用户
}

有了这个结构，就可以通过配置中心动态下发。线上遇到异常，改一条配置就生效。

7. 总结：降级数据模型的核心就是三个“明确”

1. 明确降级边界 — 哪些业务能降？降到什么程度？
2. 明确触发条件 — 什么异常触发了降级？持续多久才算真故障？
3. 明确数据策略 — 降级后数据从哪来？恢复后数据怎么处理？

你想想看，这三个点贯穿了前面讲的四层维度。把这三个问题想清楚，降级响应数据模型就不会跑偏。

嗯，这一讲的核心要素就这些。实际落地时，可以从小范围服务开始，跑通一遍降级链路再推广。