降级是一种具备策略性、可预先设置且能自动响应的系统性保障方法，其核心要点在于保障主干流程的顺畅运行、有效控制风险以及稳定用户体验。具体而言，它是按照业务的重要程度进行分级，并据此定义相应的开关；通过配置中心对这些开关进行统一管理，既支持自动触发，如根据超时、错误率或资源水平等条件来触发降级操作，也支持人工应急处理。同时，还会根据不同的场景，如读操作、写操作、页面展示以及依赖关系等，来选择合适的降级策略，并配套完善的监控机制、埋点技术、自动恢复功能以及日志追溯机制，以确保整个降级过程的可观测性、可操作性和可回溯性。

按业务重要性分级，提前定义降级开关

不能等到流量打进来才决定关什么。必须在日常就梳理清楚服务等级：

• 核心服务（如用户登录、商品查询、下单、支付）——不允许降级，必须保障可用性与响应时效
• 次核心服务（如订单详情、物流轨迹、优惠券发放）——可读降级（返回缓存）、延迟执行（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，确保问题可追溯，避免“降着降着忘了开”