【系统架构设计】优雅降级：如何体面地”坏掉”

大促当天，某电商详情页依赖一个”猜你喜欢”推荐服务。推荐服务的数据库慢查询把响应时间从 50 毫秒拉到了 6 秒。详情页的后端在拼装页面时同步调用了推荐接口，等待这 6 秒的线程迅速把连接池占满，接着评论、库存、优惠券这些和推荐毫无关系的模块也开始超时。十分钟后，整个详情页对外返回 502。事后复盘，团队发现系统里其实配置了熔断器——推荐服务的调用确实在第三分钟被熔断打开了，调用方立刻拿到了 CallNotPermittedException。问题是没有人为这个异常写 fallback，它被原样往上抛，最终变成了用户看到的白屏。

这个故障暴露的不是”没做保护”，而是”保护做了一半”。熔断器让系统不再对已经失败的下游做无谓调用，这是止损；但止损之后拿什么顶上，是另一件事，而且这件事必须在故障发生前就设计好，不能指望在事故现场临时想。被动失效（Passive Failure）是故障沿依赖链自然扩散的结果——没人规划过它会怎么表现，它就按最坏的方式表现；主动优雅降级（Graceful Degradation）则是提前按业务优先级划好边界：出问题时先牺牲什么、用什么替代、用户会看到什么、什么时候恢复。两者的最终请求成功率可能相差无几，但一个是”系统决定让你看到什么”，另一个是”系统只是碰巧还剩下什么”。

这也是本系列第 24、25、26 三篇的分工所在。《弹性设计模式》解决的是”出站保护”：熔断器判断还要不要继续调用某个下游，超时和舱壁限制单次调用能占用多少资源——但熔断器打开之后必须有一个 fallback 去接管，这正是本篇要补上的部分。《限流与过载保护》解决的是”入站保护”：请求量超过处理能力时，按什么规则丢弃哪些请求（负载脱落，Load Shedding）——它回答”接不接这个请求”，是一种粗粒度、按请求为单位的取舍。本篇要回答的是更细粒度的问题：同一个请求里，哪些功能可以先关、关了之后返回什么、什么时候恢复——这是按业务价值裁剪功能，而不是按请求整体拒绝。

本文要交代清楚三件事：

1. 被动失效和主动优雅降级的边界在哪里，“配了熔断器”为什么不等于”做了优雅降级”？
2. 降级应该分几个层次、由什么信号触发、恢复顺序怎么设计才不会引发二次故障？
3. 降级期间用户和客服看到、说的东西，怎么避免”沉默地返回错误数据”？

一、被动失效与主动优雅降级的边界

1.1 两种”坏掉”的方式

系统在压力下有两种典型的坏掉方式。

被动失效：故障没有被显式处理，顺着调用链原样传播或被放大。典型链条是——下游变慢 → 调用方线程阻塞 → 线程池耗尽 → 调用方自身对外表现为不可用 → 调用方的调用方也开始阻塞。文章开头的案例就是这种模式：熔断器切断了对推荐服务的调用，但切断之后的异常没有被接管，只是换了一种方式继续往外传播。

主动优雅降级：在设计阶段就回答清楚”当某个信号触发时，牺牲哪些功能、留哪些功能、降级期间返回什么”，并把这套逻辑实现成可以随时打开和关闭的开关。Google SRE 一书把这一点说得很直接：

“Serve degraded results by doing less work or dropping unimportant traffic. This strategy must be engineered into your service, and can be implemented only if you know which traffic can be degraded and you have the ability to differentiate between the various payloads.”（服务降级必须被预先工程化到系统里，且只有在你清楚哪些流量可以被降级、并且有能力区分不同请求负载的前提下才能实施。）

出处是 Site Reliability Engineering 第 22 章”Addressing Cascading Failures”中”Enter Degraded Modes”一节。这句话点出了优雅降级和被动失效的本质区别：降级是一种能力，需要提前投入工程实现；被动失效则是这种能力缺失时的默认下场。

需要澄清一个容易混淆的地方：被动失效不等于”系统完全宕机”。很多被动失效的系统表面上仍然在返回响应——只是返回的内容是未经设计的、不可预测的。可能是一个泄漏了内部堆栈信息的 500 错误页面，可能是因为超时链路复杂而返回了不完整的 JSON，也可能是数据库连接池耗尽后，一部分请求恰好命中了还有空闲连接的实例、侥幸成功了,另一部分请求全部失败——这种”部分能用、部分不能用，但没人能解释规律”的状态，同样属于被动失效，因为它不是任何人设计出来的结果。

1.2 一个更早的表述：功能耦合

Michael Nygard 在 Release It! 出版后接受 InfoQ 采访时，把这个问题讲得更加具体。他说全书真正的”元问题”（meta-problem）就是优雅降级：

“The meta-problem, if you will, though is graceful degradation. … Should customers still be able to book a room on the hotel site when we can’t show local restaurant listings for that location? … those features are coupled, because both kinds of page requests are served by the same request-handling thread pools in the same app servers.”

翻译过来：酒店预订网站的”本地餐馆推荐”挂了，用户还应该能订房吗？从业务逻辑上看，这两个功能毫无关系；但如果它们共享同一个请求处理线程池，“餐馆推荐变慢”就会通过线程池耗尽拖垮”订房”——这正是舱壁模式要解决的资源隔离问题，但资源隔离只是前提，隔离之后餐馆推荐模块具体应该返回什么、以什么方式关闭，仍然需要单独设计，这就是优雅降级要接手的部分。

1.3 边界对照表

这张表里最容易被忽视的一行是”依赖的前置能力”：优雅降级不是一个开关就能实现的功能，它要求你已经把系统拆成了可以独立关闭的功能单元，且每个单元关闭后有明确的替代行为。做不到这一点，就算写了 try-catch，也只是把被动失效包装得好看一点，本质上还是被动的。

1.4 被动失效的传播路径

文章开头案例的失效路径可以画成一条链：

flowchart LR
    A["推荐服务慢查询<br/>响应时间 50ms → 6s"] --> B["详情页同步等待<br/>推荐接口返回"]
    B --> C["请求处理线程<br/>被长时间占用"]
    C --> D["线程池耗尽"]
    D --> E["评论/库存/优惠券<br/>请求无线程可用"]
    E --> F["详情页整体返回 502"]
    G["熔断器 3 分钟后打开"] -.打开但无人接管.-> F

这条链上有两处本可以被拦截，但都没有发挥作用：一是熔断器确实在第 3 分钟打开了，但打开后的 CallNotPermittedException 没有被捕获，等于白打开；二是详情页把推荐、评论、库存这几个互不相关的功能放进了同一个线程池，重现了 Nygard 提到的”功能耦合”问题——即便熔断器被正确处理了，只要线程池共享的问题不解决，下一个变慢的依赖（评论、优惠券服务）还是会用同样的方式把详情页拖垮。这也是为什么优雅降级不能只在”某个依赖的调用点”单独考虑，而必须先确认舱壁隔离已经到位——降级解决的是”这个功能坏了之后返回什么”，舱壁解决的是”这个功能坏了会不会连累别的功能”，两者缺一不可。

1.5 判断标准：能不能回答”为什么是这个降级”

一个实用的判断题：如果现在把某次故障期间系统的实际行为拿给设计者看，设计者能不能立刻回答”为什么会降级成这个样子，是谁决定的，什么时候恢复”？

• 能立刻回答——说明这是主动降级：降级动作、触发条件、恢复条件都提前记录在案（比如第五节要讨论的配置中心里的开关定义）。
• 只能事后靠猜——比如”好像是某个超时导致缓存穿透，然后连锁反应，具体哪一步导致了当前这个现象不确定”——这就是被动失效，即使表面上系统还能返回响应，本质上这个响应内容也是偶然的产物，下一次同样的故障可能会以完全不同的方式表现出来。

二、Google 的例子：过载时”体面地变差”

2.1 降级的核心思路：用更便宜的计算换可用性

SRE 一书第 21 章”Handling Overload”给出了两个具体例子，说明什么叫”服务质量下降但仍然可用”：

