可靠性 — 一个下游抖动，不让它拖垮整条链路Reliability: Circuit Breaker, Retry/Backoff, Bulkhead & Graceful Degradation

问题场景 + 需求约束

设计一条电商下单链路：下单 QPS 5 万，p99 SLO 300ms，整体可用性目标 99.95%（年停机 ~4.4 小时）。下单要同步调用约 30 个下游依赖——库存、优惠券、风控、地址、支付预授权……其中只有库存和支付是核心，其余非核心。

真正要防的不是「某个服务挂了」，而是 级联故障（cascading failure）：优惠券服务一次 GC 停顿，响应从 20ms 涨到 5s。调用方同步等待，每个下单请求占着一个线程死等——几秒内线程池被占满，连根本不查优惠券的请求也排不进来。一个非核心依赖拖垮了整个下单。可靠性工程的核心命题就是：让局部故障止于局部。本期讲四件互补的武器：断路器、退避重试、舱壁、优雅降级。

• 故障模型：下游不是「全挂」，更多是「变慢」——慢比挂更危险，因为它悄悄耗尽你的线程/连接。
• 依赖分级：核心 vs 非核心。非核心依赖必须能被「跳过」，否则它的可用性就是你的可用性下限。
• 串联可用性：30 个依赖串联，每个 99.9%，整体 ≈ 99.9%³⁰ ≈ 97%。不做隔离，依赖越多越脆。
• 幂等性：决定了能不能安全重试（见 Day 7、Day 17）。

高层架构

每个下游调用都穿过一层 resilience 中间层：超时 → 舱壁（独立资源池）→ 断路器（统计错误率）→ 重试（带退避）。任何一环判定失败，立刻走 fallback（缓存值 / 默认值 / 跳过）而不是死等。入口处还有一道 负载保护（load shedding），过载时优先保住核心请求。

