全量发布十分钟，回滚一小时
一次大版本全量发布，二十个实例十分钟滚完；上线七分钟后告警响了，回滚再花一小时——因为新版本已经处理了四十万笔请求，还带出了一批脏数据。发布的风险不在发布动作本身，在爆炸半径：多少流量、多长时间、能不能快速退。三种发布策略，本质上是在爆炸半径与资源成本之间做交换。
滚动发布：默认选项
逐批替换实例：先滚一台，观察，再滚其余——K8s 的默认 Deployment 更新就是滚动。优点是资源省、流程顺；代价是新旧版本共存的窗口：发布期间一半实例是旧版，所有接口、消息、配置都必须两版兼容。滚动是默认选择，但它的前提是兼容性纪律——没有向下兼容的约束，滚动发布就是薛定谔的版本混跑。
蓝绿发布：换的是切流速度
两套完整环境（蓝=线上，绿=新版），验证绿环境后网关一键切流，出问题一键切回——回滚从分钟级变成秒级。代价是资源翻倍，以及切流瞬间的新旧硬切换：进行中的长请求会跨版本。蓝绿适合需要快速回退保障的重大版本，日常迭代用不着这么重。
金丝雀：小流量试错
金丝雀是滚动与灰度的合体：新版本先接 5% 流量，盯错误率与 P99，正常则 25%、50%、100% 逐级放量，任何一级异常立即回滚——用最小的爆炸半径换取提前发现问题。实现上就是上两篇的组合：注册中心元数据分组 + 网关灰度路由 + 全链路标签透传。金丝雀阶段观察的三个信号：错误率不高于基线、P99 无劣化、核心业务指标（转化率、支付成功率）不异动。
// 发布检查单（示例）
1. DB 变更先行：只加不改不删，旧代码在新表结构下可运行
2. API 兼容：新字段可忽略，旧字段不清空不改变语义
3. 消息兼容：消费方容忍未知字段与乱序窗口
4. 灰度批次：1 台 -> 观察 10 分钟 -> 25% -> 100%
5. 回滚预演：回滚脚本在预发跑过一遍，数据补偿预案在手
6. 窗口：避开业务高峰与下游的发布时段检查单里最重要的一条：DB 先行
代码回滚容易，数据回滚难——所以表结构变更必须遵守扩展-收缩：第一阶段只加列不加约束，旧代码照常跑；第二阶段应用发布用新列；第三阶段观察稳定后再收缩（加 NOT NULL、删旧列）。每一步独立可回退，任何时刻发布与回滚都成立。凡是把改表和发版捆在一次变更里的，最后都在凌晨三点数据回滚现场见过。
发布策略解决"怎么安全地上线"，还有一类问题藏在更底层——服务间通信的基础设施本身。下一篇聊聊服务网格：Sidecar 到底解决了什么。
评论 (0)