【系统架构设计】优雅降级：如何体面地\"坏掉\"
内容提要
该文讨论系统优雅降级设计，强调需预先规划故障时的功能取舍，而非被动失效。核心包括：降级目录分级、触发信号、开关配置、恢复顺序及用户提示。文章指出，熔断器需配合fallback，降级应比正常路径更便宜，并需定期演练验证。
延伸解读
熔断器不是降级，fallback 才是
文章开头的案例说明，配置了熔断器并不等于做了优雅降级。熔断器只是止损，切断对故障下游的调用，但如果没有 fallback 接管，异常会继续上抛，最终变成用户看到的白屏。真正的优雅降级需要提前设计好降级路径，明确降级后返回什么，而不是在故障现场临时想办法。
降级不是关闭，而是替换
降级不是简单地把功能关掉，而是用更便宜的计算或数据替换昂贵的路径。例如，搜索时只检索候选集子集，或读取本地缓存副本。降级路径必须比正常路径更便宜，否则降级本身可能成为新的负载源。设计降级时，要确保 fallback 逻辑简单、无网络依赖，避免降级路径自身拖垮系统。
恢复顺序与触发同等重要
降级后的恢复不能一刀切，需要按优先级分批进行，核心功能优先恢复，非核心功能最后恢复。同时要预留积压队列的清空时间，控制新流量的准入速率，避免恢复瞬间引发新的流量尖峰。恢复前要确认触发信号已稳定回落，并经过观察窗口，防止刚恢复又触发降级。
Q&A
什么是优雅降级？它与被动失效有什么区别？
优雅降级是提前设计好的系统在故障时按业务优先级有选择地牺牲部分功能、保留核心功能的策略，而被动失效是故障沿依赖链自然扩散、系统行为未经设计的结果。区别在于：优雅降级有预先定义的触发信号和动作，用户看到的是功能受限但可用的界面，而被动失效则表现为白屏、502等无差别错误。
降级目录分为哪几个级别？每个级别具体做什么？
降级目录分为六个级别：L1只读缓存兜底（读缓存旧值）、L2关闭个性化/推荐（返回通用榜单）、L3只读模式（关闭写路径）、L4关闭非核心写（保留核心写）、L5静态兜底页（用CDN静态页替换动态页）、L6保留核心链路其余拒绝（返回503）。级别可叠加，恢复代价和用户影响不成正比。
降级触发信号有哪些类型？为什么需要多种信号组合？
触发信号有四类：延迟/错误率SLO燃烧率、资源水位（CPU、队列长度等）、依赖熔断状态、人工战情室决策。单一信号容易误判（如短暂抖动触发假阳性），组合使用可提高准确性，通常要求至少两类独立信号同时越过阈值才触发降级。
降级开关的配置和管理有哪些关键点？
降级开关需要单独的可靠性等级，比保护的系统更简单可靠；分类上属于运维开关，长期存在；配置应包含key、scope、level、owner、auto_trigger、recovery等字段；应用侧需秒级生效，并记录状态变化日志和审计；定期自检和演练。
降级恢复时为什么要分批进行？恢复顺序如何设计？
分批恢复是为了避免所有被抑制的流量同时涌回造成新的尖峰。恢复顺序原则是：先降级的后恢复，后降级的先恢复；核心功能优先恢复，非核心功能最后恢复。配置中通过restore_order字段控制，数值越小越先恢复。
降级期间如何保证数据一致性？
降级期间需明确一致性边界：区分展示用途和决策用途的数据，决策数据不能信任降级路径的缓存；只读模式下写请求排队重放必须保证幂等；跨地域场景需确保降级开关生效范围与故障隔离边界对齐。
降级期间用户提示和客服支持应该怎么做？
用户提示应明确、诚实、可操作、一致，按降级级别准备文案模板；客服支持需有实时状态看板、对应话术模板、升级路径、降级解除通知和补偿预案。
降级与限流、熔断如何协同工作？
四层机制按顺序协同：入口限流（按配额拒绝）、负载脱落（按优先级丢弃）、功能降级（按功能裁剪）、熔断器（保护下游调用）。越靠前成本越低、粒度越粗，越靠后成本越高、粒度越细。降级发生在业务逻辑层，熔断打开后走fallback路径。
常见的降级反模式有哪些？
常见反模式包括：静默返回错误数据、降级本身增加系统负载、只降级不恢复、从不主动验证、没有可观测性、判断逻辑依赖它正要降级的对象。
