面经策

如何设计一个灰度发布系统？如何控制流量逐步切换到新版本？ ​

  • 标签：后端、系统设计、场景题

🏛 业务架构师 ​

灰度发布系统设计，我先定业务目标：灰度是"用 1% 的流量风险，换取 99% 的安全"的发布风控机制——它要回答三个问题：放多少流量、放给谁、不对了怎么自动停下。这三个问题都是业务决策，平台只是执行者。

流量控制设计（怎么放）

1. 灰度维度（放给谁）

  • 百分比：随机 1% → 5% → 20% → 50% → 100%
  • 用户标签：白名单（内部员工先吃自己的狗粮）→ 城市/尾号（58 同城的同城灰度是经典）→ 全量
  • 流量标记透传：网关给请求打灰度标 → 沿调用链透传（RPC/MQ 透传机制）→ 每一跳都路由到对应版本——标记丢失 = 灰度混乱（A 的新版本调 B 的旧版本），这是灰度系统最大的工程难点

2. 渐进节奏（放多快） 默认档位 1% → 5% → 20% → 100%，每档观察期（如 30 分钟~2 小时）看核心指标；核心交易从 1% 起步走完全程至少一天，运营活动页可以激进（错了影响小、修复快）——灰度节奏 = 业务风险偏好。

3. 自动阻断（怎么停）

  • 指标基线对比：灰度组 vs 对照组的核心业务指标（支付成功率、错误率、RT P99）实时对比
  • 偏离阈值（如错误率 +50%）自动停止放量并告警，保留现场等人工决策——自动回滚要谨慎（回滚本身也可能是事故），我倾向"自动暂停 + 人工决策回滚"

配套基础设施

  • 版本路由：网关/服务发现按灰度标路由（元数据匹配）
  • 数据双写兼容：新版本上线前数据结构向后兼容（详见数据一致性题）
  • 全链路同一版本：A/B/C 服务联合灰度时的"泳道"机制

收尾：灰度平台的验收指标是**"发布事故率"**——它是工程质量的风向灯，也是团队"敢不敢周五发版"的底气。

🏗 系统架构师 ​

灰度发布系统的核心是流量打标 → 规则匹配 → 渐进放量 → 观测拦截的闭环，我分层设计。

1. 灰度维度设计（怎么切流量）

  • 按流量比例：新版本 1% → 5% → 20% → 50% → 100%，每档观察周期按业务峰值覆盖（至少一个高峰）
  • 按用户特征：白名单（内部员工先吃自己的狗粮）、用户 ID 尾号（1% 用户）、会员等级、地域（先小城市再一线）、新用户 vs 老用户
  • 按基础设施：K8s Pod 标签 + Service 权重、网关路由权重（APISIX/Nginx weighted）、注册中心元数据（Nacos 实例权重/集群标签）

2. 技术实现链路

text
发布平台创建灰度任务
  → 下发标记：部署新版本实例(带 version=canary 标签)
  → 下发规则：网关/注册中心按规则路由（比例 or 特征）
  → 流量染色：入口打灰度标(header: x-gray=1)
  → 全链路透传：灰度标经 RPC/MQ 传递，同一次请求始终路由到灰度实例（全链路灰度）
  → 观测对比：灰度 vs 基准的核心指标对比
  → 决策：放大 / 回滚

全链路灰度是重点：只网关层灰度会导致请求落到老版本下游（链路撕裂），必须流量染色 + 逻辑路由（各中间件按标签选实例，MQ 用灰度影子 topic 或消息过滤）。

3. 观测与自动化拦截（安全网）

  • 核心对比指标：错误率、P99 RT、业务转化率、资损类指标（退款率）灰度 vs 存量实时 diff
  • 自动熔断：灰度组错误率超基准 X% 自动切回 100% 老版本，人工只做事后分析
  • 数据库变更与灰度解耦（见 102 题），灰度期是逻辑灰度

4. 我的渐进节奏：内部 → 1%（观察 30 分钟~1 天）→ 10% → 50% → 100%，每步有明确的进入/回退判据（错误率、资损指标阈值），并预演过回滚动作（回滚速度要分钟级）。发布平台的职责就是把这套流程平台化、可审计、一键执行。

💻 全栈开发专家 ​

灰度发布的完整设计是流量染色 → 按规则路由 → 全链路隔离 → 指标守门 → 自动回滚。

流量染色与分流规则

  • 入口网关给请求打标：按 userId 尾号、白名单、百分比（1% → 10% → 50% → 100%）。
  • APISIX 用 traffic-split 插件按 header/权重分流；SCG 用自定义 GlobalFilter + WeightCalculatorRoutePredicate。

分流层次

yaml
# 网关层：按权重切流量到两个版本
traffic-split:
  rules:
    - matched: [ { http_header_uid_suffix: [ "0", "1" ] } ]  # 20% 用户
      upstream: order-service-v2
    - upstream: order-service-v1   # 默认

K8s 侧：v1/v2 两个 Deployment，Argo Rollouts / Flagger 声明式管理金丝雀步骤，自动按指标推进。

全链路灰度（难点，加分项）

单层灰度不够——订单服务到了 v2，它调用的库存还是 v1，版本混跑容易出诡异问题。做法是泳道：

  • 网关打的灰度标 X-Gray: 1 沿调用链透传（HTTP header + MQ 消息属性 + 线程上下文）。
  • 每个服务注册时带版本元数据，消费方按"同标优先"路由（Spring Cloud LoaderBalancer 过滤 metadata），灰度流量在灰度泳道里闭环。
  • 数据库不做物理隔离，靠 schema 兼容（下一题展开）。

守门与回滚

  • 核心指标对比看板：v1 vs v2 的错误率、P99 RT、下单成功率，自动分析（Argo Rollouts Analysis）不达标立即回滚——回滚预案要在发布前演练，回滚只是切流量，秒级。
  • 每个阶段设观察期（如 30 分钟），高峰期不推进。

实践节奏：内部员工 → 1% → 10% → 50% → 100%，每步都有明确的"通过标准"，而不是拍脑袋推进。发布是常态，出事才回滚，机制要让人觉得"回滚不丢人"。