“Instead of searching an entire corpus to provide the best available results to a search query, search only a small percentage of the candidate set.”

“Rely on a local copy of results that may not be fully up to date but that will be cheaper to use than going against the canonical storage.”

第一个例子是搜索：全量检索一个候选集的成本远高于检索候选集的一个子集，过载时用子集换取延迟和资源的下降。第二个例子是缓存：读一份可能不是最新的本地副本，比每次都打到权威存储（canonical storage）便宜得多。这两个例子共享同一个原则——降级不是关闭功能，而是把”精确但昂贵”的路径换成”近似但便宜”的路径。

第 22 章”Addressing Cascading Failures”里，“Load Shedding and Graceful Degradation”一节把这个原则往前推了一步，给出了检索场景更具体的版本：

“Graceful degradation takes the concept of load shedding one step further by reducing the amount of work that needs to be performed. In some applications, it’s possible to significantly decrease the amount of work or time needed by decreasing the quality of responses. For instance, a search application might only search a subset of data stored in an in-memory cache rather than the full on-disk database or use a less-accurate (but faster) ranking algorithm when overloaded.”

这里明确点出了两条降级路径：一是只搜索内存缓存里的子集，不碰磁盘上的全量数据；二是过载时切换成精度更低但更快的排序算法。Google Cloud Architecture Center 后来在公开的架构框架文档中，用一个更贴近日常经验的例子复述了同样的思路：

“During periods of high load, Google Search prioritizes results from higher-ranked web pages, potentially sacrificing some accuracy. When the load decreases, Google Search recomputes the search results.”

高负载时优先展示排名靠前的结果、牺牲一部分排序精度，负载下降后重新计算——这和”用简化排序算法”是同一类思路的两种说法，都属于”降低计算量、保留可用性”。

2.2 一次真实的降级案例：Shakespeare 服务

SRE 一书在第 22 章用一个匿名化的真实案例说明降级如何在生产事故中起作用，标题是”Cascading Failure and Shakespeare”：

一部关于莎士比亚的纪录片在日本播出，片中提到了 Google 内部一个提供莎士比亚作品检索的服务（Shakespeare service），随后亚洲数据中心的流量激增，超过了该服务的容量上限，恰好这个数据中心当时又在对该服务做一次大版本更新，双重压力叠加。原文写道：

“The developers built graceful degradation into the service. As capacity becomes scarce, the service no longer returns pictures alongside text or small maps illustrating where a story takes place. And depending on its purpose, an RPC that times out is either not retried … or is retried with a randomized exponential backoff.”

容量紧张时，服务不再随文字一起返回插图和用于展示故事发生地的小地图——只保留纯文本这一核心内容；同时区分了两类超时 RPC 的处理方式：非核心的图片请求超时后不重试，核心请求超时后按带随机抖动的指数退避重试（呼应《弹性设计模式》里讨论过的抖动策略）。即便有这些安全网，任务还是逐个失败并被 Borg 重启，任务数进一步下降，SRE 最终通过临时扩容恢复了服务。

这个案例里有三点值得记下来：第一，降级的对象是”次要的展示内容”（图片、地图），而不是核心的文字检索能力，这正是”按业务价值裁剪”的具体体现；第二，降级和超时重试策略是分开配置的——同一个服务里不同类型的 RPC 可以有不同的降级/重试规则；第三，降级本身没能完全兜住这次故障，最后还是靠增加容量解决——降级延缓了问题恶化的速度，但不能替代容量规划，这一点在本文第十节反模式部分还会再展开。

2.3 降级决策需要提前回答的三个问题

SRE 一书在同一节里给出了设计降级机制时必须回答的三个问题，这三个问题构成了本文后续几节的骨架：

1. 用什么信号判断该不该进入降级模式（CPU 使用率、延迟、队列长度、线程数，还是需要人工介入）——对应本文第四节。
2. 进入降级模式后具体做什么——对应本文第三节的降级目录。
3. 降级应该实现在哪一层：每一层都做，还是只在一个高层的关卡（choke point）做——对应本文第五、九节。

书里还补充了一条容易被忽视的告诫：

“Remember that the code path you never use is the code path that (often) doesn’t work. … You can make sure that graceful degradation stays working by regularly running a small subset of servers near overload in order to exercise this code path.”

降级代码平时几乎不会被触发，这意味着它很可能存在你从未发现的 bug。唯一的解法是定期主动让一小部分服务器逼近过载，强制走一遍降级路径——这正是《混沌工程》里 Game Day 演练要验证的内容之一，本文第十一节还会回到这一点。

2.4 Netflix：把 fallback 当成和主逻辑一样需要保护的代码路径

Netflix 的 Hystrix 是最早把”熔断之后必须有 fallback”这件事做成通用基础设施的项目之一，2012 年的 Netflix Tech Blog 文章”Fault Tolerance in a High Volume, Distributed System”（《弹性设计模式》参考资料中已引用）详细描述了它的设计。这里补充一个前两节没有展开、但对降级实现非常关键的细节：fallback 本身也需要被当作一段可能失败的代码来对待，而不是默认它一定能瞬间成功。

Hystrix 官方 Wiki 在”How it Works”一节里给出了写 fallback 时的明确要求：

“Write your fallback to provide a generic response, without any network dependency, from an in-memory cache or by means of other static logic. If you must use a network call in the fallback, you should do so by means of another HystrixCommand.”

也就是说，fallback 应该优先从内存缓存或静态逻辑里取一个通用响应，不发起任何网络调用；如果确实需要在 fallback 里发起网络调用（比如降级到读一个备份存储），这次调用本身也必须包在另一个受保护的 command 里，不能是一次裸调用。Netflix Tech Blog 原文进一步解释了这样做的原因：

“We also use semaphores to protect against non-trusted fallbacks. … if an implementation is done that involves a network call and becomes latent, the fallback itself won’t be able to take down the entire app as it will be limited in how many threads it will be able to block.”

如果 fallback 里悄悄藏了一次网络调用，而这次调用恰好也变慢了，那么”降级路径”自己就会变成压垮系统的新原因——这正好呼应本文第十节要讨论的反模式”降级本身增加了系统负载”。用 Resilience4j 的组件表达同样的设计原则，大致是这样：

// 主调用路径：舱壁 + 熔断器保护对推荐服务的调用
Supplier<List<Item>> primaryCall = Decorators
    .ofSupplier(() -> recommendationClient.getPersonalized(userId))
    .withBulkhead(recommendationBulkhead)
    .withCircuitBreaker(recommendationCircuitBreaker)
    .decorate();

// fallback 路径：只读内存缓存，不发起任何网络调用，
// 并且用独立的、容量很小的信号量兜底，防止 fallback 实现被误改成同步网络调用后拖垮调用线程
Bulkhead fallbackGuard = Bulkhead.of("recommendationFallback",
    BulkheadConfig.custom().maxConcurrentCalls(50).maxWaitDuration(Duration.ZERO).build());

Supplier<List<Item>> guardedFallback = Bulkhead.decorateSupplier(
    fallbackGuard,
    () -> fallbackCatalog.getPopularItemsFromMemory(userId)); // 纯内存查表，无 IO

Try<List<Item>> result = Try.ofSupplier(primaryCall)
    .recover(throwable -> guardedFallback.get());

这里给 fallback 单独配一个舱壁（fallbackGuard），不是因为内存查表本身会阻塞，而是作为一道”契约保护”——即使未来有人把 getPopularItemsFromMemory 改成了一次真实的远程调用（这种改动在代码评审中很容易被忽略），这个独立舱壁也能把影响范围限制住，不会让降级路径本身变成新的雪崩源头。

三、降级目录：从轻到重的六个层级

把”降级”当成一个开关来谈没有意义——不同功能能承受的裁剪程度完全不同。实践中比较容易落地的做法是,把降级动作按”用户可感知程度”和”恢复代价”分级，建立一份团队共用的降级目录（Degradation Catalog），每次设计新功能时都对照着看它应该挂在哪一级。

几点补充说明：

