金丝雀/AB/红绿发布

金丝雀/AB/红绿发布

1.金丝雀发布

按流量比例逐步放量,只能按流量,不按流量就不是金丝雀发布

  • 新版本先给 一小部分用户(比如 1%)

  • 观察是否出问题

  • 没问题 → 逐步扩大(10% → 50% → 100%)

特点

  • 风险最小(逐步试探)
  • 可以实时监控指标(错误率、延迟)
  • 需要流量控制能力(如网关/服务网格)
bash 复制代码
用户请求:
1% → 新版本
99% → 老版本

2. A/B 发布

按用户特征分组对比

  • 用户被分成两组(A组 / B组)

  • A → 老版本

  • B → 新版本

  • 对比效果(转化率、点击率等)

特点

  • 用于产品决策
  • 可以长期共存
  • 不一定是为了"安全发布"
  • 需要用户分流系统

适用:推荐系统、广告策略、UI改版

bash 复制代码
北京用户 → A版本
上海用户 → B版本

3.红绿发布

两套环境,瞬间切换

  • 蓝(Blue)= 当前生产版本

  • 绿(Green)= 新版本(完整部署好)

  • 切换流量:Blue → Green(一次性切)

特点

  • 回滚极快(切回去)

  • 发布简单粗暴

  • 资源成本高(两套环境)

  • 切换瞬间有风险

适用: 传统应用、对回滚要求极高的系统

复制代码
旧环境(Blue) → 全部流量
新环境(Green) → 准备好
切换 → 100% 到 Green
  • 金丝雀 : 一点点放量,看有没有毒
  • A/B :两种方案对比哪个好
  • 红绿 :直接切新版本,不行就切回去
维度 金丝雀发布 A/B 发布 红绿发布
目的 降风险上线 实验对比 快速切换
分流方式 流量比例 用户特征 全量切换
是否渐进 是 不一定 一次切换
回滚速度 中 慢 非常快
成本 中 中 高(双环境)

4.灰度发布

让一部分用户先用新版本,逐步扩大范围,而不是一次性全量上线

灰度发布 = 策略思想(大类)

金丝雀发布 = 灰度发布的一种实现方式

bah 复制代码
灰度发布(大类)
   ⬇
金丝雀发布(其中一种)
------------------------------------------------------
灰度发布
 ├── 金丝雀发布(按流量比例)
 ├── A/B 发布(按用户分组)
 └── 其他灰度策略(按地域、账号、版本等)
  1. 按流量比例(= 金丝雀) 1% → 10% → 50% → 100%
  2. 按用户特征(类似 A/B) 公司员工 → 新版本,普通用户 → 老版本
  3. 按实例(Pod)数量 2个跑新版本,8个老版本
  4. 按请求条件
相关推荐
pengdott2 天前
Rocky linux9安装最新版sonarqube-26.10.0
ci/cd·devops·sonarqube
lsc_blog4 天前
年底还在招的岗位,先确认缺口和到岗要求
git·缓存·ci/cd·职场和发展·github
AKA__Zas4 天前
接口自动化测试(1.0 初认识
python·ci/cd·学习方法
十二同学啊5 天前
Go 工程化详解:项目结构、代码规范、测试体系与 CI/CD 实践
ci/cd·golang·代码规范
Sakura_j_h_6 天前
GitHub Actions 打包 Windows exe:中文编码与产物上传
windows·ci/cd·打包发布·github·pyinstaller·github actions
砚底藏山河6 天前
量化回测可复现流水线CI化
java·python·ci/cd·金融
X1A0RAN6 天前
Jenkins CI 流水线优化实践:基于提交指纹的任务缓存
缓存·ci/cd·jenkins
长不大的杨瑞杰6 天前
OpenCode v2 GitLab 集成实战:Issue 驱动开发、MR 审查与 CI/CD 最小权限
人工智能·ci/cd·gitlab·ai编程·opencode
2501_915921439 天前
KXBuild CI 实操,Windows/Linux 服务器接入 Jenkins 打包 iOS IPA
服务器·windows·vscode·ios·ci/cd·个人开发·敏捷流程
蒸鱼Yuzheng11 天前
性能 CI 成本优化:设备分钟、风险分层与自适应测试选择
自动化测试·ci/cd·性能测试·测试平台·成本优化