发布系统：灰度发布（Gray Deployment）

一、什么是灰度发布？

灰度发布：

新版本不一次性全量上线，而是按规则逐步放量，让不同用户在一段时间内同时使用不同版本，在真实流量下验证稳定性。

一句话：

同一时间，多版本共存，逐步扩大影响面

二、灰度发布 vs 金丝雀发布（先厘清概念）

很多人把两者混用，但在工程语义上：

灰度发布：总称 / 思想 / 策略
金丝雀发布：最典型的一种灰度发布实现

关系：

灰度发布
 ├─ 金丝雀发布
 ├─ 分批灰度
 ├─ 白名单发布
 ├─ 功能开关灰度

三、灰度发布的核心目标

风险可控
可观察
可暂停
可回滚
支持真实用户验证

四、灰度发布的整体形态

用户请求
   │
┌──▼──────────────┐
│  流量控制层       |  <- 灰度规则
│  (LB / Gateway) │
└──┬──────────────┘
   │
┌──┴──────────┐   ┌──────────────┐
│ 稳定版本 v1  │    │ 灰度版本 v2  │
│   80%流量    |   │   20%流量    │
└─────────────┘   └──────────────┘

五、灰度发布的常见方式（重点）

1️⃣ 按流量比例灰度

1% -> 5% -> 10% -> 50% -> 100%
最常见

2️⃣ 按用户维度灰度

userId hash
手机号尾号
企业 / 账号级别

优点：

同一用户始终命中同一版本
用户体验稳定

3️⃣ 白名单灰度

内部员工
测试账号
特定客户

4️⃣ 按地域灰度

先某个城市
再某个区域
再全国

5️⃣ 按请求特征灰度

Header / Cookie
User-Agent
特定 API

6️⃣ 功能级灰度（Feature Toggle）

不换版本
开关新功能
随时开关

这是最细粒度的灰度

六、灰度发布的前置条件（非常重要）

1️⃣ 多版本可并存

向前兼容
接口稳定
数据库字段兼容

2️⃣ 流量可精细控制

Gateway / Ingress / Service Mesh
不能只靠 DNS

3️⃣ 监控 & 指标拆分

按版本
按灰度规则
与基线对比

七、灰度发布的实现位置（架构视角）

层级	灰度方式
DNS	不推荐（不可控）
LB / Ingress	常用
API Gateway	推荐
Service Mesh	高级
应用内部	Feature Toggle

八、灰度发布 vs 滚动 / 蓝绿 / 金丝雀

维度	灰度	金丝雀	蓝绿	滚动
是否多版本共存	✅	✅	❌	❌
是否真实用户	✅	✅	❌	❌
风险控制	高	极高	高	中
实现复杂度	中~高	高	中	低

九、灰度发布的常见坑（非常真实）

❌ 数据库不兼容
❌ 会话绑定本地
❌ 灰度规则不一致
❌ 指标不可区分
❌ 灰度时间过短
❌ 人工切流不可回滚

十、灰度发布最佳实践（重点）

✅ 先功能灰度，再版本灰度
✅ 灰度流量 ≤ 5% 起步
✅ 每一阶段观察 ≥ 15 分钟
✅ 灰度规则必须可回滚
✅ 指标必须和基线对比
✅ 灰度用户固定（一致性）
✅ 出现异常自动回退

十一、典型灰度发布流程（推荐）

Feature Toggle 开关关闭
部署新版本（不影响用户）
白名单用户开启功能
扩大灰度范围
全量开启
删除旧代码

十二、总结

灰度发布不是一种工具，而是一种风险控制思想。

金丝雀、蓝绿、滚动只是不同成熟度下的实现手段。