L1 到 L4 是功能级降级，L5、L6 已经接近请求级的负载脱落。 L6 和上一篇讨论的负载脱落几乎是同一件事——区别只在于 L6 仍然区分了”核心”和”非核心”两类请求并分别处理，而纯粹的负载脱落可以不关心请求内容、只按配额丢弃。把这两者放在同一张表里，是为了说明降级和限流不是互相独立的两套机制，而是同一条防线上强度不同的刻度，第九节会把它们串成一条完整的编排链路。

级别之间不是互斥的，是可叠加的。 一次真实的降级往往同时触发多个级别：只读缓存兜底（L1）和关闭个性化（L2）经常一起打开，因为个性化计算本身就依赖对最新数据的强一致读取。

恢复代价和用户可见影响不成正比。 L1 对用户几乎无感，但如果缓存刷新机制设计不当，恢复到读权威存储时可能出现缓存和数据库不一致的短暂窗口；L6 对用户影响巨大，但因为逻辑简单（一刀切拒绝），恢复反而最直接。设计降级方案时不能只看”用户会不会有感知”，还要看”这一级降级引入了什么新的状态，恢复时要不要清理”。

目录需要随业务演进定期复核。 一个功能今天是非核心的（比如某个刚上线不久的推荐入口），半年后可能因为承接了更多流量、和更多下游耦合，变成事实上的核心路径。降级目录不是写完就归档的文档，需要绑定到功能的迭代节奏上定期复核，否则它记录的会是系统半年前的样子，而不是当下真实的优先级。

把一个具体页面拆解成依赖图，再标注每个依赖对应的降级级别，是把目录落地到具体系统最直接的方式。以文章开头的商品详情页为例：

flowchart TD
    P["商品详情页请求"] --> Core["核心信息：标题/价格/库存展示<br/>不降级，任何时候必须返回"]
    P --> Rec["推荐模块<br/>L2：关闭后返回通用热门榜单"]
    P --> Rev["评价模块<br/>L1：读缓存中的历史评价快照"]
    P --> Cpn["优惠券模块<br/>L4：非核心写，异步领取记录可延后"]
    P --> Buy["加入购物车/下单入口<br/>L3：极端情况下才关闭"]

    style Core fill:#2d333b,stroke:#3fb950,color:#adbac7
    style Rec fill:#2d333b,stroke:#f0883e,color:#adbac7
    style Rev fill:#2d333b,stroke:#388bfd,color:#adbac7
    style Cpn fill:#2d333b,stroke:#636e7b,color:#adbac7
    style Buy fill:#2d333b,stroke:#f85149,color:#adbac7

这张图把”页面”拆解成了若干个独立可降级的模块，每个模块标注了自己的降级级别——这正是本文开头案例里缺失的一环：如果详情页的架构师提前画出这样一张图，就会立刻发现”推荐模块”和”核心信息”共享同一个请求处理线程池是一个需要单独隔离的风险点，而不是等故障发生后才发现两者被意外耦合在了一起。

下面是 L2（关闭推荐）的一个简化实现示例，展示”降级不是关闭，是替代”这个原则在代码层面的样子：

public class RecommendationFacade {

    private final DegradationSwitch degradationSwitch; // 远程配置驱动的开关
    private final RecommendationClient recommendationClient;
    private final FallbackCatalog fallbackCatalog; // 预先计算好的通用热门榜单

    public List<Item> getRecommendations(String userId, String pageContext) {
        if (degradationSwitch.isDegraded("recommendation.personalized")) {
            // 降级路径：不再调用推荐服务，直接返回预计算的通用榜单
            return fallbackCatalog.getPopularItems(pageContext);
        }
        try {
            return recommendationClient.getPersonalized(userId, pageContext);
        } catch (CallNotPermittedException | TimeoutException e) {
            // 熔断器打开或调用超时时的兜底，同样落到通用榜单
            // 而不是把异常继续往上抛给页面渲染逻辑
            metrics.increment("recommendation.fallback", "reason", e.getClass().getSimpleName());
            return fallbackCatalog.getPopularItems(pageContext);
        }
    }
}

这段代码有两条路径都会走到 fallbackCatalog：一条是配置中心主动下发的降级开关（提前决策，属于本文的主动降级），另一条是熔断器打开后的异常兜底（被动触发，但有人接管，所以仍然是”优雅”的）。两条路径殊途同归，这正是第九节要讨论的编排关系——降级开关和熔断器的 fallback 应该指向同一套兜底逻辑，避免维护两份不一致的降级实现。

L3（只读模式）的实现思路和 L2 不同：L2 是替换某个功能模块的返回内容，L3 是在请求入口处统一拦截写请求。下面是一个网关层中间件的示意实现：

class ReadOnlyModeMiddleware:
    """在网关层统一拦截写请求，避免每个业务接口各自判断降级状态"""

    WRITE_METHODS = {"POST", "PUT", "PATCH", "DELETE"}
    EXEMPT_PATHS = {"/api/v1/login", "/api/v1/payments/callback"}  # 核心路径不受只读模式影响

    def __init__(self, degradation_switch, app):
        self.degradation_switch = degradation_switch
        self.app = app

    def __call__(self, request):
        is_write = request.method in self.WRITE_METHODS
        is_exempt = request.path in self.EXEMPT_PATHS

        if is_write and not is_exempt and self.degradation_switch.is_degraded("checkout.write_path"):
            return Response(
                status=503,
                body={
                    "code": "READ_ONLY_MODE",
                    "message": "当前写入功能维护中，预计稍后恢复，您仍可正常浏览",
                },
                headers={"Retry-After": "60"},
            )
        return self.app(request)

这个实现把只读模式的判断收敛到网关这一层，而不是让每个业务接口重复判断——好处是新增一个写接口时不需要额外记得接入降级逻辑，只要它符合 WRITE_METHODS 的约定就自动受到保护；EXEMPT_PATHS 用来显式声明哪些接口即使在只读模式下也必须继续工作（登录、支付回调这类核心路径），避免只读模式的一刀切规则误伤了本应保留的功能。Retry-After 头是对第八节”可操作提示”原则的直接落地——不只是告诉用户”现在不行”，还给出一个具体的重试参考时间。

3.1 怎么给功能定级：一个简单的打分框架

降级目录不是一次性写完的清单，新功能上线时应该同步评估它属于哪一级。一个可操作的做法是从四个维度打分，而不是单纯凭直觉判断”这个功能重不重要”：

• 收入/交易相关性：这个功能挂了，是否直接阻断用户完成一笔交易？直接阻断（如支付、下单）应划入 L3 及以上边界；只影响体验但不阻断交易（如推荐、评价展示）通常划入 L1、L2。
• 耦合系数：有多少其他功能通过共享资源（线程池、数据库连接、缓存实例）和它耦合？耦合系数越高，就越需要尽早给它配置独立的舱壁隔离和明确的降级开关——耦合系数高但没有隔离的功能，正是本文第一节里 Nygard 提到的”酒店预订和餐馆推荐共享线程池”式风险的来源。
• 降级实现复杂度：关闭这个功能需要多大的工程投入？纯读接口通常只需要一个开关和一份静态兜底数据，实现成本低；涉及状态变更的写路径需要考虑幂等、补偿、恢复顺序，实现成本高。复杂度高不是不做的理由，而是需要更早规划的信号。
• 用户感知度：功能关闭后，用户会不会明显察觉、是否会因此投诉或流失？高感知度的功能即使不涉及交易，也需要认真设计第八节讨论的用户提示文案。

四个维度不需要加权成一个单一分数——更实用的做法是分别标注高/中/低，再结合业务负责人的判断确定具体级别。这个过程本身也应该有产品或业务方参与，而不是完全由工程团队闭门决定，因为”哪个功能更重要”最终是一个业务判断，工程团队能提供的是”实现这个降级需要多大代价”这类技术输入。

四、触发条件：从延迟燃烧率到人工战情室

4.1 四类触发信号

以上四类信号不是互斥的替代关系，而是同一套触发体系里可以叠加校验的不同证据来源，具体的组合逻辑见 4.2 节。

