什么是灰度发布、金丝雀部署以及蓝绿部署？
- 标签：发布、微服务、Spring Cloud、后端
🏛 业务架构师
这三种都是**"降低发布风险"的流量策略**，区别在于"新旧版本怎么共存、怎么放量"：
蓝绿部署（Blue-Green）：
- 两套完整环境：蓝（当前生产）+ 绿（新版本），流量一次性整体切换；
- 优点：切换快、回滚 = 切回去（秒级）；
- 缺点：双倍资源成本；切换瞬间 100% 流量进新版本，风险没有逐步验证；数据库结构变更要双向兼容。
金丝雀部署（Canary）：
- 名字来自矿工带金丝雀探毒气的典故——先放一小部分流量到新版本探路：5% 观察 → 25% → 50% → 100%，指标异常立刻回切；
- 优点：风险与放量同步、可控可回退；
- 缺点：发布过程长，需要完善的监控与自动回滚机制支撑。
灰度发布：
- 中文语境的广义概念，金丝雀是其典型实现；国内更强调按业务维度精准放量：内部员工先体验 → 白名单用户 → 某地域/某租户 → 按百分比全量；
- 实现载体：网关按用户 ID/Header/标签路由 + 注册中心元数据（版本标签）+ 负载均衡按权重。
架构师视角的实践要点：
- 选择依据是故障成本与资源预算：强合规低风险容忍 → 蓝绿（回滚最快）；互联网常态 → 金丝雀/灰度（成本与安全的平衡）；
- 灰度的关键是路由能力：网关层按标签精确路由 + 新旧接口兼容契约（灰度期间两版本并存，API 必须向后兼容）；
- 观测决定灰度的安全性：灰度期间的对比监控（新旧版本错误率/RT 并排看）+ 自动回滚阈值——没有观测的灰度是赌博，放量速度永远不能超过发现问题速度。
🏗 系统架构师
三种发布策略对比：
- 蓝绿部署：两套完整环境切流量，秒级回滚；代价是双倍资源，数据库共享时 schema 双向兼容是难点；
- 金丝雀：小比例真实流量验证（1% → 5% → 25% → 100%），指标异常即回退——本质是「用生产流量做受控测试」；国内说的灰度发布 ≈ 金丝雀加 feature flag 的渐进过程（按用户/地域维度放量）；
- 全量发布的护栏：新旧版本指标对比（错误率、RT、业务指标）加自动分批推进。
架构前提（比策略本身关键）：
- 流量路由能力：网关按 header/cookie/userId 精确路由（配合 Nacos 元数据路由或 Istio 权重切分）；
- 数据兼容：schema 演进走 expand-contract（先加列后删列），新旧版本共存期双向兼容——否则金丝雀写出脏数据；
- 可观测对比：指标按版本标签分列，自动判停与回滚；
- 无状态是前提——会话、缓存键里带版本的坑要提前排。
工具组合：K8s 加 Argo Rollouts 或 Istio 权重切流是我的标准答案。
💻 全栈开发专家
三种控制爆炸半径的发布策略：
- 蓝绿部署：两套完整环境（蓝=线上，绿=新版本），绿环境部署验证后整体切流（LB/网关一键切换）。回退秒级；代价双倍资源，数据库双写兼容是难点
- 金丝雀发布：新版先上 1 个实例接少量真实流量（如 1%），观察核心指标（错误率/RT/业务转化）无异常再逐步放量 5%→20%→100%。历史梗：矿工带金丝雀探毒气——小代价探风险
- 灰度发布：金丝雀的规则化版本——按维度放量：用户 ID 尾号、白名单、地区、内部账号、流量百分比。国内语境灰度 ≈ 金丝雀的渐进过程
工程实现（我们 K8s + Gateway 的做法）：Deployment 打版本标签（version: v2）→ 网关/Nacos metadata 路由按 header（X-Gray-Id 命中灰度名单）引流到 v2 → 观测分版本的错误率与 RT 对比（SkyWalking 版本维度）→ 异常自动回滚。
一条铁律：金丝雀观察期不能太短（至少覆盖一个业务高峰周期），我见过放量 5 分钟没看日志就 100%，慢 SQL 打挂库的事故。