中 进阶
蓝绿与金丝雀发布#
一句话答案#
蓝绿部署两套环境瞬间切流量（回滚快但资源翻倍），金丝雀逐步放量（1%→10%→100%，风险可控）。
核心要点
| 策略 | 原理 | 优点 | 缺点 |
|---|---|---|---|
| 蓝绿 | 新旧两套同时运行，切换流量 | 回滚秒级 | 资源翻倍 |
| 金丝雀 | 1%→10%→50%→100% 逐步放量 | 风险可控 | 过程较长 |
| 滚动更新 | 逐批替换旧 Pod | 节省资源 | 回滚较慢 |
K8s 回滚： kubectl rollout undo deployment/app
面试回答（2分钟版）
发布策略主要有三种，各有适用场景。蓝绿部署是同时维护两套完全相同的环境（蓝和绿），新版本部署到空闲环境，验证通过后通过负载均衡器瞬间切换流量，回滚也是秒级切回，缺点是需要双倍资源。金丝雀发布是逐步放量的策略，先把1%的流量切到新版本观察，没问题就10%、50%、100%逐步扩大，这样即使新版有bug影响面也很小，缺点是整个发布过程比较长。K8s默认的滚动更新是逐批替换旧Pod，通过maxSurge和maxUnavailable控制节奏，不需要额外资源但回滚相对慢。实际生产中我们用的是金丝雀发布居多，配合Prometheus监控新版本的错误率和延迟指标，如果指标异常自动回滚。K8s回滚命令是kubectl rollout undo deployment/app，会回到上一个版本。
追问与易错
追问方向：
- “金丝雀发布怎么判断是否该全量？”→ 观察核心指标（P99 延迟、错误率、业务转化率）至少 15 分钟无劣化，且覆盖高峰流量时段；可设自动化门禁，指标异常自动回滚
- “蓝绿发布资源翻倍成本怎么优化？”→ 蓝绿环境可以用弹性伸缩，旧环境切走流量后快速缩容释放资源；或者用 K8s 的滚动更新替代纯蓝绿，减少同时运行的副本数
- “滚动更新过程中新旧版本共存怎么办？”→ 接口必须向前兼容（新版本能处理旧请求、旧版本能处理新请求），数据库 Schema 变更也要兼容；通过 maxSurge 和 maxUnavailable 控制新旧共存窗口大小
易错点：
- ❌ 只知道概念不知道原理——面试官会追问底层实现
- ❌ 缺乏实际使用经验——结合项目场景回答更有说服力