延迟/错误率 SLO 燃烧率：这一类信号直接复用《SLO 工程》里讲过的燃烧率模型。如果一个用户旅程的错误预算在过去一小时内以 14.4 倍速度消耗，按同一篇文章给出的对照表，这个预算在两小时内就会耗尽——此时触发降级，比等到预算完全耗尽、SLO 已经被突破之后再反应要及时得多。降级和告警可以共享同一套燃烧率计算：告警通知人，降级直接改变系统行为，两者的输入是同一个指标，只是消费方式不同。

资源水位：CPU 使用率、请求队列深度、线程池占用率这些指标反应更快，但单独看容易误判。SRE 一书在讨论”Queries per Second”的陷阱时指出，不同请求的资源消耗差异很大，用固定的 QPS 阈值判断是否过载并不可靠，更稳妥的做法是直接测量资源消耗（CPU 时间、内存），而不是用请求数做代理指标。这个结论同样适用于降级触发：与其设一个”QPS > 5000 就降级”的规则，不如直接看 CPU 使用率或线程池排队时间。

依赖熔断状态：当某个下游的熔断器进入 Open 状态，调用方立刻知道”这个依赖暂时不可用”，这本身就是一个现成的降级触发信号——不需要额外去猜测下游是否健康。设计上要区分依赖的重要程度：核心依赖（如支付网关）熔断可能需要触发 L3（只读模式）甚至更严重的降级；非核心依赖（如推荐服务）熔断只需要触发 L2。这个区分需要在系统设计阶段就明确写进依赖清单，而不是留到故障现场临时判断。

人工战情室：并不是所有场景都能靠指标自动判断。一次涉及多个团队、原因尚不明确的复合故障，往往需要人工决策”现在要不要主动关掉某个功能”。SRE 一书把这个选择直接列成了设计决策之一：

“Whether your service enters degraded mode automatically or if manual intervention is necessary?”

这不是一道有标准答案的题——完全自动化的降级反应快，但增加了系统复杂度，也增加了”复杂的降级逻辑本身诱发新故障”的风险（第十节反模式会具体讨论）；完全依赖人工则响应慢，且强依赖值班人员的经验和当时的判断力。多数成熟团队的做法是分层：L1、L2 这类影响范围小、可快速回滚的降级自动触发；L3 及以上涉及关闭写路径的降级需要人工确认，哪怕只是在自动检测后弹出一个需要一键确认的告警。

4.2 为什么单一信号不够用

只用一种信号触发降级，容易出现两类判断错误：

• 假阳性：一次短暂的网络抖动让 5 分钟窗口内的错误率瞬间冲高，如果直接以此触发 L3 只读模式，代价（用户无法下单）远大于收益（其实几十秒后错误率就自己回落了）。
• 假阴性：CPU 使用率长期稳定在 60%，看起来毫无压力，但如果这 60% 里有一部分线程正阻塞在等待一个变慢的下游上，实际可用的处理能力已经大幅下降，仅看 CPU 使用率会完全错过这个信号。

比较稳妥的做法是像《SLO 工程》里讨论多窗口燃烧率告警一样，要求至少两类独立信号同时越过阈值才真正触发降级，用长窗口确认问题在持续，用短窗口确认问题是当前正在发生的。以 Prometheus 告警规则表达，大致是这样：

groups:
  - name: degradation-trigger
    rules:
      # 信号一：1 小时和 5 分钟窗口的错误预算燃烧率同时超过 6x（复用 28 篇的燃烧率定义）
      # 信号二：推荐服务的熔断器同时处于 Open 状态
      # 两者同时成立，才认为需要触发 L2 降级，避免单一信号误判
      - alert: TriggerRecommendationDegradation
        expr: |
          (
            slo:product_detail_error_rate:1h > (6 * 0.001)
            and
            slo:product_detail_error_rate:5m > (6 * 0.001)
          )
          and
          (circuit_breaker_state{service="recommendation"} == 1)  # 1 表示 Open
        for: 1m
        labels:
          action: degrade
          switch_key: "recommendation.personalized"
          target_level: "L2"
        annotations:
          summary: "触发推荐服务降级：燃烧率和熔断状态同时异常"

这条规则本身只负责判断”是否应该触发”，真正执行开关切换的动作交给一个订阅告警事件的自动化脚本或平台去调用配置中心的 API——告警系统和执行系统分离，是为了保证告警规则可以被安全地测试和回放，而不会在测试告警规则时意外触发一次真实的线上降级。

4.3 决策流程

下面这张图给出了一个简化的降级决策流程，帮助把上面四类信号和第三节的降级目录串起来。

图为示意流程，不代表任何具体系统的真实阈值——实际的信号选择、层级划分和恢复条件需要结合具体业务的依赖关系和 SLO 来确定。

这张图的核心逻辑分三步：第一步判断是否触发了过载或错误预算告警；第二步在触发后判断”还能不能承受得起计算成本更低的响应”——能则走功能降级（关推荐、只读缓存、降精度），不能则直接走负载脱落（按优先级丢弃、返回 503），这正是第九节要展开的编排关系；第三步是恢复，要点是”错误预算回升 + 显式解除 flag”，且要先恢复高价值功能——第六节会详细讨论恢复顺序为什么重要。

五、开关与配置中心：让降级可以随时插拔

5.1 降级开关需要单独的可靠性等级

一个容易被忽视的原则：控制降级的开关，可靠性要求比它所保护的系统更高，同时复杂度要比它所保护的系统更低。 SRE 一书对这一点的表述是：

“Complex load shedding and graceful degradation can cause problems themselves … Design a way to quickly turn off complex graceful degradation or tune parameters if needed. Storing this configuration in a consistent system that each server can watch for changes … can increase deployment speed, but also introduces its own risks of synchronized failure.”

翻译过来是两条建议：第一，降级逻辑本身要保留一个”一键关闭”的开关，万一降级逻辑写错了，能立刻回滚，不能让降级逻辑本身变成新的故障源；第二，如果用一个统一的配置系统给所有实例推送降级状态，要意识到这个配置系统一旦出问题，可能导致所有实例同步进入（或同步退出）降级状态——这是一种新的单点风险，需要额外的谨慎。这也是为什么很多团队的降级开关会同时保留两条路径：配置中心推送（正常路径）和本地静态配置兜底（配置中心不可用时的最后防线）。

5.2 开关的分类与生命周期

降级开关本质上是特性开关（Feature Flag）的一种，对应四象限分类中的”运维开关（Ops Toggle）“：长期存在、由 SRE/运维团队负责、变化频率低但需要极快的生效速度。它和用来做灰度发布的”发布开关（Release Toggle）“有本质区别——发布开关上线后几周内应该被清理，运维开关则会伴随对应功能的整个生命周期长期存在，因为过载场景不会消失。把这两类开关混在同一套治理流程里管理，很容易出现”发布开关按周清理，结果连带清理了正在生效的降级开关”这种事故。

一个可落地的降级开关 schema 大致包含以下字段：

# 配置中心中的降级开关定义（示例，字段命名以 Apollo/Nacos 风格为参考）
degradation_switches:
  - key: "recommendation.personalized"
    scope: "product-detail-service"      # 生效范围：服务级 / 接口级 / 全局
    level: "L2"                          # 对应第三节的降级级别
    default_state: "enabled"             # 默认状态：不降级
    owner: "recommendation-team"
    fallback_description: "改用预计算通用热门榜单，来源见 fallback-catalog 服务"
    auto_trigger:
      metric: "burn_rate:1h"
      threshold: 6.0                     # 对应 28 篇中 6x 燃烧率告警
      require_manual_confirm: false
    recovery:
      cooldown_seconds: 300              # 触发解除条件后，观察窗口再决定是否真正恢复
      restore_order: 20                  # 数值越小恢复越靠前，见第六节

  - key: "checkout.write_path"
    scope: "order-service"
    level: "L3"
    default_state: "enabled"
    owner: "order-team"
    fallback_description: "只读模式，前端展示'下单功能维护中'提示"
    auto_trigger:
      metric: "burn_rate:5m"
      threshold: 14.4
      require_manual_confirm: true        # 涉及关闭核心写路径，强制人工确认
    recovery:
      cooldown_seconds: 600
      restore_order: 90                  # 恢复顺序靠后，最后一批打开

