降级是有策略、可预置、能自动响应的系统性保障手段，核心是保主干、控风险、稳体验；按业务分级定义开关，通过配置中心统一管理，支持自动触发（超时、错误率、资源水位）与人工应急；区分读/写/页面/依赖场景选择策略，并配套监控、埋点、自动恢复与日志追溯机制。
按业务重要性分级，提前定义降级开关
不能等到流量打进来才决定关什么。必须在日常就梳理清楚服务等级：
- 核心服务（如用户登录、商品查询、下单、支付）——不允许降级，必须保障可用性与响应时效
- 次核心服务（如订单详情、物流轨迹、优惠券发放）——可读降级（返回缓存）、延迟执行（MQ异步）或限流后降级
- 边缘服务（如评论、分享、推荐、退货申请、地址修改）——允许直接关闭或返回静态兜底页
建议用配置中心（如Nacos、Apollo）统一管理各服务的降级开关状态，支持灰度、分集群、按用户标签动态开启/关闭。
降级要能自动触发，也要有人工兜底通道
靠人工点按钮处理突发流量太慢，系统需具备自动识别并响应的能力：
- 超时降级：调用下游接口平均RT连续5秒超过300ms，自动切换至默认值或缓存数据
- 错误率熔断式降级：某服务1分钟内失败率＞50%，自动触发降级，5分钟后尝试半开探测
- 资源水位联动：JVM老年代使用率＞90% 或 CPU持续＞95%达30秒，自动关闭非核心线程池与定时任务
-
人工应急入口：提供带签名校验的降级API（如
/api/v1/degrade?service=comment&op=disable&sign=xxx），便于SRE快速干预
不同场景选对降级方式，避免一刀切
降级不是简单“关服务”，而是根据调用位置和数据一致性要求选择合适策略：
- 读服务降级：数据库慢或不可用时，降级为只读Redis或本地Caffeine缓存；若缓存也失效，返回预设兜底数据（如“暂无评论”+静态评分）
- 写服务降级：秒杀扣库存时，先写Redis再异步落库，DB异常期间允许“超卖”但保证最终一致；日志类写入可直接丢弃
- 页面级降级：前端通过Feature Flag控制模块加载，后端返回精简版JSON（如去掉推荐区块、隐藏运费险入口），保持主流程可操作
- 依赖服务降级：调用外部风控或短信服务超时，跳过校验直接走默认策略（如免短信注册），后续异步补单
降级不是终点，必须配套可观测与恢复机制
降级生效后，用户感知可能变弱，但运维视角必须更清晰：
- 所有降级动作实时上报到监控平台（如Prometheus + Grafana），标注触发条件、影响范围、持续时间
- 降级期间关键指标单独埋点：降级请求占比、兜底数据命中率、缓存击穿次数
- 设置自动恢复策略：例如降级开启10分钟后，每30秒发起一次探针调用，连续3次成功则自动恢复服务
- 降级日志必须包含traceId，确保问题可追溯，避免“降着降着忘了开”
