刚开始做 MLOps 工程师时，我需要上线一个包含用于图像分类的机器学习模型的小型应用。第一次上线一切顺利。但当我更新模型后，噩梦开始了。首先，承载新模型的 Pod 因测试环境与生产环境存在差异而无法启动。此外，客户也无法工作，因为承载旧模型的 Pod 已被我这个无法启动的新 Pod 替换。这简直是一场灾难。最后我不得不手动回滚，并向该模型的用户道歉。
不过，我从中吸取了教训，转而采用蓝绿部署策略。这种 DevOps 方法可以在无停机、无需熬夜回滚的情况下无缝发布更新。
在本指南中，我将带您了解蓝绿部署在实践中的样子：如何搭建、权衡点有哪些、文档里没有的经验教训。无论您在构建 ML 服务、API，还是全栈应用，这种方法都能为团队提供发布新功能所需的“安全网”，让您更有信心地推进上线。
理解蓝绿部署 蓝绿部署听起来比实际复杂（至少对我而言，刚听说时觉得很难）。
它其实就是一种聪明的发布技巧：通过维护两个相同的生产环境并在其间切换流量，从而在不打扰用户的情况下发布新版本。
如果您遇到过应用在预发可用、到生产却崩溃的问题，那这项策略就很适合您！
核心架构与运行机制 基本思路是：维护两个相同的生产环境。一个称为 蓝（blue） ，另一个称为 绿（green） 。
蓝色环境是当前用户正在使用的。当您有新版本要发布时，先将其部署到绿色环境，进行测试；当您确信其工作正常，再将生产流量从蓝色切换到绿色。
这种策略带来的是零停机、没有“抱歉我们在更新”的提示。一切过渡都在幕后悄然完成，用户甚至不会察觉。
在实践中，“魔法”发生在负载均衡器上。您通过配置它在两个环境间路由流量，取决于部署状态。这样可以对流量进行精细控制，并让回滚变得像把流量切回蓝色环境一样简单。
这种策略解决了我在新 ML 模型上遭遇的“为什么在预发好好的”的问题。因为绿色环境同样是生产环境，您会在真实世界中进行测试，而不是等用户先用再发现问题。
下面是典型流程的快速概览：
将新版本部署到绿色环境。 运行集成测试和冒烟测试。 使用负载均衡器切换流量。 监控绿色环境是否有异常。 如果一切正常，降级或保留蓝色环境，以备回滚之需。
蓝绿部署阶段 1：新应用在绿色环境测试，流量仍指向蓝色（作者供图）。
蓝绿部署阶段 2：流量切换至绿色环境（作者供图）。
历史演进与行业采纳 蓝绿方法大约在 2005 年由 Daniel Terhorst‑North 和 Jez Humble 在 ThoughtWorks 内部命名并使用。随后在 2010 年由 Jez Humble 和 Dave Farley 的著作《持续交付》中记录并推广。
自那以后，从初创公司到如今的云原生巨头（如 Netflix），再到每天多次无痛部署的团队，都在广泛采用它。
云平台加速了这一转变。借助基础设施即代码、自扩缩组和像 Kubernetes 这样的容器编排工具，启用并维护“镜像”环境变得简单。
蓝绿部署甚至启发了其他发布模型，如金丝雀发布和功能开关。理解了蓝绿，也就为理解其他模型打下了基础。
DevOps 新手？从 DevOps 概念 课程开始吧。清晰实用的基础，帮助您在深入高级工作流之前理解核心策略。
蓝绿部署的关键收益 坦白说，我第一次听到蓝绿部署时，觉得维护两个生产环境完全不合理。但当我看到上线新 ML 模型变得容易，用户投诉和升级也明显减少时，我意识到这确实值得。
接下来几节，我将重点介绍蓝绿部署的优势。
近乎零停机 这是最显而易见的一点：没人希望停机。
通过蓝绿，您可以瞬时将流量从旧环境切到新环境，而无需经历服务降级。用户不会注意到切换——理应如此。
当您运行面向用户的 API、仪表盘，或无法容忍几分钟中断的 ML 流水线时，这将成为“游戏规则改变者”。
回滚简单 想象一下，您刚发布新版本，几分钟后就发现产生大量 500 错误。采用蓝绿部署，您只需把负载均衡切回蓝色环境，便可从容修复，无需仓促行事。
这种安全级别能让团队更自信地高频发布，不再有“运行着的系统别动”的心态。
安全的生产环境测试 您可以在生产环境测试而不让用户暴露于风险之下。这就是绿色环境的妙处。您可以在真实环境中进行压测、集成检查，甚至模拟用户行为，先于真实流量进入应用之前完成验证。
与传统预发不同，您是在同样的基础设施、配置等环境中运行测试。
这样测试结果更贴近真实情况。
支持 A/B 测试与分阶段发布 当您拥有两个相同的生产环境时，还能做更多。例如，您可以将 90% 流量路由到蓝色版本，10% 路由到绿色版本。
您还可以集成功能开关来控制功能何时上线。蓝绿部署可作为底层发布基础为其提供良好支撑。
如果想更深入了解渐进式交付，请查看 数据工程中的 CI/CD 。它概述了如何搭建支持 A/B 测试与渐进式发布的流水线。
更佳的用户体验与业务连续性 蓝绿部署有助于：
减少暴露给用户的错误。 当问题出现时，加快工程响应速度。 简化备份恢复。 如果您在部署关键的机器学习服务或大家每天依赖的内部数据工具，这些都有很大意义。
蓝绿部署的规划 在实施蓝绿部署之前，有必要先更深入地理解它。
下面从架构、成本考量和组织准备度三个方面拆解所需条件。
基础设施要求 您需要两个相同的生产环境。这意味着双倍的搭建与维护。
但先别为成本惊慌。它并不总是意味着双倍费用。借助云平台或 Kubernetes，您可以在需要时才为绿色环境启动资源，并在之后释放掉。
以下做法有助于搭建两个环境：
基础设施即代码 （如 Terraform），快速复制环境。 配置管理 ，防止配置漂移引发问题。 在 Kubernetes 中，为蓝绿使用不同的命名空间或不同的部署对象。 同时要注意，在本地自建环境中会更复杂，您需要确保：
负载均衡器足够可配置，能瞬时切换流量。 可以快速供应环境（也许通过虚拟化或容器）。 外部依赖（如数据库、API）已同步并相互隔离。 您可以参考 AWS、Azure 与 GCP 服务对比 ，以决定在您的平台上哪个最省力。
成本效益分析 质疑者总会指出维护两个生产环境的成本上升。确实，同时运行两个环境并非免费。不过，需要在第二个环境的额外成本与业务停机代价之间做取舍。
问问自己：
一次失败部署的平均影响（时间或金钱）是多少？ 为排障、回滚与解释故障要花多少小时？ 您多常在压力下发布，只希望它别出问题？ 这正是蓝绿的最大卖点：更少的中断，更快的迭代，更小的工程压力与倦怠。
优化成本的小技巧：
使用自动扩缩，根据测试负载为绿色环境定容量。 在绿色环境使用竞价实例或临时虚机。 在独立的 Kubernetes 命名空间运行绿色版本，切换后将其缩容到 0。 配置良好的 CI/CD 流水线甚至可以自动处理这些扩缩。
前置条件与组织准备度 这一点常被忽视，却至关重要。
即使有足够的基础设施和工具预算，若团队文化和系统没准备好，蓝绿部署也难以奏效。
您需要：
CI/CD 工作流： 能独立部署并测试绿色环境的流水线。 监控与可观测性： 在从蓝切到绿之前检查各项指标。 明确的回滚策略： 最好自动化，并且要反复演练。 跨职能协作一致性： 开发、运维、QA 与产品团队都应理解流程如何运作。 不确定团队现状？可以考虑 机器学习的 CI/CD 。该课程全面解析成熟部署体系的样貌及实现路径。
技术实现 到目前为止，我们讨论了为何要使用蓝绿部署。本节将展示如何实施。
我将拆解一个典型的蓝绿部署生命周期，重点讲解最具挑战的数据库处理。
您将了解该自动化什么、监控什么、哪些环节绝不能跳过。
标准部署生命周期 良好实现的蓝绿部署遵循明确的顺序。实际中通常如下所示：
准备绿色环境 ：启动与当前（蓝色）环境镜像的生产级环境，可在云端、本地或使用 Kubernetes 搭建。将新版本部署至绿色 ：CI/CD 流水线应在此构建并部署代码，理想情况下标记为当前候选发布。运行自动化测试 ：包括冒烟测试、集成检查，以及模拟用户行为的健康探针。用以确认绿色是否已为用户就绪。监控日志与指标 ：若仪表盘干净无告警，即可推进；否则修复问题后重新部署到绿色。将流量切到绿色 ：重新配置负载均衡，将全部流量路由到绿色服务器。停用蓝色 ：当您对绿色足够有信心，关闭蓝色，或保留为下次发布前的备份。让回滚步骤与上线一样快，保证团队成员能在一分钟内撤回一次部署。
这份 数据工程中的 CI/CD 指南非常适合用来搭建这些自动化阶段。
数据库同步策略 这部分很棘手。您的应用可以是无状态的，但数据库不是。
若这一环节处理不当，就无法轻松回滚，蓝绿部署的意义也就荡然无存。
以下是处理方式：
为向后兼容而设计 ：切换期间，用户可能仍会在几毫秒内打到蓝色环境。此时您的 Schema 需要同时适配两个应用版本。 不要立刻删除或重命名字段。 新增列/表，使用默认值。 在两个版本都支持改动前，避免硬性约束。 为迁移做版本化 ：Java 系统可用 Flyway 或 Liquibase，Python + SQLAlchemy 可用 Alembic。 处理会话状态 ：若应用使用内存会话存储，切换环境可能导致用户登出或功能异常。使用 Redis、Memcached 或共享数据库避免此问题。 切换后校验数据一致性 ：对关键数据进行自动化检查，确保一致性。 用户能正常登录吗？ 最近变更是否已保存？ 分析流水线是否仍能正确摄取数据？ 监控“缓慢漂移” ：有些变更不会报错、看似可用，但会引发微妙问题，如事件处理延迟或记录畸形。通过日志与可观测性尽早发现此类问题。 如果您对生产级 MLOps 感兴趣，我推荐课程 MLOps 部署与生命周期管理 。
与其他发布策略的对比分析 蓝绿常被用作其他发布策略的基础，在此之上衍生出应对不同问题的变体。
根据您的架构、发布频率和对复杂度的取舍，可以选择替代方案，或将几种方法混合使用。
我们来比较最常见的一对：蓝绿 vs. 金丝雀发布。
蓝绿与金丝雀发布 这两种策略常被混用，但目标不同。
蓝绿是完全切换的发布模型。将新版本部署到绿色，测试通过后，一次性把 100% 流量切过去。
金丝雀发布是渐进切换。新旧版本并行部署，先将少量流量（如 1%、10%、50%）逐步导向新版本，并在过程中监控潜在问题。
二者的关键差异：
特性
蓝绿
金丝雀
流量切换
一次性
渐进式
回滚
即时（切回蓝色）
部分或逐步回滚
风险暴露
若绿色故障，影响较大
较低（可早期发现问题）
基础设施需求
两个完整环境
可分流的路由层
发布可见性
干净、可控的切换
需要更复杂的可观测性
最适合
小团队、稳定应用
关键服务、大用户群
我个人在将新 ML 模型部署到生产时使用蓝绿，但用户规模也有限。若面向更大的用户群，我可能会更偏好金丝雀发布。
基础设施与运维权衡 两种策略都需要良好工具支撑，但复杂度体现在不同方面。
蓝绿需要相同环境，增加了基础设施成本；但路由很简单，只是在两个环境间切换流量。
金丝雀在基础设施成本上更轻，但需要更多逻辑来实现渐进式流量切换，同时需要更细致的可观测性以尽早捕获问题。
还需考虑的因素：
监控： 金丝雀需要更细粒度指标（如按用户或请求的延迟），而蓝绿只需判断应用是否健康。 自动化工具： 如 Argo Rollouts 在 Kubernetes 中同时支持两种模型，但金丝雀需要更多配置。 部署时间： 蓝绿更快；金丝雀更谨慎、耗时更长。 那么，哪种更适合您？
如果团队的 CI/CD 成熟度尚在提升，蓝绿可能是建立信心的最佳方式。蓝绿也是良好的起点，便于积累经验。
但若您拥有庞大的用户群，或发布变更风险较高（如定价逻辑），金丝雀会更合适。
对 Azure 生态专注的团队， Azure DevOps 教程 展示了如何在 Azure 上实现良好的 CI/CD。
平台特定实现 理论说得够多了，来点技术实操。我们看看数据团队日常使用的平台（如 Kubernetes、云托管服务与自动化工具）上，蓝绿部署如何落地。
各平台提供的功能不同，但核心思想不变：两个相同环境与一个流量开关。
Kubernetes 编排模式 在 Kubernetes 中实现蓝绿部署并不复杂，所需工具都已内建于 Kubernetes。
有几种搭建方式：
独立部署： 将 my-app-blue 与 my-app-green 作为两个独立的 Deployment，复用标签与 Service。 带版本修订的单一部署对象： 不常见，但可以通过注解跟踪版本实现。 命名空间： 在独立命名空间运行蓝绿，实现完全隔离。 关键组件是 Kubernetes Service。它充当负载均衡，通过标签选择器将流量导向蓝或绿 Pod。
比如，您有：
selector : version : blue技术支持 验证绿色版本后，将 service 的选择器更新为 version: green，流量便会立即切换。
我建议使用 readinessProbes，确保新版本在接收任何流量前已完全就绪。
这一过程可用 Argo Rollouts 与 Flagger 等工具自动化，它们可处理：
想更深入了解以 ML 为中心的基础设施？看看 全自动化 MLOps 。
云原生托管服务 如果您使用 AWS、Azure 或 GCP，好消息是蓝绿部署已内置支持，您只需开启并配置即可。
AWS CodeDeploy（配合 Elastic Beanstalk 或 EC2）：
提供专门的蓝绿部署策略 您定义哪个环境为绿色，CodeDeploy 负责流量切换与回滚 Azure Container Apps 或 Azure App Service：
Azure 通过“插槽（slot）”来分阶段版本，并可零停机交换 结合 Azure DevOps 流水线实现全量 CI/CD 自动化 Google Cloud（Cloud Run 或 GKE）：
Cloud Run 支持在修订版本间渐进式分流，非常适合测试与发布 在 GKE 中，可用负载均衡规则或 Istio 管理蓝绿逻辑 各云厂商的配置与功能各有差异，但都能减轻您的实现负担。
使用托管服务的好处还在于无需自维护，云厂商会持续更新服务，您只需专注于合理配置。
初识 GCP？请查看 Cloud Run：在 GCP 部署容器化应用指南 。
以 Cloud Foundry 与其他工具为例 Cloud Foundry 是一个开源 PaaS，屏蔽了大量底层基础设施，使开发者专注于提交代码。它在大型企业中尤为受欢迎，因其自动化、合规特性与快速部署工作流。
以下是在 Cloud Foundry 中使用官方 CLI 进行典型蓝绿部署的流程：
推送蓝色版本 ，使用子域名 demo-time： cf create-route example.com --hostname my-appcf push my-appcf map-route my-app example.com --hostname my-app技术支持 蓝色已运行，路由器将全部流量发送至 my-app.example.com。 推送绿色版本 ，使用新名称与新路由： cf create-route example.com --hostname my-app-tempcf push my-app-greencf map-route my-app-green example.com --hostname my-app-temp技术支持 两套应用实例现已运行，但对应两条可接受流量的路由（蓝色的 my-app.example.com 与绿色的 my-app-temp.example.com）。 将生产路由映射到绿色 ： bashcf map-route my-app-green example.com -n my-app技术支持 此时新旧（蓝与绿）版本均在线，除非您显式移除蓝色，否则流量会同时路由给两者。 验证绿色版本 是否正常工作。您可以通过其路由测试，或在切换后监控真实流量。 从蓝色解绑路由 ，将流量完全切换至绿色： cf unmap-route my-app example.com -n my-app技术支持 路由器不再向蓝色发送流量。 删除旧应用 并删除绿色的临时路由 （可选但推荐）： cf delete my-appcf unmap-route my-app-green example.com --hostname my-app-temp技术支持 该流程将停机时间降至最低，并让您完全掌控何时、如何切换版本。
如果您希望用可视化流水线、人工审批或自动回滚来进一步改进这一流程， Octopus Deploy 、 Codefresh 或 Spinnaker 都是稳妥的选择。它们能与 CI/CD 无缝集成，帮助团队自动化复杂的部署全生命周期。
最佳实践与优化策略 蓝绿部署听起来很美好，也确实很有帮助，但若未妥善管理成本、风险或自动化，很快就会变得混乱。我见过团队深受过度复杂的方案或意外边界情况之苦。
看看该如何避免踩坑，并让您的蓝绿策略取得成功。
成本管理技巧 复制环境当然会带来额外成本。
但可以通过以下策略尽量降低：
自动扩缩 ：使用水平 Pod 自动扩缩或云原生自动扩缩，匹配实际负载，避免资源浪费。 竞价实例与可抢占实例 ：若仅用于测试、且可接受中断，非常适合绿色环境。 临时供给 ：不要让绿色环境运行超过必要时间。通过 CI/CD 启动，切换后销毁。 容器化 ：轻量、快速、成本效率高，尤其在 Kubernetes 或 Azure Container Apps 上运行时。 自动化验证框架 在完全有把握绿色应用按预期工作之前，绝不要切换流量。
使用以下测试层级，在切换前建立信任：
冒烟测试： 关键端点是否存活且健康？ 集成测试： 核心流程（认证、数据访问等）在绿色版本中是否正常？ 端到端测试： 针对临时绿色路由模拟真实用户行为（在 Cloud Foundry 与 Azure 中尤为实用）。 将这些测试集成到 CI/CD，使其在成功部署后自动运行。
需要回顾如何构建这些流程？ 机器学习的 CI/CD 涵盖如何将自动化验证融入部署生命周期。
数据库迁移方法论 这部分比较难，因为应用可以在两个环境中运行，但数据库通常最终对两者来说是同一个。
安全过渡的方法：
向后兼容的 Schema 变更 ：默认假设在绿色上线时，蓝色仍会使用数据库。 功能开关 ：仅在新 Schema 部署后，逐步开放依赖该 Schema 的功能。 版本化迁移 ：使用 Flyway、Alembic 或 Liquibase，使变更可追踪、可回退。 会话/数据一致性： 若依赖会话状态，使用双方共享的外部存储（如 Redis）。 功能开关与渐进式交付 将蓝绿与功能开关结合，可获得更大灵活性。
借助开关，您可以：
仅向绿色环境中的部分用户开放新功能 部署功能但暂不显露 在不暴露完整功能集的前提下，安全测试边界情况或性能影响 使用 LaunchDarkly、ConfigCat 或 Unleash 等工具可简化管理，无需修改代码。
健壮的监控与可观测性 监控与可观测性是安全切流的关键，它使您能够正确评估绿色是否可安全替代蓝色。
您应具备：
健康检查 ：如 Kubernetes 的 readinessProbes、Azure 的修订版本 URL 等。 日志 ：集中可检索，并按环境（蓝 vs. 绿）打标签。 告警： 设定阈值，在错误率上升时收到通知。 流量分析 ：比较蓝绿行为（如延迟、错误率、吞吐）。 不过，无论是否采用蓝绿，健壮的监控与可观测性都应该是您基础设施的一部分。
回滚与灾备规划 偶发问题在所难免。目标是在故障发生时尽可能快速、轻松地恢复。
做法如下：
即时回滚 ：在确认绿色稳定前，务必保持蓝色环境在线。 自动回滚触发器 ：使用 Argo Rollouts 或 Spinnaker 等工具，在关键指标异常时自动回退流量。 运行手册与预案 ：预先编写步骤，确保团队人人清楚该做什么。 想要更多实用的 DevOps 自动化建议，请查看 Azure DevOps 教程 。
安全加固 拥有两个环境，也意味着有两处潜在攻击面。
以下建议可提升安全性：
环境隔离 ：使用独立子网、命名空间或云资源组，确保隔离。 频繁轮换密钥 ：尤其是在蓝绿共享凭据时。 为两套环境打补丁 ：不要因为绿色暂未对外就让其安全更新滞后。 审计日志 ：记录部署事件与环境切换，便于追溯。 结语 蓝绿部署并非只有“过度工程化”的流程才会使用的华而不实策略。它切实可行、可靠稳妥，适合重视可用性、快速反馈与安稳睡眠的团队。
它带来：
在出问题时即时回滚 生产级测试而无需让真实用户承担风险 更干净、更自信的发布，哪怕在周五（真的） 但它是否适用于所有场景？我认为并非如此。您需要有稳固的 CI/CD 体系与支持该路径的工具，否则容易迅速变得混乱。
不过，这不应成为回避它的理由，而是改进部署实践的信号。
我们采用蓝绿部署后，发布流程显著改善，发布日也轻松不少，甚至有信心在周五发布。
若想更深入，建议从 DevOps 概念 或 MLOps 部署与生命周期管理 入手，它们将帮助您夯实蓝绿部署所依托的基础。
现在，请自信地发布您的应用吧。
%22%3E%3Cpath%20d%3D%22m-369%200h408v79h-408z%22%20fill%3D%22%237933ff%22%2F%3E%3Cpath%20d%3D%22m-148%200h306v45h-306z%22%20fill%3D%22%23974dff%22%2F%3E%3C%2Fg%3E%3C%2Fsvg%3E)
%22%2F%3E%3C%2FclipPath%3E%3Cg%20clip-path%3D%22url(%23a)%22%3E%3Cpath%20d%3D%22m76%200h484v36h-484z%22%20fill%3D%22%23974dff%22%2F%3E%3Cpath%20d%3D%22m0%200h384v24h-384z%22%20fill%3D%22%2306bdfc%22%20transform%3D%22matrix(1%200%200%20-1%200%2060)%22%2F%3E%3C%2Fg%3E%3C%2Fsvg%3E)
刚开始做 MLOps 工程师时，我需要上线一个包含用于图像分类的机器学习模型的小型应用。第一次上线一切顺利。但当我更新模型后，噩梦开始了。首先，承载新模型的 Pod 因测试环境与生产环境存在差异而无法启动。此外，客户也无法工作，因为承载旧模型的 Pod 已被我这个无法启动的新 Pod 替换。这简直是一场灾难。最后我不得不手动回滚，并向该模型的用户道歉。
不过，我从中吸取了教训，转而采用蓝绿部署策略。这种 DevOps 方法可以在无停机、无需熬夜回滚的情况下无缝发布更新。
在本指南中，我将带您了解蓝绿部署在实践中的样子：如何搭建、权衡点有哪些、文档里没有的经验教训。无论您在构建 ML 服务、API，还是全栈应用，这种方法都能为团队提供发布新功能所需的“安全网”，让您更有信心地推进上线。
理解蓝绿部署
蓝绿部署听起来比实际复杂（至少对我而言，刚听说时觉得很难）。
它其实就是一种聪明的发布技巧：通过维护两个相同的生产环境并在其间切换流量，从而在不打扰用户的情况下发布新版本。
如果您遇到过应用在预发可用、到生产却崩溃的问题，那这项策略就很适合您！
核心架构与运行机制
基本思路是：维护两个相同的生产环境。一个称为蓝（blue），另一个称为绿（green）。
蓝色环境是当前用户正在使用的。当您有新版本要发布时，先将其部署到绿色环境，进行测试；当您确信其工作正常，再将生产流量从蓝色切换到绿色。
这种策略带来的是零停机、没有“抱歉我们在更新”的提示。一切过渡都在幕后悄然完成，用户甚至不会察觉。
在实践中，“魔法”发生在负载均衡器上。您通过配置它在两个环境间路由流量，取决于部署状态。这样可以对流量进行精细控制，并让回滚变得像把流量切回蓝色环境一样简单。
这种策略解决了我在新 ML 模型上遭遇的“为什么在预发好好的”的问题。因为绿色环境同样是生产环境，您会在真实世界中进行测试，而不是等用户先用再发现问题。
下面是典型流程的快速概览：
蓝绿部署阶段 1：新应用在绿色环境测试，流量仍指向蓝色（作者供图）。
蓝绿部署阶段 2：流量切换至绿色环境（作者供图）。
历史演进与行业采纳
蓝绿方法大约在 2005 年由 Daniel Terhorst‑North 和 Jez Humble 在 ThoughtWorks 内部命名并使用。随后在 2010 年由 Jez Humble 和 Dave Farley 的著作《持续交付》中记录并推广。
自那以后，从初创公司到如今的云原生巨头（如 Netflix），再到每天多次无痛部署的团队，都在广泛采用它。
云平台加速了这一转变。借助基础设施即代码、自扩缩组和像 Kubernetes 这样的容器编排工具，启用并维护“镜像”环境变得简单。
蓝绿部署甚至启发了其他发布模型，如金丝雀发布和功能开关。理解了蓝绿，也就为理解其他模型打下了基础。
DevOps 新手？从DevOps 概念课程开始吧。清晰实用的基础，帮助您在深入高级工作流之前理解核心策略。
蓝绿部署的关键收益
坦白说，我第一次听到蓝绿部署时，觉得维护两个生产环境完全不合理。但当我看到上线新 ML 模型变得容易，用户投诉和升级也明显减少时，我意识到这确实值得。
接下来几节，我将重点介绍蓝绿部署的优势。
近乎零停机
这是最显而易见的一点：没人希望停机。
通过蓝绿，您可以瞬时将流量从旧环境切到新环境，而无需经历服务降级。用户不会注意到切换——理应如此。
当您运行面向用户的 API、仪表盘，或无法容忍几分钟中断的 ML 流水线时，这将成为“游戏规则改变者”。
回滚简单
想象一下，您刚发布新版本，几分钟后就发现产生大量 500 错误。采用蓝绿部署，您只需把负载均衡切回蓝色环境，便可从容修复，无需仓促行事。
这种安全级别能让团队更自信地高频发布，不再有“运行着的系统别动”的心态。
安全的生产环境测试
您可以在生产环境测试而不让用户暴露于风险之下。这就是绿色环境的妙处。您可以在真实环境中进行压测、集成检查，甚至模拟用户行为，先于真实流量进入应用之前完成验证。
与传统预发不同，您是在同样的基础设施、配置等环境中运行测试。
这样测试结果更贴近真实情况。
支持 A/B 测试与分阶段发布
当您拥有两个相同的生产环境时，还能做更多。例如，您可以将 90% 流量路由到蓝色版本，10% 路由到绿色版本。
您还可以集成功能开关来控制功能何时上线。蓝绿部署可作为底层发布基础为其提供良好支撑。
如果想更深入了解渐进式交付，请查看 数据工程中的 CI/CD。它概述了如何搭建支持 A/B 测试与渐进式发布的流水线。
更佳的用户体验与业务连续性
蓝绿部署有助于：
如果您在部署关键的机器学习服务或大家每天依赖的内部数据工具，这些都有很大意义。
蓝绿部署的规划
在实施蓝绿部署之前，有必要先更深入地理解它。
下面从架构、成本考量和组织准备度三个方面拆解所需条件。
基础设施要求
您需要两个相同的生产环境。这意味着双倍的搭建与维护。
但先别为成本惊慌。它并不总是意味着双倍费用。借助云平台或 Kubernetes，您可以在需要时才为绿色环境启动资源，并在之后释放掉。
以下做法有助于搭建两个环境：
同时要注意，在本地自建环境中会更复杂，您需要确保：
您可以参考 AWS、Azure 与 GCP 服务对比，以决定在您的平台上哪个最省力。
成本效益分析
质疑者总会指出维护两个生产环境的成本上升。确实，同时运行两个环境并非免费。不过，需要在第二个环境的额外成本与业务停机代价之间做取舍。
问问自己：
这正是蓝绿的最大卖点：更少的中断，更快的迭代，更小的工程压力与倦怠。
优化成本的小技巧：
配置良好的 CI/CD 流水线甚至可以自动处理这些扩缩。
前置条件与组织准备度
这一点常被忽视，却至关重要。
即使有足够的基础设施和工具预算，若团队文化和系统没准备好，蓝绿部署也难以奏效。
您需要：
不确定团队现状？可以考虑 机器学习的 CI/CD。该课程全面解析成熟部署体系的样貌及实现路径。
技术实现
到目前为止，我们讨论了为何要使用蓝绿部署。本节将展示如何实施。
我将拆解一个典型的蓝绿部署生命周期，重点讲解最具挑战的数据库处理。
您将了解该自动化什么、监控什么、哪些环节绝不能跳过。
标准部署生命周期
良好实现的蓝绿部署遵循明确的顺序。实际中通常如下所示：
让回滚步骤与上线一样快，保证团队成员能在一分钟内撤回一次部署。
这份 数据工程中的 CI/CD指南非常适合用来搭建这些自动化阶段。
数据库同步策略
这部分很棘手。您的应用可以是无状态的，但数据库不是。
若这一环节处理不当，就无法轻松回滚，蓝绿部署的意义也就荡然无存。
以下是处理方式：
如果您对生产级 MLOps 感兴趣，我推荐课程 MLOps 部署与生命周期管理。
与其他发布策略的对比分析
蓝绿常被用作其他发布策略的基础，在此之上衍生出应对不同问题的变体。
根据您的架构、发布频率和对复杂度的取舍，可以选择替代方案，或将几种方法混合使用。
我们来比较最常见的一对：蓝绿 vs. 金丝雀发布。
蓝绿与金丝雀发布
这两种策略常被混用，但目标不同。
蓝绿是完全切换的发布模型。将新版本部署到绿色，测试通过后，一次性把 100% 流量切过去。
金丝雀发布是渐进切换。新旧版本并行部署，先将少量流量（如 1%、10%、50%）逐步导向新版本，并在过程中监控潜在问题。
二者的关键差异：
特性
蓝绿
金丝雀
流量切换
一次性
渐进式
回滚
即时（切回蓝色）
部分或逐步回滚
风险暴露
若绿色故障，影响较大
较低（可早期发现问题）
基础设施需求
两个完整环境
可分流的路由层
发布可见性
干净、可控的切换
需要更复杂的可观测性
最适合
小团队、稳定应用
关键服务、大用户群
我个人在将新 ML 模型部署到生产时使用蓝绿，但用户规模也有限。若面向更大的用户群，我可能会更偏好金丝雀发布。
基础设施与运维权衡
两种策略都需要良好工具支撑，但复杂度体现在不同方面。
蓝绿需要相同环境，增加了基础设施成本；但路由很简单，只是在两个环境间切换流量。
金丝雀在基础设施成本上更轻，但需要更多逻辑来实现渐进式流量切换，同时需要更细致的可观测性以尽早捕获问题。
还需考虑的因素：
那么，哪种更适合您？
如果团队的 CI/CD 成熟度尚在提升，蓝绿可能是建立信心的最佳方式。蓝绿也是良好的起点，便于积累经验。
但若您拥有庞大的用户群，或发布变更风险较高（如定价逻辑），金丝雀会更合适。
对 Azure 生态专注的团队， Azure DevOps 教程展示了如何在 Azure 上实现良好的 CI/CD。
平台特定实现
理论说得够多了，来点技术实操。我们看看数据团队日常使用的平台（如 Kubernetes、云托管服务与自动化工具）上，蓝绿部署如何落地。
各平台提供的功能不同，但核心思想不变：两个相同环境与一个流量开关。
Kubernetes 编排模式
在 Kubernetes 中实现蓝绿部署并不复杂，所需工具都已内建于 Kubernetes。
有几种搭建方式：
my-app-blue与my-app-green作为两个独立的 Deployment，复用标签与 Service。关键组件是 Kubernetes Service。它充当负载均衡，通过标签选择器将流量导向蓝或绿 Pod。
比如，您有：
验证绿色版本后，将 service 的选择器更新为
version: green，流量便会立即切换。我建议使用
readinessProbes，确保新版本在接收任何流量前已完全就绪。这一过程可用Argo Rollouts 与 Flagger等工具自动化，它们可处理：
想更深入了解以 ML 为中心的基础设施？看看 全自动化 MLOps。
云原生托管服务
如果您使用 AWS、Azure 或 GCP，好消息是蓝绿部署已内置支持，您只需开启并配置即可。
AWS CodeDeploy（配合 Elastic Beanstalk 或 EC2）：
Azure Container Apps 或 Azure App Service：
Google Cloud（Cloud Run 或 GKE）：
各云厂商的配置与功能各有差异，但都能减轻您的实现负担。
使用托管服务的好处还在于无需自维护，云厂商会持续更新服务，您只需专注于合理配置。
初识 GCP？请查看 Cloud Run：在 GCP 部署容器化应用指南。
以 Cloud Foundry 与其他工具为例
Cloud Foundry 是一个开源 PaaS，屏蔽了大量底层基础设施，使开发者专注于提交代码。它在大型企业中尤为受欢迎，因其自动化、合规特性与快速部署工作流。
以下是在 Cloud Foundry 中使用官方 CLI 进行典型蓝绿部署的流程：
demo-time：my-app.example.com。my-app.example.com与绿色的my-app-temp.example.com）。该流程将停机时间降至最低，并让您完全掌控何时、如何切换版本。
如果您希望用可视化流水线、人工审批或自动回滚来进一步改进这一流程，Octopus Deploy、Codefresh 或 Spinnaker 都是稳妥的选择。它们能与 CI/CD 无缝集成，帮助团队自动化复杂的部署全生命周期。
最佳实践与优化策略
蓝绿部署听起来很美好，也确实很有帮助，但若未妥善管理成本、风险或自动化，很快就会变得混乱。我见过团队深受过度复杂的方案或意外边界情况之苦。
看看该如何避免踩坑，并让您的蓝绿策略取得成功。
成本管理技巧
复制环境当然会带来额外成本。
但可以通过以下策略尽量降低：
自动化验证框架
在完全有把握绿色应用按预期工作之前，绝不要切换流量。
使用以下测试层级，在切换前建立信任：
将这些测试集成到 CI/CD，使其在成功部署后自动运行。
需要回顾如何构建这些流程？ 机器学习的 CI/CD涵盖如何将自动化验证融入部署生命周期。
数据库迁移方法论
这部分比较难，因为应用可以在两个环境中运行，但数据库通常最终对两者来说是同一个。
安全过渡的方法：
功能开关与渐进式交付
将蓝绿与功能开关结合，可获得更大灵活性。
借助开关，您可以：
使用 LaunchDarkly、ConfigCat 或 Unleash 等工具可简化管理，无需修改代码。
健壮的监控与可观测性
监控与可观测性是安全切流的关键，它使您能够正确评估绿色是否可安全替代蓝色。
您应具备：
readinessProbes、Azure 的修订版本 URL 等。不过，无论是否采用蓝绿，健壮的监控与可观测性都应该是您基础设施的一部分。
回滚与灾备规划
偶发问题在所难免。目标是在故障发生时尽可能快速、轻松地恢复。
做法如下：
想要更多实用的 DevOps 自动化建议，请查看 Azure DevOps 教程。
安全加固
拥有两个环境，也意味着有两处潜在攻击面。
以下建议可提升安全性：
结语
蓝绿部署并非只有“过度工程化”的流程才会使用的华而不实策略。它切实可行、可靠稳妥，适合重视可用性、快速反馈与安稳睡眠的团队。
它带来：
但它是否适用于所有场景？我认为并非如此。您需要有稳固的 CI/CD 体系与支持该路径的工具，否则容易迅速变得混乱。
不过，这不应成为回避它的理由，而是改进部署实践的信号。
我们采用蓝绿部署后，发布流程显著改善，发布日也轻松不少，甚至有信心在周五发布。
若想更深入，建议从 DevOps 概念或 MLOps 部署与生命周期管理入手，它们将帮助您夯实蓝绿部署所依托的基础。
现在，请自信地发布您的应用吧。