系统架构 · 容错弹性与稳定性

场景 1 · 库存 RPC 挂 40 分钟, 下单链路只跌了 3% — gobreaker 三件套落地

下单服务强依赖库存 RPC, 库存一抖单量就归零。给库存调用包上熔断器: 错误率超阈值拉闸, 冷却后半开探测, 熔断期读本地缓存兜底。

// github.com/sony/gobreaker v1 (Go 1.21)
var invCB = gobreaker.NewCircuitBreaker(gobreaker.Settings{
    Name:        "inventory-rpc",
    MaxRequests: 3,                 // 半开放行的探测请求数
    Interval:    10 * time.Second,  // Closed 态错误率统计窗口
    Timeout:     30 * time.Second,  // Open → Half-Open 冷却时长
    ReadyToTrip: func(c gobreaker.Counts) bool { // 近 20 次错一半拉闸
        return c.Requests >= 20 && float64(c.TotalFailures)/
            float64(c.Requests) >= 0.5
    },
})
func stock(ctx context.Context, sku string) (int, error) {
    v, err := invCB.Execute(func() (interface{}, error) {
        return invClient.Get(ctx, sku)     // 受熔断保护的调用
    })
    if err != nil {                        // ErrOpenState: 熔断期快速失败
        return localCache.Get(sku), nil    // 关键: 读缓存旧值兜底, 不报错给用户
    }
    return v.(int), nil
}

库存彻底挂掉的 40 分钟里, 下单成功率只跌 3% — 熔断期全部走缓存旧值。

场景 2 · Java 团队不手写状态机 — Resilience4j 注解版熔断 + 舱壁 + 超时

Spring Boot 项目用 resilience4j 注解三行挂上三道保护; 熔断、舱壁、超时按实例名独立配置, 粒度到方法级。

// resilience4j-spring-boot 2.x (Spring Boot 2.7)
@CircuitBreaker(name = "inventory", fallbackMethod = "stockFallback")
@Bulkhead(name = "inventory", type = Bulkhead.Type.SEMAPHORE)
@TimeLimiter(name = "inventory")               // 需返回 CompletableFuture
public CompletableFuture<Stock> getStock(String sku) {
    return CompletableFuture.supplyAsync(() -> client.query(sku));
}
public CompletableFuture<Stock> stockFallback(String sku, CallNotPermittedException e) {
    return CompletableFuture.completedFuture(cache.get(sku)); // 熔断期兜底
}
// 关键: fallback 签名 = 原参数 + 末尾异常; Open 时抛 CallNotPermittedException

场景 3 · 503 风暴被重试放大三倍之后 — 指数退避 + Full Jitter 统一重试模板

计费服务偶发 503, 各处手写 for 循环重试, 风暴来时 QPS ×3。抽一个统一模板: 退避、抖动、错误白名单、上游预算四件事一次做对。

func Retry(ctx context.Context, op func() error) error {
    base := 100 * time.Millisecond
    for attempt := 0; attempt < 5; attempt++ {
        if err := op(); err == nil {
            return nil
        } else if !retryable(err) { // 400/401/404 不在白名单
            return err
        }
        d := base << attempt // 100ms → 200ms → 400ms → 800ms
        if d > 5*time.Second { d = 5 * time.Second } // cap 封顶
        d = time.Duration(rand.Int63n(int64(d))) // Full Jitter: [0,d) 均匀取
        select {
        case <-time.After(d):            // 关键: 抖动打散重试齐射
        case <-ctx.Done():
            return ctx.Err()             // 上游预算没了, 立刻收手
        }
    }
    return errors.New("retry budget exhausted")
}

全公司收敛到这一个模板后, 503 风暴期的下游放大系数从 3 降到 1.2。

场景 4 · 推荐接口熔断后白屏三天 — 降级读缓存兜底, 挂了 GMV 只掉 1%

推荐服务依赖 3 个下游, 任一抖动就熔断; 之前熔断直接抛错导致前端白屏。现在熔断期读"上次成功的榜单缓存", 并打降级标记。

func recommend(ctx context.Context, uid int64) []Ad {
    ads, err := recCB.Execute(func() (interface{}, error) {
        return recClient.ForUser(ctx, uid)
    })
    if err != nil {                        // 熔断打开或 RPC 失败
        if cached, ok := boardCache.Get(uid); ok {
            return markDegraded(cached)    // 关键: 旧榜单 + degraded 标记
        }
        return hotDefaultBoard             // 再兜一层: 全站热门榜
    }
    boardCache.Set(uid, ads, 24*time.Hour) // 成功结果顺手写兜底缓存
    return ads
}

场景 5 · 报表任务一夜拖挂支付回调 — 核心/非核心拆舱壁

两类业务共用 200 线程池, 报表导出占满后支付回调全部排队。拆成两个池: 核心独占配额, 非核心有界降速。

// 迁移前: static ExecutorService POOL = Executors.newFixedThreadPool(200);
// 报表一慢 → 200 线程全卡在导出 → 支付回调无线程可用, 全站支付超时
ExecutorService payPool = new ThreadPoolExecutor(
        32, 32, 0, TimeUnit.MILLISECONDS,
        new ArrayBlockingQueue<>(100),               // 有界队列
        new ThreadPoolExecutor.AbortPolicy());       // 打满立即拒绝
ExecutorService reportPool = new ThreadPoolExecutor(
        8, 8, 0, TimeUnit.MILLISECONDS,
        new ArrayBlockingQueue<>(200),
        new ThreadPoolExecutor.CallerRunsPolicy());  // 非核心: 降速不丢
