原生蓝绿两套完整环境流量一次性全部切换风险点一旦切过去全部用户都走到新版本故障爆炸半径是全站。蓝绿 灰度组合模式保留蓝、绿两套完整集群不直接一次性全量切流先给绿环境放小部分灰度流量验证没问题再逐步放大直到 100%异常则直接把流量切回蓝环境兼顾新版本完整环境隔离 灰度小流量验证 秒级整体回滚能力。一、基础概念回顾蓝绿部署 Blue‑Green蓝环境线上正在运行旧版本 V1承接全部业务流量绿环境独立一套同等规格集群部署新版本 V2初期0 流量传统蓝绿验证绿环境正常LB / 网关直接100% 流量切到绿故障直接切回蓝环境蓝环境保留作为下次发布的备用环境缺点瞬间全量切换如果新版本存在并发下隐藏 bug全站受影响。灰度金丝雀 Canary新旧版本同时接收流量按权重 / 用户 / Header 逐步放量先小流量验证慢慢扩到全量风险可控但没有完整独立的旧集群回滚需要缩容新版本实例。蓝绿 灰度组合生产高级模式核心两套完整集群做底座网关做灰度流量权重控制分阶段把流量从蓝集群导到绿集群而不是一刀切换。二、完整工作流程7 步现状蓝集群V1承载 100% 线上流量绿集群空闲。部署新版本在绿集群部署 V2内部接口测试、预热此时绿集群0 线上流量。开启灰度放量网关 / Ingress/SLB 配置流量策略例如95% 流量→蓝 (V1)5% 流量→绿 (V2)真实生产小流量进入新版本集群。支持按权重、用户 ID、请求 Header、地域做灰度规则。观测指标持续监控绿集群错误率、响应时间、GC、线程堆栈、慢 SQL、业务日志告警触发就终止发布。逐步放大流量无异常逐步调权重5% → 20% → 50% → 80% → 100%。全量切换100% 流量切至绿集群此时蓝集群不再接收流量但集群实例不销毁保留待命。收尾确认稳定运行一段时间后数小时1 天蓝集群部署下一个新版本变为下一轮的“绿环境”循环。故障回滚任意阶段发现绿集群异常网关直接把全部流量切回蓝集群V1 完整集群秒级恢复不需要重建实例、不需要回滚部署。三、架构实现方式1K8s 实现主流deploy‑blue标签version:blue运行 V1deploy‑green标签version:green运行 V2Service 不直接绑定版本依靠Ingress‑Nginx / Istio做流量权重分流把部分流量打向 green其余到 blue。Istio 示例逻辑虚拟服务配置权重virtualservice: route: - destination: {host: svc, subset: blue} weight: 90 - destination: {host: svc, subset: green} weight: 102传统虚拟机 / 物理机NginxSLB两套后端 upstreamupstream_blueV1、upstream_greenV2Nginxsplit_clients或者 SLB 的流量权重实现流量按比例分发两套集群。split_clients ${remote_addr} $canary { 5% upstream_green; * upstream_blue; }四、组合模式优势对比单纯蓝绿、单纯灰度风险比原生蓝绿小不是瞬间全站切新版本小流量先验证避免一次性全站故障。回滚能力强于普通灰度一旦出事直接切回完整蓝集群不需要删除 / 缩容 pod秒级整体回滚。普通灰度回滚需要关闭新版本实例。环境完全隔离新版本部署在独立绿集群部署、预热、内部测试完全不影响线上旧集群。支持精细化灰度可以按用户、Header 做定向流量不止简单百分比。五、缺点资源成本高必须维护两套完整集群资源几乎翻倍。普通灰度只需要少量新版本实例。数据库 Schema 必须向前兼容蓝、绿集群新旧版本同时读写 DB表结构变更必须兼容新旧代码否则报错。六、和普通灰度金丝雀对比对比项普通灰度 (金丝雀)蓝绿 灰度组合模式集群资源共享一套集群少量实例升级新版本两套完整独立集群资源翻倍流量切换逐步扩副本 / 调权重新旧实例混在同一集群两套集群之间做权重灰度分流回滚动作缩减新版本实例网关一键切回整套旧集群故障爆炸半径小但旧版本和新版本混部可控灰度保留完整旧环境兜底适用场景常规迭代、资源紧张重大版本、架构改造、核心交易系统七、关键风险点生产踩坑数据库兼容问题新旧版本同时访问 DB表结构变更必须向前兼容不能做破坏性变更否则蓝集群旧代码写数据绿集群读报错反之亦然。会话、缓存一致性如果本地缓存两套集群缓存独立需要关注会话、token、缓存逻辑。资源成本双倍 CPU / 内存、连接池大集群成本很高。监控两套集群蓝、绿两套都要采集指标、日志不能只看新版本。八、三种发布模式选型建议普通迭代资源有限→普通灰度金丝雀重大版本、架构重构、核心交易、想要秒级整体回滚→蓝绿 灰度组合模式简单小版本追求发布速度能接受瞬间切换风险→原生蓝绿发布直接一次性切 100% 流量九、故障处理操作绿集群出现异常直接把流量权重全部切回 blue不用删除 green 集群快速恢复业务。排查绿集群问题GC、线程 dump、堆 dump、日志修复后重新灰度发布。不解决完问题绝不把流量再切回绿集群。面试记忆点蓝绿 灰度 蓝绿的完整双集群底座 灰度的分阶段流量放量解决原生蓝绿“一次性全量切换风险大”的痛点。
原生蓝绿两套完整环境流量一次性全部切换风险点一旦切过去全部用户都走到新版本故障爆炸半径是全站。蓝绿 灰度组合模式保留蓝、绿两套完整集群不直接一次性全量切流先给绿环境放小部分灰度流量验证没问题再逐步放大直到 100%异常则直接把流量切回蓝环境兼顾新版本完整环境隔离 灰度小流量验证 秒级整体回滚能力。一、基础概念回顾蓝绿部署 Blue‑Green蓝环境线上正在运行旧版本 V1承接全部业务流量绿环境独立一套同等规格集群部署新版本 V2初期0 流量传统蓝绿验证绿环境正常LB / 网关直接100% 流量切到绿故障直接切回蓝环境蓝环境保留作为下次发布的备用环境缺点瞬间全量切换如果新版本存在并发下隐藏 bug全站受影响。灰度金丝雀 Canary新旧版本同时接收流量按权重 / 用户 / Header 逐步放量先小流量验证慢慢扩到全量风险可控但没有完整独立的旧集群回滚需要缩容新版本实例。蓝绿 灰度组合生产高级模式核心两套完整集群做底座网关做灰度流量权重控制分阶段把流量从蓝集群导到绿集群而不是一刀切换。二、完整工作流程7 步现状蓝集群V1承载 100% 线上流量绿集群空闲。部署新版本在绿集群部署 V2内部接口测试、预热此时绿集群0 线上流量。开启灰度放量网关 / Ingress/SLB 配置流量策略例如95% 流量→蓝 (V1)5% 流量→绿 (V2)真实生产小流量进入新版本集群。支持按权重、用户 ID、请求 Header、地域做灰度规则。观测指标持续监控绿集群错误率、响应时间、GC、线程堆栈、慢 SQL、业务日志告警触发就终止发布。逐步放大流量无异常逐步调权重5% → 20% → 50% → 80% → 100%。全量切换100% 流量切至绿集群此时蓝集群不再接收流量但集群实例不销毁保留待命。收尾确认稳定运行一段时间后数小时1 天蓝集群部署下一个新版本变为下一轮的“绿环境”循环。故障回滚任意阶段发现绿集群异常网关直接把全部流量切回蓝集群V1 完整集群秒级恢复不需要重建实例、不需要回滚部署。三、架构实现方式1K8s 实现主流deploy‑blue标签version:blue运行 V1deploy‑green标签version:green运行 V2Service 不直接绑定版本依靠Ingress‑Nginx / Istio做流量权重分流把部分流量打向 green其余到 blue。Istio 示例逻辑虚拟服务配置权重virtualservice: route: - destination: {host: svc, subset: blue} weight: 90 - destination: {host: svc, subset: green} weight: 102传统虚拟机 / 物理机NginxSLB两套后端 upstreamupstream_blueV1、upstream_greenV2Nginxsplit_clients或者 SLB 的流量权重实现流量按比例分发两套集群。split_clients ${remote_addr} $canary { 5% upstream_green; * upstream_blue; }四、组合模式优势对比单纯蓝绿、单纯灰度风险比原生蓝绿小不是瞬间全站切新版本小流量先验证避免一次性全站故障。回滚能力强于普通灰度一旦出事直接切回完整蓝集群不需要删除 / 缩容 pod秒级整体回滚。普通灰度回滚需要关闭新版本实例。环境完全隔离新版本部署在独立绿集群部署、预热、内部测试完全不影响线上旧集群。支持精细化灰度可以按用户、Header 做定向流量不止简单百分比。五、缺点资源成本高必须维护两套完整集群资源几乎翻倍。普通灰度只需要少量新版本实例。数据库 Schema 必须向前兼容蓝、绿集群新旧版本同时读写 DB表结构变更必须兼容新旧代码否则报错。六、和普通灰度金丝雀对比对比项普通灰度 (金丝雀)蓝绿 灰度组合模式集群资源共享一套集群少量实例升级新版本两套完整独立集群资源翻倍流量切换逐步扩副本 / 调权重新旧实例混在同一集群两套集群之间做权重灰度分流回滚动作缩减新版本实例网关一键切回整套旧集群故障爆炸半径小但旧版本和新版本混部可控灰度保留完整旧环境兜底适用场景常规迭代、资源紧张重大版本、架构改造、核心交易系统七、关键风险点生产踩坑数据库兼容问题新旧版本同时访问 DB表结构变更必须向前兼容不能做破坏性变更否则蓝集群旧代码写数据绿集群读报错反之亦然。会话、缓存一致性如果本地缓存两套集群缓存独立需要关注会话、token、缓存逻辑。资源成本双倍 CPU / 内存、连接池大集群成本很高。监控两套集群蓝、绿两套都要采集指标、日志不能只看新版本。八、三种发布模式选型建议普通迭代资源有限→普通灰度金丝雀重大版本、架构重构、核心交易、想要秒级整体回滚→蓝绿 灰度组合模式简单小版本追求发布速度能接受瞬间切换风险→原生蓝绿发布直接一次性切 100% 流量九、故障处理操作绿集群出现异常直接把流量权重全部切回 blue不用删除 green 集群快速恢复业务。排查绿集群问题GC、线程 dump、堆 dump、日志修复后重新灰度发布。不解决完问题绝不把流量再切回绿集群。面试记忆点蓝绿 灰度 蓝绿的完整双集群底座 灰度的分阶段流量放量解决原生蓝绿“一次性全量切换风险大”的痛点。
