渐进式交付

概述 凌晨 2 点，某出行平台的支付服务做蓝绿切换。运维执行 kubectl rollout 切换 Service selector，流量从蓝色环境切到绿色环境。看起来一切正常——Pod 就绪、健康检查通过、响应延迟正常。 3 分钟后，DBA 群炸了。数据库连接数从 200 飙到 1200，连接池被打满，下游 5 个服务全部超时。原因是绿色环境的应用版本更新了 ORM 框架，连接池默认配置从 20 改成了 100，而蓝绿两套环境同时存在时，总连接数直接翻了一倍。 蓝绿部署和金丝雀发布，概念上很简单——准备两套环境切流量，或者先放一小部分流量验证。但生产环境落地的坑远比"切个流量"复杂得多。数据库 schema 怎么兼容？两套环境并存时资源怎么算？流量切换的粒度怎么控制？回滚怎么自动化？ 这篇文章拆解蓝绿与金丝雀发布在生产环境落地的 6 个关键决策，每个决策都来自实际项目中的踩坑或权衡。涉及 K8s 原生 Deployment 的局限性、Argo Rollouts 的渐进式交付架构、Istio 流量治理、数据库迁移兼容策略、自动回滚门禁设计等内容。配置示例全部可复制运行。 决策一：为什么 K8s 原生 Deployment 不够用 滚动更新的三个硬伤 Kubernetes 原生 Deployment 用 RollingUpdate 策略做发布，原理是逐步用新 Pod 替换旧 Pod。对很多场景够用，但生产环境有几个硬伤： 1. 无法控制流量比例。 RollingUpdate 按 Pod 数量做替换，不是按流量比例。假设 10 个副本，maxSurge=1，maxUnavailable=0，那发布过程中新旧 Pod 比例是 1:9、2:8…10:0。但你没法说"只给新版本 5% 的流量"——所有请求随机打到新 Pod，5% 流量意味着 1 个新 Pod 承接 10 个副本中随机的请求。这对支付类业务是致命的：你不知道哪个用户的请求会打到新版本。...

概述 凌晨 2 点 47 分，告警群炸了。一个支付服务新版本上线后 P99 延迟从 80ms 飙到 1200ms，值班同事第一时间按下回滚按钮。kubectl rollout undo 执行成功，旧版本 Pod 重新拉起，流量切回去。结果呢？服务彻底不可用了——因为新版本上线时跑了一个数据库迁移脚本，把订单表的 status 字段从 varchar(20) 改成了 tinyint，回滚后的旧代码根本不认识新的字段类型。 这不是杜撰。这是我在某出行项目亲历的一次故障。那次事故的 MTTR（平均恢复时间）是 1 小时 23 分钟，其中回滚操作本身只花了 47 秒，但回滚后服务不可用导致的排查时间占了 1 小时 22 分钟。 回滚不是银弹。设计不当的自动回滚比不回滚还危险——它会让你在已经出问题的窗口期再做一次变更，把"半挂"变成"全挂"。 这篇文章拆解 CI/CD 自动回滚体系的 5 层架构，给出 4 个生产级踩坑实录。不讲"什么是回滚"这种入门概念，直接上架构决策和工程权衡。如果你正在设计 CI/CD 回滚机制，或者被"回滚失败"坑过，这篇应该能帮到你。 为什么 90% 的回滚设计都是残缺的 先说一个反直觉的数据。微软对 Microsoft Teams 的 152 起生产事故做了系统研究（来源），发现超过 90% 的事故最终通过"不改代码"的方式缓解——回滚、配置变更、重启服务。但有意思的是，接近一半的事故在"缓解"阶段被延迟了，原因不是技术问题，而是"回滚决策不明确"和"修复部署太慢"。 换句话说，大多数团队不是没有回滚，而是回滚设计是残缺的。残缺在哪？看这张表： 回滚层次 常见做法 缺什么 后果 代码回滚 kubectl rollout undo 只回滚了镜像，没回滚配置 旧代码读新配置，启动失败 配置回滚 手动改 ConfigMap 没和代码版本绑定 配置漂移，下次部署带错误配置上线 数据回滚 不回滚 数据库迁移不可逆 旧代码连不上新 schema，全挂 流量回滚 切回旧版本 没考虑缓存和会话状态 用户请求打到旧版本但 session 数据在新版本里 回滚验证 不验证 回滚了就算完事 回滚本身引入新故障，无人发现 这五层里，漏掉任何一层，你的回滚机制就是残缺的。我见过太多团队，CI/CD 流水线里加了一个 kubectl rollout undo 就觉得自己有自动回滚了。实际上那只是"镜像回滚"，不是"服务回滚"。...