// 关键: 核心池独占配额 + 有界队列, 非核心流量挤不进核心

场景 6 · 每月混沌演练日: Chaos Mesh 杀 30% 支付 pod + 对库存断网 3 分钟

降级代码写了没人信, 就用 Chaos Mesh 真刀真枪注入两类故障: 杀 pod 验证自愈, 断网验证熔断与降级, 演练报告直接当预案验收单。

apiVersion: chaos-mesh.org/v1alpha1
kind: PodChaos
metadata: { name: kill-pay-30 }
spec:
  action: pod-kill
  mode: fixed-percent
  value: "30"
  selector: { labelSelectors: { app: payment } }
  duration: 5m
---
# 演练二: 对库存服务双向断网, 验证熔断 30s 内打开并走兜底
apiVersion: chaos-mesh.org/v1alpha1
kind: NetworkChaos
spec:
  action: partition
  direction: both
  selector: { labelSelectors: { app: order } }
  target: { selector: { labelSelectors: { app: inventory } } }
  duration: 3m
# 关键: 演练验收指标 — 自愈 < 60s, 熔断打开率 100%

场景 7 · 凌晨 3 点 HikariPool 告警: 一个没配超时的下游拖死整个连接池

订单服务 DB 连接全部占用、pending 800+。排查发现不是 DB 慢, 是营销服务卡死而 HTTP 调用没设超时, Tomcat 200 线程全挂起, 每个线程还各押着一个连接。

$ kubectl logs order-svc-7d9f --since=10m | grep -c TimeoutException
12583
java.sql.SQLTransientConnectionException: HikariPool-1 - Connection is not
  available, request timed out after 30000ms.
  at com.zaxxer.hikari.pool.HikariPool.getConnection(HikariPool.java:196)
$ curl -o /dev/null -sw '%{time_total}\n' http://marketing-svc/health
30.012     # ← 营销服务不拒绝也不响应, 一挂就是 30s
# 根因: Feign 未配超时, Tomcat 200 线程全挂起, 每线程还各押一个连接
# 修复: 给下游客户端补超时并独立舱壁隔离
feign.client.config.marketing.connectTimeout=200
feign.client.config.marketing.readTimeout=800
# 关键: 没有超时的调用, 等于拿线程和连接给下游当人质

场景 8 · 三副本同宿主机被一锅端之后 — 拓扑打散 + 中断预算做实冗余

4 个副本曾被调度器排在一台宿主机上, 宿主机重启全站下单不可用。用拓扑分布约束强制跨区, 再配 PDB 保证检修时容量。

apiVersion: apps/v1
kind: Deployment
spec:
  replicas: 4                         # 3 干活 + 1 冗余
  template:
    spec:
      topologySpreadConstraints:
        - maxSkew: 1
          topologyKey: topology.kubernetes.io/zone
          whenUnsatisfiable: DoNotSchedule  # 关键: 强制跨可用区
          labelSelector: { matchLabels: { app: order } }
        - maxSkew: 1
          topologyKey: kubernetes.io/hostname
          whenUnsatisfiable: ScheduleAnyway   # 尽量打散宿主机
          labelSelector: { matchLabels: { app: order } }
---
apiVersion: policy/v1
kind: PodDisruptionBudget
spec:
  minAvailable: 3   # 关键: 驱逐/检修时永远保 3 副本在线
  selector: { matchLabels: { app: order } }

场景 9 · 下单接口 2s 总预算的分配表 — 压测校准, 每层递减留余量

网关给下单 2s 总预算, 按依赖树分家: 每层自留一份, 子预算之和必须小于父预算; 数值来自全链路压测, 写进代码并随容量复审。

// 压测校准后的预算表 (P99: 库存 180ms / 营销 90ms / 券 120ms)
// 网关 2.0s ─┬─ 订单落库 300ms
//           ├─ 库存 RPC 500ms   (P99×2 + 抖动余量)
//           ├─ 营销 RPC 300ms
//           └─ 券核销  400ms    (与库存并行, 取 max 不叠加)
ctx, cancel := context.WithTimeout(ctx, 500*time.Millisecond) // 库存预算
defer cancel()
stock, err := inventoryClient.Deduct(ctx, req)
if errors.Is(err, context.DeadlineExceeded) {
    metrics.TimeoutCounter.WithLabelValues("inventory").Inc()
    return preDeduct(req) // 关键: 预扣 + 异步补偿, 不拖死入口预算
}

场景 10 · 熔断器在开/半开间反复横跳 — 恢复探测的样本数与口径设计

半开只放 1 个请求, 探测接口 P99 抖一下就重新熔断, 兜底缓存越来越旧。改成 3 探测 + 连败计数拉闸 + 自定义"成功"口径, 一天只横跳 0 次。

gobreaker.Settings{
    Name:        "pay-gateway",
    MaxRequests: 3,                // 关键: 3 个探测, 单个偶发慢不翻盘
    Interval:    10 * time.Second,
    Timeout:     60 * time.Second, // 冷却给足, 防在开/半开间反复横跳
    ReadyToTrip: func(c gobreaker.Counts) bool {
        return c.ConsecutiveFailures >= 5   // 连败才拉闸, 忽略零星抖动
    },
    IsSuccessful: func(err error) bool {    // 定制"成功"口径
        return err == nil || errors.Is(err, ErrBizRejected)
    },  // 业务拒绝(库存不足)不是故障, 不计入熔断统计
}