金丝雀发布是干什么的
先把少量流量导入新版本，对错误率、延迟与业务指标做对照观测，逐步放大比例；异常时停止放量并把流量切回旧版本，把影响面限制在子集用户内。名字来自矿工用金丝雀试毒气的做法。与蓝绿的区别：蓝绿是一次性整体切换、回滚靠切回整套旧环境；金丝雀是比例式逐步放量，观测周期更长、资源占用更小。工程上通常由网关、服务网格（如 Istio）或负载均衡层按权重或标签分流实现。放量决策必须有两个前提：可对照的观测指标与验证过的回切通道；没有指标对照的比例放量只是小范围全量。
基本信息
| 流量方式 | 按权重或用户标签导入子集 |
|---|---|
| 观测口径 | 新版本与基线并排对比错误率、延迟与业务指标 |
| 节奏 | 小步递增加每档停留观察 |
| 失败动作 | 停止放量并把流量切回旧版本 |
| 自动分析 | 指标阈值驱动自动晋级或中止，替代人工盯盘 |
| 前提 | 两版本共存期兼容同一份数据与外部依赖 |
典型使用场景
- 用户量大的核心服务：1% 流量即可获得足够样本快速判断稳定性。
- 高风险改动：支付、订单类变更先在小比例真实用户上验证业务指标。
- 低流量服务：比例观测样本不足时，改用内部用户或员工先行验证。
- 与功能开关组合：金丝雀管代码路径的稳定性，开关管功能对谁可见。
- 生产渐进放量：1% 到 5% 到 25% 到 100%，每档停留核对指标再继续。
- 实验文化团队：注意与 A/B 试验区分，金丝雀目标是稳定性对照而非业务效果评估。
- 基础设施变更：网关路由、消息中间件参数调整同样可按金丝雀思路小范围验证。
- 多团队协作发布：把流量比例写成跨团队共识语言，谁观察、谁有权放量写进流程。
Istio 权重金丝雀
Istio 权重金丝雀
apiVersion: networking.istio.io/v1
kind: VirtualService
metadata: {name: web}
spec:
hosts: [web.example.com]
http:
- route: # 按权重分流
- destination: {host: web, subset: v1}
weight: 90 # 稳定版本 90 百分比
- destination: {host: web, subset: v2}
weight: 10 # 金丝雀 10 百分比
# 放量顺序：内部用户 到 1 到 5 到 25 到 100 百分比
# 每档停留核对：错误率、延迟、业务指标、日志告警放量阶梯示例
| 阶段 | 流量 | 停留核对 |
|---|---|---|
| 内部验证 | 内部标记 | 功能与日志确认 |
| 初始放量 | 1% 到 5% | 错误率与延迟 |
| 扩大放量 | 25% 到 50% | 业务指标与容量 |
| 全量 | 100% | 收尾观察后下线旧版本 |
| 回切 | 回到旧版本全量 | 异常达阈值立即执行 |
低流量服务先按 QPS 估算样本量：每秒几个请求时 1% 权重几乎无观测价值，应改用内部用户先行。
金丝雀期间两版本共享有副作用的外部资源（缓存、队列、定时任务）会互相污染数据，必要时隔离资源或停用相关任务。
回切不等于数据回滚：金丝雀期间已写入的数据与已投递的消息不会自动撤销，涉及数据结构变更时要设计向前兼容与补偿。
金丝雀与功能开关分工：开关控制功能对谁可见，金丝雀控制请求发到哪个版本；组合使用能实现先放代码、再放功能的节奏。