这份配置里有几个关键设计：require_manual_confirm 直接落实了第四节关于自动/人工决策的分层原则；restore_order 提前把恢复顺序编码进配置本身，而不是留到故障现场再商量；owner 字段保证每个开关都有明确的责任人，这一点在第十节讨论”没人知道哪些 flag 在生效”这个反模式时会再强调。

5.3 应用侧的读取与生效延迟

降级开关的价值取决于它的生效速度。如果用配置中心（如 Apollo/Nacos/etcd）做长连接推送，从下发到应用侧生效通常可以做到秒级；如果退化成”改配置文件、重启服务”，这个开关在真正的故障现场基本没有意义——故障往往几分钟就会造成大面积影响，等不起一次滚动重启。以下是应用侧监听降级开关变化的一个示意实现：

type DegradationSwitch struct {
    mu    sync.RWMutex
    state map[string]bool // key -> 是否处于降级状态
}

func (d *DegradationSwitch) IsDegraded(key string) bool {
    d.mu.RLock()
    defer d.mu.RUnlock()
    return d.state[key]
}

// 由配置中心 SDK 的 watch 回调触发，秒级生效
func (d *DegradationSwitch) OnConfigChange(key string, degraded bool) {
    d.mu.Lock()
    prev := d.state[key]
    d.state[key] = degraded
    d.mu.Unlock()

    if prev != degraded {
        log.Printf("degradation switch changed: key=%s degraded=%v", key, degraded)
        metrics.Gauge("degradation.switch.state", boolToFloat(degraded), "key", key)
        // 状态变化必须可观测，避免出现第十节讨论的"没人知道哪些 flag 在生效"
        alertOnStateChange(key, degraded)
    }
}

这里有意把状态变化的日志、指标、告警写在一起——降级开关的每一次翻转都应该留痕，这是第十节反模式部分要强调的可观测性要求的最小实现。

5.4 定期自检，而不是等故障发生才第一次使用

第二节引用过 SRE 一书的告诫：降级路径平时几乎不会被执行，意味着它很可能带着从未被发现的 bug。落到配置中心层面，这条告诫对应两件具体的事：

• 开关本身需要审计日志。 每一次状态变化都要留下”谁在什么时候因为什么原因切换了这个开关”的记录，而不只是当前状态的一个布尔值。一条审计记录大致包含：switch_key、from_state、to_state、trigger_source（自动规则名或人工操作者）、timestamp、related_incident（如果关联了某次故障或演练）。这份记录既是第十节强调的可观测性的一部分，也是复盘时还原”降级的时间线和依据”的唯一可靠来源。
• 定期做”冷启动”演练。 每个季度选择一个低风险时段，在一个隔离的小流量分片上真实触发一次降级开关（而不是只测试配置能否下发），确认 fallback 路径的返回内容、格式、延迟符合预期，再手动恢复。这类演练可以并入《混沌工程》的常规 Game Day 计划里，作为固定的一项检查，而不是单独发起一次专项活动。

这两件事共同的目的是：把”降级机制是否可用”从一个只能靠故障验证的假设，变成一个可以在平时持续验证的事实。

六、分级执行与恢复顺序

6.1 降级要分批，不要一刀切

即使确定要触发某一级降级，也不建议对所有实例、所有流量一次性生效。一个稳妥的顺序是：先在单个机房或一小部分流量上验证降级逻辑本身没有问题（毕竟如第二节所说，降级代码路径平时很少被执行，很可能带着未被发现的 bug），确认无误后再全量推开。

这个顺序看起来会拖慢降级生效的速度，但对于影响范围大的降级（L3 及以上），跳过灰度直接全量往往意味着”如果降级逻辑本身有问题，会立刻造成比原故障更大的新故障”，得不偿失。对于影响范围小、逻辑简单的降级（L1、L2），可以适当压缩甚至跳过灰度阶段，用更快的速度换取止损时机。

6.2 恢复顺序：先复核心，再复次要

降级的对称面是恢复，而恢复往往比触发更容易被低估。一个常见的错误是”错误预算一回升，就把所有降级开关同时关掉”——这等于让所有被压制的流量在同一时刻涌回系统，很容易引发《弹性设计模式》里讨论过的雷群效应的另一个变体：不是重试请求同步到达，而是被抑制的正常功能同步恢复,瞬间叠加成一次新的流量尖峰。

恢复顺序的基本原则和触发顺序相反：先降级的后恢复，后降级的先恢复；核心功能优先恢复，非核心功能最后恢复。 这也是上一节配置示例里 restore_order 字段存在的原因——checkout.write_path（L3，涉及核心写路径）恢复顺序值是 90，recommendation.personalized（L2，非核心）是 20，数值越小越先恢复，也就是说非核心的推荐功能反而应该更早尝试恢复，因为它对系统的冲击更小，可以用来验证系统是否真的具备了承载全量流量的能力，验证通过后再逐步放开写路径。

恢复过程中，如果某个环节存在积压队列（比如降级期间被排队而非直接执行的异步写入），需要先估算清空这个积压队列所需要的时间，再决定何时打开对应的入口流量。用一个简化的排队模型可以得到一个粗略的下限：如果队列深度为 \(Q\)，系统在恢复后能提供的处理速率为 \(\mu\)，新流量的到达速率为 \(\lambda\)（且要求 \(\mu > \lambda\)，否则积压永远无法清空），那么清空这批历史积压所需的额外时间近似为

\[ T_{\text{drain}} = \frac{Q}{\mu - \lambda} \]

这只是一个流体近似（fluid approximation），没有考虑到达过程和服务时间的具体分布，但足以说明一个工程结论：恢复速度不是”开关一开就恢复”，而是要预留出 \(T_{\text{drain}}\) 这段时间，期间新流量的准入速度需要人为控制在低于 \(\mu\) 的水平，否则积压永远追不上。这也是为什么第六节强调恢复要分阶段、按比例放量，而不是一次性把所有降级开关同时置回默认状态。

举一个纯粹用来说明推导过程的算例（数值为便于演示的假设值，非任何真实系统的实测数据）：某订单服务在只读模式期间积压了 \(Q = 3000\) 笔延后写请求，正常处理能力是每秒 \(\mu = 60\) 笔，同一时间新订单的到达速率是 \(\lambda = 40\) 笔/秒。按上面的公式，清空积压大约需要

\[ T_{\text{drain}} = \frac{3000}{60 - 40} = 150 \text{ 秒} \]

这意味着从解除只读模式到系统真正消化完这批历史积压，需要至少 150 秒，且这段时间里如果新订单的到达速率超过 40 笔/秒，实际耗时会更长。据此可以反推出恢复期间的准入控制策略：与其立刻放开全部流量，不如先用一个限流器把新订单的准入速率压在 40 笔/秒以下，等积压清空后再逐步放开到正常水平。用令牌桶实现这样一个渐进放量的准入控制器，大致是：

type RampUpLimiter struct {
    bucket      *rate.Limiter
    targetRate  float64       // 恢复后的目标速率，例如 60/s
    startRate   float64       // 恢复期间的起始速率，例如 40/s
    rampSeconds float64       // 从起始速率线性提升到目标速率所需的秒数
    startedAt   time.Time
}

func (r *RampUpLimiter) currentRate() float64 {
    elapsed := time.Since(r.startedAt).Seconds()
    if elapsed >= r.rampSeconds {
        return r.targetRate
    }
    // 线性插值：从 startRate 逐步提升到 targetRate，避免恢复瞬间涌入全量流量
    progress := elapsed / r.rampSeconds
    return r.startRate + (r.targetRate-r.startRate)*progress
}

func (r *RampUpLimiter) Allow() bool {
    r.bucket.SetLimit(rate.Limit(r.currentRate()))
    return r.bucket.Allow()
}

这个限制器的准入速率随时间线性提升，而不是恢复那一刻直接设成目标速率——目的就是把 \(T_{\text{drain}}\) 这段时间显式地体现在准入控制里，而不是寄希望于”下游自然能扛住”。

