蓝绿部署与金丝雀发布：零停机的两种策略

发布是每个后端团队绕不开的日常——但「发布 = 停机维护」的时代早已过去。蓝绿部署（Blue-Green Deployment）与金丝雀发布（Canary Release）是两种零停机发布策略：前者一次性切换全部流量到新版本（快但风险集中），后者逐步将少量流量导向新版本（慢但风险可控）。两者不是互斥的——大厂通常将金丝雀作为蓝绿的增强——本篇讲清两种策略的机制、适用场景与实施要点。

蓝绿部署：两套环境一次性切换

蓝绿部署的机制：维护两套完全相同的生产环境——蓝环境（当前线上版本）与绿环境（新版本）。发布流程：① 在绿环境部署新版本；② 在绿环境做预发验证（冒烟测试）；③ 将流量从蓝环境一次性切换到绿环境（通常是修改负载均衡器的后端指向）；④ 确认绿环境稳定后，蓝环境保留作为回滚目标。回滚极其简单——流量切回蓝环境，秒级完成。

蓝绿的优势：切换速度快（改一条路由规则）、回滚秒级、新版本在隔离环境验证（不影响线上）。蓝绿的代价：需要双倍的资源（两套完整的生产环境——服务器、数据库连接、缓存容量——成本翻倍）；数据库 Schema 变更的兼容性是新版本必须遵守的约束（新旧版本同时运行，Schema 变更必须向后兼容——不能在新版本中直接 DROP 旧版本还在使用的列）。适用场景：发布频率不高（天/周级）、资源充足、希望快速回滚的场景。

金丝雀发布：逐步放量，观察再推进

金丝雀发布的名字来自矿工的金丝雀：矿工带金丝雀下井，金丝雀对毒气敏感，它的异常是矿工的预警。金丝雀发布的机制：新版本部署后，先将少量流量（如 1%）导向新版本，观察指标（错误率、延迟、业务指标）——指标正常则逐步放量（1% → 5% → 25% → 50% → 100%）；指标异常则立即回滚。金丝雀的核心价值：将发布风险从「一次性全量」降为「逐步可控」——1% 流量的问题影响范围极小，回滚成本接近零。

金丝雀的关键要素有三条。流量分割：需要按比例精确分配流量的能力（nginx 的 weighted upstream、Kubernetes 的 Service + Deployment 权重、服务网格的流量镜像与权重路由）。指标监控：金丝雀的核心不是「放流量」而是「观察指标」——错误率、P99 延迟、CPU/内存、业务指标（转化率、下单量）——自动化的指标对比（金丝雀 vs 基线）与自动回滚触发是金丝雀的智能层（手动盯监控的团队通常做不到 7×24 的金丝雀监控）。渐进式自动化：指标正常 → 自动推进到下一阶段 → 异常 → 自动回滚——Argo Rollouts 与 Flagger 是 Kubernetes 上的自动化金丝雀工具。

蓝绿 vs 金丝雀：选型与组合

对比表：

两者不是互斥的，可以组合：先做金丝雀（1% → 25% 验证），确认稳定后做一次蓝绿切换（剩余流量一次性切换）——结合了金丝雀的风险控制与蓝绿的切换效率。对 Kubernetes 用户：金丝雀是更自然的选择（Deployment 的滚动更新天然是金丝雀的简化版——逐 Pod 替换；配合 Argo Rollouts 可以实现精确的流量权重控制），蓝绿需要额外的 Service 切换机制（如两个 Deployment + 一个切换用的 Service）。

金丝雀的指标监控：自动化回滚的触发条件

金丝雀发布的核心不是放流量而是监控指标——指标异常时自动回滚比人工判断更快更准确。需要监控的四类指标：错误率（新版本的 5xx 错误率与基线版本的对比——超过基线的 2 倍则回滚）、延迟（P99 延迟与基线版本的对比——超过基线的 1.5 倍则回滚）、业务指标（转化率、下单量、支付成功率——下降超过 10% 则回滚）、系统指标（CPU、内存、连接池——超过容量的 80% 则告警）。自动化回滚的实现：Argo Rollouts 或 Flagger 在 Kubernetes 上实现自动化的金丝雀分析与回滚——每一步放量后自动分析指标，指标异常自动回滚到上一版本。金丝雀的核心不是发布工具，是「指标基线」的定义——知道什么是「正常」，才能识别什么是「异常」；基线的建立需要历史数据的积累（至少一周的稳定运行数据）。

蓝绿部署的数据库 Schema 兼容策略

