每次发版都抖三抖？无损发布三种方案对比

很多团队的发版流程是这样的：挑半夜用户少的时候，停机、部署、启动、祈祷，发版窗口期用户看到"系统维护中"。版本一发就出问题的话，整个团队半夜回滚，第二天顶着黑眼圈复盘。

核心矛盾是：发版是高频动作，停机是业务不可承受之痛，而"不停机"三个字背后，是一整套流量调度和状态管理的功夫。 业界有三条主流路线：滚动发布、蓝绿发布、金丝雀发布，资源成本和风险控制各不相同。

方案一：滚动发布

原理： 逐个或分批替换实例：摘一个旧实例，启一个新实例，健康检查通过后接入流量，再处理下一个。全程服务不中断，新旧版本短暂共存。

优点：

• 资源零额外开销：不需要双倍环境，几台机器就能玩
• 流程简单：Kubernetes 默认策略就是滚动更新，声明一下就有
• 发版过程全自动，配合就绪探针基本无人值守

缺点：

• 新旧版本混跑期请求随机分配，接口不兼容会直接报错给用户
• 出问题回滚也是滚动的，回滚期间故障仍在持续
• 无法精确控制流量比例，验证新版本的样本不可控

适用场景： 接口兼容性有保障（只加不改）、实例数量多的无状态服务。兼容性纪律好的团队，这是性价比最高的默认选项。

方案二：蓝绿发布

原理： 维护两套完整环境：蓝环境跑旧版本对外服务，绿环境部署新版本。绿环境验证通过后，负载均衡一次性把流量全部切到绿，蓝环境保留观察，出问题秒级切回。

优点：

• 切换是原子的：所有用户同时进入新版本，没有混跑期
• 回滚最快：切回流量就是回滚，几秒钟的事
• 新版本可在绿环境做完整预生产验证，放量前心里有底

缺点：

• 资源翻倍：两套完整环境，机器成本直接乘二
• 数据库是软肋：新旧版本共用数据库，表结构变更必须向前兼容，否则蓝绿解决不了数据层问题
• 全量切换意味着全量风险：验证没覆盖到的问题，一切换就是全员事故

适用场景： 核心交易类系统，对"切换瞬间行为一致"要求高的场景。前提是数据库变更纪律严格——表结构只增不改、字段废弃分两步走。

方案三：金丝雀发布（灰度发布）

原理： 新版本先部署少量实例，按权重或规则导入小比例流量（1% 的用户、内部员工、某个地区），观察指标正常后逐步放大比例，直到全量。出问题只影响小比例用户，立即摘流止损。

优点：

• 风险最小化：问题暴露在 1% 的流量里，爆炸半径可控
• 真实流量验证：监控指标、业务转化率都能拿到真实反馈
• 回滚成本极低：摘掉金丝雀实例即可

缺点：

• 链路最复杂：流量按比例分配需要服务网格或网关支持（Istio、APISIX 等）
• 新旧版本长时间共存，兼容性要求贯穿整个灰度周期
• 观察周期拉长：一个版本可能要灰度几天，发版节奏变慢

适用场景： 用户量大、故障影响面广的互联网业务，以及对新功能效果没把握需要数据验证的场景。大厂标配，但中小团队引入前要掂量服务网格的运维成本。

按系统重要度对号入座

实战中常见组合：普通服务滚动发布，核心服务金丝雀，重大版本蓝绿兜底。发布策略按服务分级，而不是一刀切。

落地前必做的三件事

第一件：优雅下线比上线更重要。 实例下线时，在途请求要处理完、注册中心要先摘流、长连接要优雅关闭，否则每次发版都伴随一小撮 500 错误。很多企业监控里"说不清来源的零星报错"，根源就在粗暴下线。

第二件：数据库变更和代码发布解耦。 表结构变更必须先发兼容版本（新旧代码都能用），再发代码版本，最后清理旧字段。"代码和表结构一起上"是无损发布翻车的头号原因。

第三件：发版要有准入指标。 错误率、响应时间、核心业务转化，金丝雀放量的每个台阶都要有明确的通过标准和自动熔断。靠人肉盯盘决定是否继续放量，迟早盯漏一次。

写在最后

无损发布的核心不是"不停机"，而是"让发版从赌博变成工程"：流量可控、风险可限、回滚可秒。方案选型跟着系统重要度和团队成熟度走，但优雅下线、数据库解耦、准入指标这三件事，是所有方案的共同地基。