6.3 恢复检查清单

一份可执行的恢复 playbook，通常需要覆盖以下几项：

• 触发降级的原始信号（燃烧率、资源水位、熔断状态）是否已经稳定回落到阈值以下，并保持了一段观察窗口（对应第五节配置里的 cooldown_seconds），而不是刚回落就立刻恢复。
• 是否存在需要清空的积压队列，预计清空时间是多少，恢复期间的准入速率如何控制。
• 按 restore_order 从小到大分批打开开关，每打开一批观察系统指标一段时间再继续。
• 是否需要通知客服团队”用户可见的降级提示即将消失”，避免客服还在按降级期间的话术回复用户（第八节详细展开）。
• 恢复完成后，是否已经把这次降级期间新暴露的问题（比如 fallback 数据格式有误、某个 owner 字段填错）登记为后续待办，而不是等下一次触发时才重新发现。
• 事后是否需要一次简短复盘，即便这次降级本身工作正常——目的是确认触发阈值、恢复顺序是否仍然合理，业务在这段时间内是否发生了会影响这些参数的变化。

七、一致性边界：降级期间用户看到了什么

优雅降级不可避免地会改变系统的一致性和数据新鲜度边界，这些边界必须提前想清楚，而不是留给用户自己发现。

7.1 关闭个性化/推荐之后

用户会从”千人千面”的排序切换到通用榜单。这里最容易出问题的地方不是排序本身，而是切换的边界是否清晰——如果只有部分接口切到了通用榜单，另一些接口仍然尝试个性化（比如首页降级了，但搜索结果页没有），用户会在同一次会话里看到两种明显不一致的推荐逻辑，体验上比”整体都用通用榜单”更差。降级方案设计时应该以”用户旅程”而不是”单个接口”为单位划分，《SLO 工程》一文中按用户旅程（商品浏览、下单支付、物流查询）划分 SLI 的思路，同样适用于划分降级范围。

7.2 只读缓存与最终一致性

L1 级别的降级把强一致读（读权威存储）换成了最终一致读（读缓存）。这意味着降级期间，用户可能看到的库存数、订单状态、余额存在几秒到几分钟的滞后。这本身不是问题——只要这个滞后窗口被显式定义并且不会导致业务逻辑错误。真正的风险在于把这份滞后数据用在了不该用的地方：例如库存数被缓存了 30 秒，如果下单扣减逻辑直接读这份缓存值做判断，就可能出现超卖。正确的做法是区分”展示用途”和”决策用途”——展示库存可以读缓存，但真正决定”能不能卖”的库存扣减必须落到能保证一致性的路径上（不论是数据库行锁还是分布式锁），即使这意味着扣减接口本身不在降级范围内。

7.3 只读模式下的写请求与幂等性

进入 L3 只读模式后，写请求不是简单地报错，更好的处理方式通常是排队延后处理（如果业务允许），或者明确拒绝并给出可操作的提示（“当前下单功能维护中，预计 X 分钟后恢复”）。如果选择排队延后，就必须保证这些排队中的写请求在系统恢复、批量重放时是幂等的——否则用户在降级期间因为页面没反应而重复点击提交，恢复后这些重复请求被同时重放，会造成重复下单或重复扣款。幂等键的设计、去重窗口的选择，属于另一个独立的话题，具体方案可以参考《幂等性设计》。这里需要强调的是：降级方案里只要出现”排队延后重试”这个环节，幂等性设计就不是可选项，而是前置条件——没有幂等保证的情况下让写请求排队重放，是拿一个故障换另一个故障。

7.4 跨地域场景下的边界

如果系统本身部署了多活或异地容灾（《容灾架构》讨论的多活拓扑），降级状态是否需要跨地域同步是一个容易被忽略的问题。一个常见的错误场景是：A 地域因为局部依赖故障触发了 L2 降级，但降级开关的生效范围没有正确设置（对应第五节配置里的 scope 字段），结果 B 地域的用户也看到了不属于自己的降级提示，或者反过来——A 地域已经降级，但用户的后续请求被负载均衡切换到了仍在正常提供个性化服务的 B 地域，导致同一个用户在同一次会话里看到两种不一致的体验。降级开关的生效范围必须和实际的故障隔离边界严格对齐：一个数据中心内部的资源问题，只应该影响该数据中心的开关状态，不应该被误配置成全局生效，反之亦然。这类跨地域一致性问题的完整解决方案属于容灾架构的范畴，本文不再展开。

八、用户提示与客服支持剧本

8.1 用户可见文案的原则

降级期间的用户提示，核心原则是明确、诚实、可操作，而不是用含糊的措辞掩盖问题。

• 明确：告诉用户具体是哪个功能受影响，而不是笼统地说”系统繁忙”。“当前下单功能维护中，浏览和加购不受影响”远比”系统繁忙，请稍后再试”有用——后者会让用户误以为所有功能都不可用，从而放弃访问原本仍然可用的部分。
• 诚实：如果核心交易功能确实不可用，不要用轻描淡写的措辞（比如把”无法下单”包装成”系统优化中”）。诚实的提示能减少用户重复尝试、重复投诉的概率，因为用户知道问题的真实范围和大致原因。
• 可操作：告诉用户接下来能做什么——“稍后重试”“已收藏订单，恢复后会通知您”“请通过 App 而非网页端下单”，这类提示比单纯的报错信息更能降低用户的挫败感。
• 一致：同一次降级期间，网页端、App、客服话术、状态页展示的内容应该是同一份信息源的不同呈现，而不是各写各的。用户很容易同时打开网页和 App 对比，一旦发现两边说法不一致，会进一步降低对系统状态描述的信任。

反面例子是文章开头的场景：详情页整体返回 502，用户唯一能得到的信息是”这个网站打不开”，完全无法判断问题范围，也不知道该不该换个时间再试，这正是被动失效和主动降级在用户体验上的直接差距。

按降级级别预先准备提示文案模板，能避免故障现场临时组织语言、措辞前后不一致的问题：

模板里的 [X] 这类动态字段应该来自第四节配置里的预估恢复时间或历史平均恢复时长，而不是留空或写一个不负责任的”稍后”——含糊的时间估计和完全不给时间估计相比，后者反而更容易让用户放弃等待、转而重复刷新页面，加重系统负担。

8.2 客服支持 playbook

降级期间，客服团队面对的用户咨询量通常会上升，如果客服拿到的信息和实际生效的降级状态对不上，会进一步放大用户的不满。一份可执行的客服 playbook 至少应该包含：

• 实时状态看板：客服能直接查到当前生效的降级开关列表（对应第五节配置里的 key、level、fallback_description 字段），而不是靠工程师口头转达。
• 对应话术模板：每个降级开关配一段面向用户的标准话术，客服不需要临时组织语言，也不会出现不同客服说法不一致的情况。
• 升级路径：客服判断”这不是已知的降级范围，可能是新故障”时，应该有明确的升级联系人和响应时限，避免把新故障误判为”正常的降级现象”而耽误响应。
• 降级解除通知：第六节提到过，恢复时需要同步通知客服——如果客服还在用降级期间的话术回答已经恢复的问题，会造成新的困惑。
• 补偿/挽回预案：涉及交易类的降级（如只读模式导致用户下单失败）通常伴随一定的用户流失和投诉，客服 playbook 应该提前明确是否有优惠券、补偿等挽回手段，以及客服自己能不能直接发放，还是需要审批——降级发生的当下不是现场讨论补偿政策的好时机。

一个可以直接对接状态看板的公开状态页（如 Statuspage、Cachet 等自建方案）能进一步减少客服的咨询压力，把”当前哪些功能受影响”这类问题从客服转移到用户自助查询，但状态页展示的内容应该和第五节配置中心里的降级开关状态保持同源，而不是维护第二份需要手工同步的信息。

九、编排：与限流、熔断协同工作

优雅降级不是孤立生效的，它是一条完整防线里的一环。把《限流与过载保护》、本文和《弹性设计模式》放在一起看，一次请求从进入系统到得到响应，理论上会依次经过四层判断：

