蓝绿与金丝雀的自动化实现
书页微光
5 分钟阅读
蓝绿与金丝雀的自动化实现
零停机发布的关键不是“不停机”三个字，而是把流量切换和版本就绪解耦：先让新版本在旁边跑起来、验证了，再把用户切过去。蓝绿是二选一的整体切换，金丝雀是按比例逐步放量。两者都依赖一个能按权重或条件分流的入口，以及一套能自动判断“该不该继续”的度量。没有度量的切换只是赌博，放量越快死得越透。真正成熟的发布，不是“切过去了”，而是“切过去且能马上切回来、且过程中有人盯着指标”。
蓝绿：两套环境一份流量
蓝绿保留两套完全相同的部署，旧版（绿）继续接流量，新版（蓝）起好后切入口：
# 切换只改 Service 的 selector
apiVersion: v1
kind: Service
spec:
selector:
app: web
version: blue # 从 green 改成 blue 即完成切换
切过去后发现不对，把 selector 改回 green 就回滚，秒级、无重建。代价是要双倍资源扛两套，且数据库必须兼容两个版本同时读写。蓝绿适合“切换要快、回滚要稳”的场景，但对资源冗余要求高，小集群未必供得起，且双倍资源只在切换窗口短暂需要，平时是浪费。
金丝雀：先放一点点
金丝雀不替换全部，而是让一小部分请求走新版本，观察指标再逐步放大：
# 基于权重的分流示意
route:
- destination: web-stable
weight: 90
- destination: web-canary
weight: 10
从 10% 到 50% 再到 100%，每一步都看错误率、延迟、业务指标。经验上，放量节奏按“小步快看”来：先 5% 跑十分钟，再 20%、50%，最终全量。放量速度要匹配你发现问题的速度，发现得慢就放得慢，别被上线压力推着大步跨。新手常犯的错是一上来就 50%，等发现问题已经影响一半用户。
自动化要在哪几步介入
- 就绪校验：新版本 Pod 必须 passed 健康检查才进流量池。
- 指标门禁：错误率超阈值自动冻结放量甚至回滚。
- 渐进控制：用控制器管理权重步进，人只设目标比例与步长。
- 自动分析：对比新旧版本的延迟分位数、错误率、关键业务转化，异常即暂停。
- 自动回滚：连续多个采样窗口不达标，直接把流量切回稳定版，不等人反应。
# 自动金丝雀的典型流程（概念示意）
canary analyze --metric error-rate --threshold 1%
canary promote --step 20
数据库迁移是隐藏难点
无论蓝绿还是金丝雀，数据库通常只有一份。新版本若改了 schema，必须保证旧版本仍能跑（先加列不删列、双写兼容），否则切到新版本后旧版本回不来。发布顺序要“先兼容旧、再升级新、最终清理旧”：先部署能兼容新 schema 的旧代码，再上新版，确认稳定后再删旧字段。跳步直接导致回滚失败，这是发布事故里最高频的一类。
用特性开关配合
当无法靠流量比例隔离风险时，可在代码里加特性开关，先全量部署新代码但默认关新逻辑，按用户或比例打开。这样“部署”和“生效”分离，回滚只需关开关而非切流量。开关要设默认值且能远程调，避免开关本身成单点，也别让开关堆积成技术债，上线稳定后及时清理。
观测指标清单
做金丝雀不能只看“服务在不在”，至少要看这几类：
- 错误率：按版本拆分，新版本错误率是否显著高于旧版本。
- 延迟分位数：P50/P95/P99，平均值掩盖长尾。
- 饱和度：CPU、内存、连接池、队列深度。
- 业务指标：下单成功率、登录成功率等，技术指标正常不代表业务正常。
只看错误率漏掉长尾，只看延迟漏掉业务，要组合起来判断。
踩坑清单
- 蓝绿切换只改了入口却没确认新版本连得上数据库，切过去即刻雪崩。切换前新版本要独立跑通端到端。
- 金丝雀只看平均延迟，被长尾请求拖垮的少数用户没被代表。门禁要覆盖 P99 和错误率。
- 有状态服务做蓝绿要小心双写：两套同时写库可能引发冲突，需先确认兼容或只读切换。
- 回滚靠改 selector，但若新版本已改了数据库 schema 且不向后兼容，切回旧版也起不来。发布顺序要保证“先兼容旧、再升级新”。
- 权重分流依赖特定入口能力，普通 Service 做不到按比例，需要支持流量权重的网关或控制器。
- 自动化门禁阈值设太宽，问题放大到全量才触发，等于没保护。阈值要按业务可接受误差反推。
- 金丝雀期间新旧版本日志混在一起，定位问题要先按版本打标，否则分不清是谁出错、浪费排查时间。
- 回滚后没复盘为什么放量失败，下一次换个版本又踩同样的坑，发布能力没有积累。
选蓝绿还是金丝雀，看你能不能承受双倍资源、以及故障影响面愿不愿意被比例限制。两者都不是银弹，配套的监控、门禁和回滚纪律才是关键。
浏览 0
点赞 0
评论 0