发布系统：金丝雀发布（Canary Deployment）

一、什么是金丝雀发布？

金丝雀发布：

先将新版本只开放给极少量用户或流量，观察系统与业务指标；确认稳定后，再逐步扩大流量，最终全量发布。

一句话：

先小流量试毒，再逐步放量

名称来源：

矿井里的金丝雀——最早感知危险

二、金丝雀发布的核心目标

把风险控制在最小范围
在真实用户流量下验证
随时可暂停、可回滚
支持灰度、AB 实验

三、金丝雀发布整体架构

                 用户流量
                    │
             ┌──────▼───────┐
             │ LB / Gateway │
             └──────┬───────┘
                    │
         ┌──────────┴──────────┐
         │                     │
   稳定版本（v1）        金丝雀版本（v2）
      95% 流量                5% 流量

四、金丝雀发布的完整流程（标准版）

1️⃣ 部署金丝雀版本

新版本只部署少量实例
与正式版本并存
配置保持一致

2️⃣ 流量分配（关键）

常见方式：

按比例（1% / 5% / 10%）
按用户特征
userId hash
IP
地区
UA
按请求头
Header / Cookie
内部白名单

3️⃣ 监控 & 验证

重点指标：

错误率
延迟（P99）
成功率
业务指标（下单率、转化率）

4️⃣ 决策

正常 -> 扩大流量
异常 -> 立即回滚
不确定 -> 保持比例继续观察

5️⃣ 全量发布

流量逐步放大到 100%
下线旧版本

五、金丝雀发布的前置条件（非常重要）

1️⃣ 流量可控

必须能精确控制流量
LB / Ingress / API Gateway 支持权重或规则

2️⃣ 监控必须完善

实时监控
指标必须区分版本
延迟、错误率要有基线

3️⃣ 版本可并存

向前兼容
数据库字段不破坏旧版本

六、金丝雀发布的实现方式

1️⃣ 网关 / 负载均衡（最常见）

Nginx 权重
Ingress annotations
API Gateway 路由规则

2️⃣ Kubernetes + Service Mesh

Istio / Linkerd
精细流量治理
按请求级别控制

3️⃣ 应用内灰度

Feature Toggle
配置中心
动态开关

七、金丝雀发布 vs 蓝绿 vs 滚动

维度	金丝雀	蓝绿	滚动
风险	极低	低	中
回滚	快	秒级	较慢
成本	中	高	低
复杂度	高	中	低
是否灰度	✅	❌	❌

八、金丝雀发布的优点 & 缺点

✅ 优点

风险最低
最接近真实用户
支持业务实验
非常适合高并发系统

❌ 缺点

实现复杂
监控要求高
问题复现可能困难
测试周期较长

九、金丝雀发布的最佳实践（重点）

金丝雀流量 ≤ 5% 起步
每一阶段至少观察 10~30 分钟
指标必须与稳定版本对比
出现异常立即自动回滚
结合限流、熔断、降级
重要变更必须先金丝雀
与 Feature Toggle 搭配使用

十、什么时候最适合金丝雀发布？

用户规模巨大
新功能风险未知
性能改动明显
算法 / 推荐 / 策略变更
核心链路系统

十一、总结

金丝雀发布是风险控制的终极形态，是高成熟度系统的标志。