flowchart TD
    A["请求进入网关"] --> B{"入口限流：<br/>是否超过 QPS/并发配额?"}
    B -->|超限| C["直接拒绝<br/>返回 429"]
    B -->|未超限| D{"负载脱落：<br/>是否需要按优先级丢弃?"}
    D -->|丢弃低优先级请求| E["返回 503<br/>不进入业务逻辑"]
    D -->|放行| F{"功能降级：<br/>当前请求涉及的功能<br/>是否处于降级状态?"}
    F -->|是| G["走 fallback 路径<br/>缓存/通用榜单/只读"]
    F -->|否| H["调用下游服务"]
    H --> I{"熔断器：<br/>下游是否处于 Open 状态?"}
    I -->|是| G
    I -->|否| J["正常调用下游"]
    J -->|调用失败或超时| G
    J -->|调用成功| K["正常响应"]

这四层的分工和触发时机完全不同：

• 入口限流（25 篇）是第一道关卡，按配额粗粒度拒绝，不关心请求内容，成本最低，反应最快。
• 负载脱落（25 篇）在限流之后、业务逻辑之前生效，按请求的优先级标签决定丢弃谁，同样不进入具体的业务处理逻辑。
• 功能降级（本篇）发生在请求已经进入业务逻辑之后，按功能维度而不是请求维度做取舍——同一个请求里，核心部分正常处理，非核心部分走 fallback。
• 熔断器（24 篇）作用于具体的下游调用，判断某个依赖是否还值得调用；熔断器打开后走的 fallback 路径，通常就是本篇第三节讨论的降级目录里的某一级。

这个顺序背后的工程判断是：越靠前的机制成本越低、粒度越粗，越靠后的机制成本越高、粒度越细。 限流和负载脱落几乎不消耗业务逻辑的计算资源，应该先做；功能降级和熔断需要进入具体的业务处理路径才能判断，成本更高，但换来的是更精细的用户体验——同一个请求里能保留多少就保留多少，而不是整体一刀切拒绝。当系统压力大到连计算”该走哪个 fallback”都变得奢侈时，就应该退回到更靠前、成本更低的负载脱落甚至限流，这也是第三节里 L6 级别和负载脱落边界重叠的原因。

反过来，这个链路也说明了一个容易被忽视的问题：如果只做了限流和负载脱落，没有功能降级这一层，系统在没到限流阈值之前的表现完全无法预测——因为没有任何机制告诉它”哪些功能可以先放弃”，一旦某个非核心依赖变慢，故障会径直按被动失效的方式扩散，这正是本文开头案例发生的原因。

需要说明的是，上面这个顺序针对的是同步的、用户直接等待响应的请求路径。对于异步消费的场景（比如消息队列里的批处理任务、离线报表生成），排序逻辑会不一样：这类请求背后没有一个正在等待的用户，负载脱落（直接丢弃或延后整批任务）往往可以排在功能降级之前，因为”延迟处理一批离线任务”的用户可感知代价远低于”牺牲这批任务里的某个字段”。具体顺序需要结合请求路径上是否存在一个正在实时等待的用户来判断，不能不加区分地套用同一套顺序。

9.1 一份跨层的组合配置示例

在实践中，这四层机制通常分别由不同的组件实现（网关、限流中间件、应用代码、Resilience4j/Sentinel），但把它们对同一个业务功能的配置放在一起看，有助于检查是否存在遗漏或矛盾。以”下单”这个核心用户旅程为例：

# 针对"下单"用户旅程的分层防护配置汇总（示例，非单一组件的真实配置格式）
checkout_journey:
  gateway_rate_limit:
    qps_limit: 2000              # 25 篇：入口限流
    per_client_quota: 200

  load_shedding:
    priority: "high"             # 25 篇：下单请求标记为高优先级，最后被丢弃
    shed_threshold_cpu: 0.85

  degradation:
    switch_key: "checkout.write_path"   # 本篇：只读模式开关
    level: "L3"
    depends_on_circuit_breaker: "paymentService"  # 与熔断状态联动，见 4.1 节

  circuit_breaker:
    target: "paymentService"     # 24 篇：出站保护
    fallback: "checkout.write_path"  # 熔断打开后触发的降级开关，与 degradation 字段呼应

这份汇总配置里最重要的一行是 depends_on_circuit_breaker 和 fallback 的相互引用——它把”支付服务的熔断状态”和”下单只读模式的降级开关”显式关联了起来,避免出现两套系统各自维护一份规则、互相不知情的情况。至于每一层具体在哪个组件、用什么协议下发，取决于团队已有的技术栈，这里只强调这几层配置在逻辑上必须能对得上账，能够被同一份文档或同一张图完整描述。

十、反模式

10.1 静默返回错误数据

比”报错”更危险的是”不报错但数据是错的”。典型场景：库存缓存过期后，降级逻辑继续展示旧值而不做任何标记，用户看到”有货”下单后才发现实际已经缺货；或者推荐降级时返回的通用榜单其实是几天前生成的，其中包含已经下架的商品。降级可以牺牲精度和实时性，但不能牺牲数据的正确性边界——如果某份数据可能过期，就必须在系统内部标记清楚这份数据的新鲜度，并且在触及”能不能卖、能不能扣款”这类决策点时，绝不能直接信任降级路径上的数据（呼应第七节关于只读缓存的讨论）。

10.2 降级本身增加了系统负载

一些降级实现比正常路径更复杂——比如降级时触发大量日志打印、告警风暴，或者 fallback 逻辑本身需要额外的计算（例如实时生成一个”简化版”页面，而不是直接读预先渲染好的静态内容）。如果降级路径的资源消耗接近甚至超过正常路径，降级就完全失去了意义,甚至会成为压垮系统的最后一根稻草。降级路径的设计目标应该始终是”比正常路径更便宜”，这也是第二节里 Google 的例子反复强调的——降级不是换一条同样贵的路，而是换一条明显更便宜的路。

10.3 只降级不恢复

降级开关打开容易，关闭往往被遗忘——尤其是当降级期间业务侧发现”用户好像也没太抱怨”“通用榜单的点击率似乎还行”，团队可能会倾向于不再优先处理恢复，把降级状态长期保留下来。这样做的后果是：本该被推动的根因修复（比如推荐服务的容量扩容、慢查询优化）失去了紧迫性，降级从”临时止损手段”变成了事实上的永久架构决策，而这个决策从未经过真正的评审。第五节里为每个降级开关配置 owner 字段的目的之一，就是让”这个开关还开着，为什么”这件事有人持续负责，而不是没人问起就一直保持默认状态。

10.4 从不主动验证，一恢复就出新故障

第二节引用过 SRE 一书的告诫：降级代码路径平时几乎不会被执行，出问题时才第一次真正被使用，风险很高。如果团队从来不主动在可控范围内演练降级和恢复流程，那么真正需要降级的时候，很可能会同时暴露”降级逻辑本身有 bug”和”恢复逻辑引发雷群”两个新问题——这正是《混沌工程》里 Game Day 演练存在的意义，第十一节还会具体讨论。

10.5 没有可观测性：不知道现在哪些开关生效

如果一个系统里同时存在几十个降级开关，但没有统一的地方能一眼看出”现在哪些处于打开状态、是谁在什么时候打开的、预计什么时候恢复”，团队会陷入两难：新入职的工程师排查一个”奇怪的行为”时，很可能根本想不到要去检查降级开关；而已经离职或转岗的人设置的开关，也可能长期无人知晓地生效着。第五节强调的状态变化必须留痕、必须有 owner，正是为了避免这个问题——降级开关的可观测性和它保护的业务指标同等重要，缺了它，降级机制本身就变成了一个黑盒故障源。

10.6 判断逻辑依赖它正要降级的对象

