服务降级：有损服务的艺术

跳闸之后，用户看到什么

熔断把请求挡在门外，但 HTTP 总得回点什么。回 500？用户扭头就走，缓存里的商品详情白白放着。降级回答的是一个更冷静的问题：故障期间，用什么替代正常答案。注意是「替代」不是「糊弄」——用户可以接受推荐位变成热销榜，不能接受页面报错。

降级的四板斧

按用户感知从轻到重，常用四招：

选择顺序：能静默就不关功能，能关功能就不动主流程。降级越深，用户感知越强，决策链就要越往上走——所以预案必须提前定好，不能现场吵。

分级：谁是核心，谁先下桌

降级清单不能等出事再想，把功能预先分级：L0 核心链路（下单、支付、库存扣减）永不主动降，靠隔离与熔断保护；L1 重要功能（商品详情、搜索）可有损，静默降级优先；L2 边缘功能（推荐、评价、积分、动效）可全关，一有风吹草动先下桌。

degrade:
  switches:
    recommend: true     # 推荐已降级：返回运营配置的静态榜单
    review: true        # 评价入口已关闭
    points: false       # 积分明细正常

开关推到配置中心，一键全局生效。但注意开关自身的可用性：配置中心挂了怎么办？本地要留一份兜底配置，应用启动时加载，配置中心不可达时按本地配置走——给救火用的开关，自己先不能是单点。

降级的坑

三个高频坑，个个都是事故换来的：

缓存兜底没有保鲜策略——降级返回的缓存若是三天前的价格，比不降级还糟糕。兜底数据要有新鲜度要求与更新机制：定时刷新的静态榜单可以，陈年缓存不行。

只降不恢复——手动恢复容易忘，自动恢复要防抖：刚闭合又跳闸，来回横跳比持续降级更伤。恢复动作带上观察期，稳住几分钟再全量放开。

预案没演练过——写在 wiki 里的降级清单，第一次执行就在故障现场，十有八九手忙脚乱。定期按剧本把推荐关掉、把评价关掉，确认页面真的能活。

降级是「牺牲局部保全整体」，前提是局部之间先隔离——线程池互不拖累，才谈得上砍谁留谁；砍的动作要快、要局部，不能牵一发动全身。下篇聊舱壁模式：把船隔成一间间水密舱。