graph LR
    IN["下单请求"]
    LS{"负载保护
过载→shed"}
    ORD["下单服务
编排"]
    BH["舱壁
每依赖独立池"]
    CB{"断路器
open?"}
    DEP["下游依赖
优惠券/风控..."]
    FB["Fallback
缓存/默认/跳过"]

    IN --> LS -->|放行| ORD --> BH --> CB
    LS -.->|拒绝 429| IN
    CB -->|closed| DEP
    CB -.->|open→fail fast| FB
    DEP -.->|超时/错误| FB

    classDef in fill:#1a2530,stroke:#64c8ff,color:#e8eef5
    classDef gate fill:#2a1530,stroke:#ff7ab6,color:#e8eef5
    classDef core fill:#1a1a30,stroke:#ffb450,color:#e8eef5
    classDef dep fill:#0e2030,stroke:#5eead4,color:#e8eef5
    class IN in
    class LS,CB gate
    class ORD,BH core
    class DEP,FB dep

每个依赖被独立隔离；失败快速短路到 fallback，不让一个慢依赖耗尽全局资源

关键技术点

1. 断路器 Circuit Breaker — 给故障依赖「拉闸」

一句话 trade-off：用「对故障依赖的临时不可用」换「调用方快速失败、下游获得喘息」。

原理：电闸的隐喻。断路器是个三态机：Closed（正常放行，统计失败率）→ 失败率超阈值 → Open（直接拒绝，不再发请求，立刻走 fallback）→ 冷却一段时间 → Half-Open（放少量探测请求试水）→ 成功则回 Closed，失败则退回 Open。它把「等满超时再失败」（每次浪费几秒、还在给濒死的下游加压）变成「fail fast」，同时切断了持续打击，让下游有机会恢复。

# 断路器状态机 (pseudo-code)
def call(dep, req):
    if state == OPEN:
        if now() - opened_at > cooldown:   # 冷却到点
            state = HALF_OPEN               # 放一个探测
        else:
            return fallback(req)            # fail fast，不打下游
    try:
        resp = dep.invoke(req, timeout=200ms)
        on_success()                        # half-open 成功 → CLOSED
        return resp
    except (Timeout, ServerError):
        on_failure()                        # 窗口错误率超阈值 → OPEN
        return fallback(req)

2. 退避重试 Retry with Backoff + Jitter — 重试是把双刃剑

一句话 trade-off：用「重试带来的额外负载」换「吸收瞬时抖动」——但用错就是火上浇油。

原理：瞬时故障（网络抖动、leader 选举、偶发超时）重试一次往往就好。但 naive 立即重试是放大器：下游过载 → 大量请求失败 → 所有客户端同时重试 → 下游被双倍流量彻底打死，这就是 retry storm（重试风暴）。两个解药：① 指数退避（exponential backoff），每次失败等待翻倍（100ms→200ms→400ms），给下游恢复时间；② jitter（抖动），加随机让重试时刻错开，否则所有客户端会「对齐」成同步脉冲，周期性地一起砸过去。

# Full Jitter 指数退避 (AWS 推荐)
def retry(req, max_attempts=3):
    base, cap = 0.1, 2.0          # 100ms 起，封顶 2s
    for attempt in range(max_attempts):
        try:
            return call(req)       # 仅对幂等 + 可重试错误重试
        except Retryable:
            if attempt == max_attempts - 1: raise
            if not retry_budget.try_acquire(): raise  # 全局重试预算
            backoff = min(cap, base * 2 ** attempt)
            sleep(random.uniform(0, backoff))         # full jitter

3. 舱壁 Bulkhead — 把资源切成隔舱

一句话 trade-off：用「整体资源利用率下降」换「单依赖故障不耗尽全局资源」。

原理：源自造船——船体分成多个水密隔舱，一处进水不会沉船。映射到系统：不要让所有下游调用共用同一个线程池/连接池。给每个依赖分配独立配额（如优惠券最多占 20 个线程）。这样优惠券变慢，最多占满它自己那 20 个，核心的库存、支付调用仍有线程可用——故障被关在隔舱里。这正是开头那个雪崩场景的根治方案。

# 信号量舱壁：限制单依赖并发 (pseudo-code)
sem = {dep: Semaphore(limit[dep]) for dep in deps}   # 每依赖独立配额
def call(dep, req):
    if not sem[dep].try_acquire():      # 满了立即拒绝，不排队
        return fallback(req)            # 隔舱满 → 不波及其他依赖
    try:
        return dep.invoke(req, timeout=200ms)
    finally:
        sem[dep].release()

4. 优雅降级 + 负载保护 — 宁可残缺，不可全死

一句话 trade-off：用「功能完整性 / 结果精度」换「核心链路存活」。

原理：当依赖失败或系统过载，与其返回 500、与其全盘崩溃，不如返回一个降级响应：优惠券服务挂了就按原价下单（fallback 到默认值）；个性化推荐挂了就返回热门榜（fallback 到缓存/静态结果）。配套的是入口侧 load shedding（负载保护）：当系统接近过载，主动拒绝一部分请求（返回 429），保住剩余请求能正常完成——部分成功远好于全体超时。拒绝时按 criticality（请求优先级）取舍：先拒非核心、保核心下单。

扩展与优化

• 自适应并发限流：与其手调每个舱壁的固定大小，不如用类 TCP 拥塞控制的自适应算法（Netflix concurrency-limits），按延迟变化动态调并发上限。
• 对冲请求（hedged requests）：对幂等读，p95 没返回就并发发第二个请求、取先到的，显著压低长尾延迟（但要配重试预算防放大）。
• 全链路超时预算：入口分配总预算（如 300ms），逐层递减传递（deadline propagation），下游知道还剩多少时间，过期直接放弃。
• 混沌工程验证：这些防护写了不等于有效，要靠故障注入（注延迟、断依赖）主动验证断路器真能跳、fallback 真能兜（详见后续混沌工程篇）。
• 区域级 failover：单可用区/区域故障时，把流量切到健康区域，是比单机隔离更高层级的可靠性。

常见陷阱 + 面试追问

深入资源

• Amazon Builders' Library：Marc Brooker, Timeouts, retries, and backoff with jitter —— 超时/重试/退避的权威实践。
• Google《SRE Book》：Handling Overload 与 Addressing Cascading Failures —— load shedding、节流、级联故障的系统论述。
• Martin Fowler bliki：CircuitBreaker —— 断路器模式标准定义。
• Netflix：Hystrix Wiki，断路器 + 舱壁 + fallback 的工程实现细节。
• Michael Nygard《Release It!》（Pragmatic Bookshelf）：稳定性模式（Circuit Breaker / Bulkhead / Fail Fast / Shed Load）的原始出处。

深入思考（点击展开答案）