一个更隐蔽的反模式是循环依赖：判断”要不要触发降级”的逻辑，自身又依赖某个可能正在故障的组件。比如降级判断需要读取配置中心里的实时阈值，而配置中心恰好和触发故障的基础设施共享同一套底层存储或网络；又比如判断”推荐服务是否需要降级”的规则引擎，本身通过调用另一个也可能过载的规则服务来完成计算。一旦触发降级所需要的判断能力本身失效，系统既不会正常工作，也不会进入预期的降级状态，而是卡在两者之间一个未定义的状态。规避方法是让触发判断所需的最小依赖集合，独立于它所要保护的系统之外，并且尽量简单——这也呼应了第五节”降级开关本身要比它保护的系统更简单”的原则，这个原则不仅适用于开关的执行路径，同样适用于开关的判断路径。

十一、开放问题

降级决策的自动化边界在哪里？ SRE 一书把”自动触发还是人工介入”列为一个需要针对具体场景权衡的设计决策，而不是给出一个统一答案。自动化能缩短响应时间，但复杂的自动降级逻辑本身可能诱发新的故障模式（如误判、级联触发多个开关、恢复时的自动化和人工判断冲突）；完全依赖人工则受限于值班人员的经验和当时的信息完整度。这个边界目前没有形式化的判断标准，更多依赖具体系统的故障历史和团队的运维成熟度——一个可行的验证手段是通过混沌工程的 Game Day 演练，持续测试自动降级逻辑在各种边界条件下的实际表现，用真实的失败案例反过来修正”哪些该自动、哪些该人工”的边界，而不是在设计阶段一次性拍板。

降级期间的一致性保证如何系统化验证？ 本文第七节给出了一些经验性的原则（区分展示用途和决策用途的数据、排队重放必须幂等），但这些原则目前依赖工程师逐个场景手工审查，还没有看到成熟的、能自动检测”某个降级路径破坏了某种一致性保证”的工具或方法论。这和更广义的分布式系统一致性验证（如基于形式化方法的模型检查）是否可以结合，是一个仍然开放的方向。

特性开关数量增长后，降级方案的组合爆炸怎么处理？ 《特性开关架构》一文提到，\(N\) 个开关意味着理论上有 \(2^N\) 种组合状态，普通功能开关尚且难以做到组合测试全覆盖，专门用于降级的运维开关同样存在这个问题——当多个降级开关同时打开时（例如同时触发了 L2 和 L4），组合出的系统状态是否被真正验证过，还是只验证过每个开关单独打开的情况，这在开关数量增长后会越来越难以保证，目前主要依赖限制同时可能触发的开关组合数量和针对已知高风险组合的专项演练，而不是穷举验证。

功能优先级的决策权应该归工程还是归业务？ 第三节的打分框架把”收入相关性”“用户感知度”这类维度交给业务方判断，把”实现复杂度”“耦合系数”交给工程团队判断，但真正出现分歧时——比如业务方认为某个功能绝不能降级，而工程团队评估它的实现成本和风险都极高——目前没有一个通用的仲裁机制。《SLO 工程》一文讨论过用错误预算来仲裁”产品要不要发布新功能”这类冲突，但”哪个功能该在降级目录里排第几位”是一个更早期、更依赖业务上下文的决策，是否也能找到类似的量化仲裁方式，还需要更多实践积累。

十二、总结

优雅降级要解决的问题很朴素：系统迟早会遇到扛不住的压力，与其让故障沿着依赖链随机扩散、最终变成用户面前一片空白的报错页面，不如提前想清楚”扛不住的时候，先放弃什么、留住什么、用什么顶上、什么时候收回决定”，把这套逻辑变成可以随时打开关闭的开关，而不是留到事故现场临时决定。

被动失效和主动降级的分界线，不在于是否配置了熔断器或限流规则，而在于故障发生后，系统的行为是”被设计过的取舍”还是”碰巧剩下的样子”——《弹性设计模式》里的熔断器打开之后，需要一个明确的 fallback 去接管，这个 fallback 具体做什么，就是本文讨论的降级目录；《限流与过载保护》里的负载脱落解决”接不接”，本文解决”接了之后，哪些功能可以先关掉”；《SLO 工程》里的错误预算燃烧率，是触发降级最直接可量化的信号之一。四篇文章合在一起，才是从”入口流量控制”到”业务功能取舍”再到”下游调用保护”的完整链路。

降级目录要按业务价值分级维护，触发信号要区分自动和人工，开关本身要比它保护的系统更简单、更可靠，恢复要分批进行并且核心功能优先——这些原则单独看都不复杂，难点在于把它们提前落到具体的功能清单和配置里，而不是等故障发生时才现场发明。文章开头那次因为熔断之后没人接管而演变成全站 502 的事故，本质上不是熔断器的问题，而是团队从未真正回答过”熔断之后拿什么顶上”这个问题——这正是优雅降级要提前交的作业。

导航

上一篇：限流与过载保护：保命的最后一道防线

下一篇：容灾架构：多活与灾备设计

参考资料

书籍与规范

• Betsy Beyer, Chris Jones, Jennifer Petoff, Niall Richard Murphy, Site Reliability Engineering: How Google Runs Production Systems, O’Reilly, 2016. 第 21 章 “Handling Overload” 给出了”检索候选集子集”“读本地旧副本”两个降级换取可用性的例子；第 22 章 “Addressing Cascading Failures” 中 “Load Shedding and Graceful Degradation” 一节给出了降级的设计三问和”降级代码路径需要定期演练”的告诫，“Enter Degraded Modes” 与案例框 “Cascading Failure and Shakespeare” 给出了具体的生产降级案例。
• Michael T. Nygard, Release It! Design and Deploy Production-Ready Software, 2nd Edition, Pragmatic Bookshelf, 2018. 稳定性反模式与稳定性模式（熔断器、舱壁、超时、稳态）一章是本篇第一节讨论”被动失效”成因的基础参考。
• Pete Hodgson, “Feature Toggles (aka Feature Flags)”, martinfowler.com, 2017. 特性开关四象限分类的出处，本篇第五节区分”运维开关”与”发布开关”的依据。

采访与技术博客

• InfoQ, “Book Excerpt and Review: Release It!”, infoq.com. Michael Nygard 在采访中把优雅降级称为全书的”元问题”，并给出酒店预订与本地餐馆推荐耦合的例子，是本篇第一节的核心引用来源。
• Google Cloud Architecture Center, “Design for graceful degradation”, Reliability pillar, docs.cloud.google.com. 给出了 Google 搜索在高负载下优先展示高排名结果、牺牲部分精度的现代复述，与 SRE 一书的经典例子相互印证。
• Google SRE, “Handling Overload” 与 “Addressing Cascading Failures”，sre.google/sre-book 在线版本，内容与前述书籍一致，便于查阅具体段落原文。
• Netflix Technology Blog, “Fault Tolerance in a High Volume, Distributed System”, 2012. 详细描述了 Hystrix 用信号量保护 fallback、避免”不受信任的 fallback”拖垮调用线程的设计动机，是本篇第 2.4 节的核心引用来源。
• Netflix/Hystrix, “How it Works”, GitHub Wiki, github.com/Netflix/Hystrix/wiki. 明确要求 fallback 应返回无网络依赖的静态或内存响应，是本篇第 2.4 节 Resilience4j 示例设计的直接依据。

开源项目文档

• Apollo / Nacos 官方文档. 配置中心的长连接推送机制，是本篇第 5.3 节降级开关生效延迟讨论的实现参考，具体架构对比见站内《配置管理架构》。

系列内参考

• 《弹性设计模式：熔断器、舱壁与超时》——熔断器打开后的 fallback，是本篇降级目录的直接消费方。
• 《限流与过载保护：保命的最后一道防线》——负载脱落与功能降级的边界与协同。
• 《SLO 工程：可靠性的量化管理》——错误预算燃烧率作为降级触发信号的量化依据。
• 《混沌工程：主动验证系统的韧性》——Game Day 演练验证降级路径是否真的可用。
• 《特性开关架构：安全发布与实验的工程实践》——降级开关作为运维开关（Ops Toggle）的生命周期管理。
• 《配置管理架构：从配置文件到配置中心》——降级开关的推送机制与配置中心可靠性设计。
• 《幂等性设计：分布式环境下的安全重试》——只读模式下写请求排队重放的幂等性前提。