蓝绿部署最大的隐藏挑战是数据库 Schema 变更的兼容性——新旧版本同时运行意味着新旧两套代码同时访问同一个数据库。Schema 兼容的策略分三步走。第一步：只添加不删除——新增列或新表是安全的（旧版本不使用新列不受影响），不能直接删除旧版本还在使用的列。第二步：分两次发布完成破坏性变更——第一次发布只添加新列（双写：新旧列同时写入），确认新版本稳定运行一段时间后第二次发布才删除旧列。第三步：使用数据库迁移工具（Flyway 或 Liquibase）管理 Schema 变更的版本——每次 Schema 变更都是一个有版本号的迁移脚本，确保变更的顺序性与可追溯性。Schema 兼容的黄金法则：新代码必须能在旧 Schema 上运行，旧代码必须能在新 Schema 上运行——两次发布才能完成一次破坏性的 Schema 变更。

金丝雀的指标监控与自动回滚

金丝雀发布的核心不是放流量而是监控指标。需要监控的四类指标：错误率（新版本的 5xx 错误率与基线版本的对比——超过基线的 2 倍则回滚）、延迟（P99 延迟与基线版本的对比——超过基线的 1.5 倍则回滚）、业务指标（转化率下单量支付成功率——下降超过 10% 则回滚）、系统指标（CPU 内存连接池——超过容量的 80% 则告警）。自动化回滚的实现：Argo Rollouts 或 Flagger 在 Kubernetes 上实现自动化的金丝雀分析与回滚。金丝雀的核心不是发布工具是指标基线的定义。

蓝绿部署的 Schema 兼容与金丝雀的指标监控

蓝绿部署最大的隐藏挑战是数据库 Schema 变更的兼容性。Schema 兼容的策略分三步走。第一步只添加不删除新增列或新表是安全的。第二步分两次发布完成破坏性变更第一次发布只添加新列双写确认新版本稳定运行一段时间后第二次发布才删除旧列。第三步使用数据库迁移工具管理 Schema 变更的版本。金丝雀发布的核心不是放流量而是监控指标。需要监控的四类指标错误率延迟业务指标系统指标。自动化回滚的实现 Argo Rollouts 或 Flagger 在 Kubernetes 上实现自动化的金丝雀分析与回滚。

蓝绿部署与金丝雀的「Schema 兼容」三步法

蓝绿部署与金丝雀发布的数据库 Schema 变更需要遵循向后兼容的三步法。第一步：只添加不删除——新增列或新表是安全的（旧版本不使用新列不受影响）；添加列时使用 NULL 或 DEFAULT 值（避免 NOT NULL 约束导致旧代码写入失败）。第二步：双写过渡——新版本同时写入新旧两列（旧列保持数据最新），确认新版本稳定运行一段时间后第二次发布才切换读取到新列并删除旧列。第三步：清理旧列——旧列删除前的确认：确认没有任何代码（包括定时任务、脚本、报表）还在使用旧列。三步法的核心思想：Schema 变更的每一步都必须是「向后兼容的」——新代码兼容旧数据，旧代码兼容新数据——两次发布完成一次破坏性的 Schema 变更。这个三步法与航空业的检查单文化同源——复杂系统的 Schema 变更需要清单而非记忆。

蓝绿部署的「数据库回滚」策略

蓝绿部署的数据库回滚是最大的难点之一：Schema 变更通常不可逆（DROP COLUMN 后数据丢失）。数据库回滚的策略有三种。策略一：只加不删——Schema 变更只添加列或表不删除任何列或表（数据回滚时旧列还在，旧代码可以正常运行）。策略二：双写过渡——新旧列同时写入一段时间确认新列数据完整后再切换读取到新列并删除旧列。策略三：备份恢复——发布前备份数据库（或使用数据库快照），回滚时恢复备份（代价是丢失发布期间的所有数据——只适用于可以接受数据回退的场景）。三种策略的选型取决于业务对数据丢失的容忍度与 Schema 变更的破坏程度。

小结

蓝绿与金丝雀收成四条：蓝绿一次性切流量——快但风险集中，需要双倍资源，回滚秒级；金丝雀逐步放量——慢但风险可控，增量资源即可，自动化指标监控是核心；Schema 变更必须向后兼容（新旧版本同时运行），这是所有零停机发布的共同约束；两者可以组合——金丝雀验证 + 蓝绿全量切换，兼得风险控制与效率。零停机发布的终极目标不是「不停机」，是「出了问题能秒级回滚」——回滚能力比发布能力更重要。

参考资料

• 本库前篇：《Kubernetes 架构设计与深入实践》《一篇读懂限流器》
• Argo Rollouts 官方文档 —— Kubernetes 上的金丝雀与蓝绿发布
• Martin Fowler, BlueGreenDeployment / CanaryRelease —— 两种策略的经典定义