深入理解蓝绿部署：构建无缝、高可靠的发布流程

当我初次担任 MLOps 工程师时，我需要发布一个包含图像分类 ML 模型的应用程序。最初的发布非常顺利，但当模型更新时，混乱就开始了。首先，承载新模型的 Pod 因测试环境和生产环境之间的差异而无法启动。更糟糕的是，承载旧模型的 Pod 已经被新的、无法启动的 Pod 替换，导致用户无法正常工作。这简直是一场噩梦。我不得不手动回滚，并向模型用户道歉。

然而，我从这次经历中吸取了教训，并转向使用蓝绿部署（Blue-Green Deployment）策略。这种 DevOps 方法能够无缝地发布新更新，避免停机，也无需深夜紧急回滚。

本指南将深入探讨蓝绿部署的实践细节：如何设置、权衡、以及文档中可能未提及的经验教训。无论你是构建 ML 服务、API 还是全栈应用程序，这种方法都能为你的团队提供发布新功能所需的“安全网”。

深入理解蓝绿部署（Blue-Green Deployment）

蓝绿部署听起来比实际复杂得多（至少对我来说，当我第一次听说它时，确实觉得很难）。

它实际上是一个巧妙的技巧，可以在不中断用户的情况下发布新版本。其核心在于维护两个相同的生产环境，并在它们之间切换流量。

如果你曾遇到应用程序在测试（staging）环境正常工作，但在生产环境却崩溃的问题，那么蓝绿部署策略正是为你准备的！

核心架构与操作机制

基本思想是：你维护两个相同的生产环境。一个称为“蓝色”环境（Blue），另一个称为“绿色”环境（Green）。

蓝色环境是用户当前正在交互的生产环境。当你想发布一个新版本时，你将其部署到绿色环境，进行测试。一旦你确信新版本运行正常，就将生产流量从蓝色环境重新路由到绿色环境。

这种策略能实现零停机，没有“抱歉，我们正在更新”的提示。这只是一次在幕后进行的平滑过渡，用户甚至不会察觉。

在实践中，这种“魔术”主要发生在负载均衡器（Load Balancer）上。你配置负载均衡器，使其根据部署状态将流量路由到任一环境。这提供了对流量的精细控制，并且回滚也变得异常简单——只需将流量切换回蓝色环境即可。

这种策略解决了我在发布新 ML 模型时遇到的“但在测试环境是好的啊”的尴尬。由于绿色环境也是一个生产环境，因此你可以在用户真正使用新版本之前，就对其进行真实环境的测试。

以下是典型的蓝绿部署流程概述：

将新版本部署到绿色环境。
运行集成测试和冒烟测试（Smoke Tests）。
使用负载均衡器切换流量。
监控绿色环境是否存在任何异常。
如果一切正常，可以销毁蓝色环境，或者将其保留作为回滚备用。

蓝绿部署阶段1：新应用部署到绿色环境进行测试，流量仍路由到蓝色环境 (图片由作者提供)

蓝绿部署阶段2：流量已重新路由到绿色环境 (图片由作者提供)

历史演进与行业应用

蓝绿部署方法由 Daniel Terhorst-North 和 Jez Humble 于2005年左右在 ThoughtWorks 内部命名并使用。随后，在 Jez Humble 和 Dave Farley 2010年出版的《持续交付》（Continuous Delivery）一书中，该方法得到了详细的记录和推广。

自那时起，它被广泛应用于各种场景，从初创公司到如今的云原生巨头（如 Netflix），任何每天需要多次发布且不引发混乱的组织都在使用它。

云平台加速了这种转变。借助基础设施即代码（Infrastructure-as-Code）、自动扩缩组（Auto-Scaling Groups）以及 Kubernetes 等容器编排工具，快速启动和维护重复环境变得异常简单。

蓝绿部署甚至启发了其他部署模型，例如金丝雀发布（Canary Releases）和功能开关（Feature Flags）。理解蓝绿部署，也为你理解其他部署策略奠定了基础。

刚接触 DevOps？可以从 DevOps Concepts 课程开始。它提供了清晰、实用的基础知识，帮助你在深入了解高级工作流之前，掌握核心策略。

蓝绿部署的关键优势

老实说，我第一次听说蓝绿部署时，觉得维护两个生产环境完全没有意义。然而，当我看到它如何轻松地发布新的 ML 模型，以及我收到的用户投诉和升级请求越来越少时，我意识到这一切努力都是值得的。

在接下来的章节中，我将重点介绍蓝绿部署的优势。

接近零停机

这是最显而易见的优势，因为没有人希望出现停机。

通过蓝绿部署，你可以立即将流量从旧环境切换到新环境，而无需等待服务降级。你的用户甚至不会察觉到这次切换，这正是我们所追求的效果。

当你运行面向用户的 API、仪表板或无法承受几分钟中断的 ML 管道时，这无疑是一项颠覆性的改变。

轻松回滚

想象一下，你发布了一个新版本，几分钟后才意识到它抛出了大量的内部服务器错误。使用蓝绿部署，你只需将负载均衡器切换回蓝色环境，就可以从容地修复错误，而无需手忙脚乱。

这种安全级别让团队更有信心频繁发布。再也不会听到“永远不要改变正在运行的系统”这种说法了。

安全的生产环境测试

你可以在不将用户置于风险的情况下，在生产环境中进行测试。这就是绿色环境的魅力所在。你可以在任何实际流量到达应用程序之前，运行负载测试、集成检查，甚至模拟用户行为。

与传统的测试（staging）环境不同，你是在相同的基础设施、配置和所有其他条件上运行测试的。

这使得测试结果更可能反映真实情况。

支持 A/B 测试和分阶段发布

一旦你拥有两个相同的生产环境，你就可以利用它们做更多事情。你可以将 90% 的流量路由到蓝色版本，将 10% 的流量路由到绿色版本，从而进行 A/B 测试。

你还可以集成功能开关（Feature Flags）来控制哪些功能何时上线，而蓝绿部署则可以作为底层部署基础提供良好的支持。

如果你想深入了解渐进式交付，请查阅 CI/CD in Data Engineering。它概述了如何设置支持 A/B 测试和渐进式发布的管道。

更好的用户体验和业务连续性

蓝绿部署有助于：

减少用户遇到的错误。
在出现问题时，提高工程团队的响应速度。
简化备份恢复过程。

如果你正在部署关键的机器学习服务或人们日常依赖的内部数据工具，这些都非常重要。

蓝绿部署规划

在实施蓝绿部署之前，深入理解其运作原理至关重要。

让我们从架构需求、成本考量和内部准备情况几个方面进行分析。

基础设施要求

你需要拥有两个相同的生产环境。这意味着双倍的设置和双倍的维护工作。

但在你开始担心成本之前，请记住，这并不总是意味着双倍的成本。通过云平台或 Kubernetes，你可以仅在需要时为绿色环境启动资源，并在之后将其关闭。

以下工具有助于设置这两个环境：

基础设施即代码（Infrastructure-as-Code，如 Terraform）：用于快速复制环境。
配置管理（Configuration Management）：用于防止由配置漂移（configuration drift）引起的问题。
Kubernetes：可以使用不同的命名空间（namespaces）或部署对象（deployment objects）来区分蓝绿环境。

此外，请记住在本地（on-prem）设置中，情况会变得更复杂，你需要确保：

负载均衡器（Load Balancers）具有足够的可配置性，可以即时切换流量。
你能快速提供环境（可能通过虚拟化或容器）。
外部依赖（例如数据库、API）是同步且相互隔离的。

你可以参考 AWS, Azure and GCP Service Comparison 来决定哪个平台对你的平台最容易。

成本效益分析

怀疑者总是指出维护两个生产环境会增加成本。是的，运行两个环境确实不是免费的。然而，这需要在第二个环境增加的成本与业务停机成本之间进行权衡。

问问你自己：

一次失败部署的平均影响（时间或金钱）有多大？
调试、回滚和解释故障需要多少小时？
你多久在压力下发布一次，只是希望它不会出问题？

这就是蓝绿部署的最大卖点：更少的停机、更快的迭代、更小的工程压力和更少的工作倦怠。

优化成本的技巧：

使用自动扩缩（Auto-scaling）根据测试负载调整绿色环境的大小。
为绿色环境选择 Spot 实例或临时虚拟机（ephemeral VMs）。
在单独的 Kubernetes 命名空间中运行绿色版本，并在切换后将其缩减到零。

一个配置良好的 CI/CD 管道甚至可以自动处理这种扩缩。

先决条件和组织就绪度

这部分经常被忽视，但它非常重要。

即使你拥有基础设施和工具的预算，如果你的团队文化和系统尚未准备好，蓝绿部署也无法奏效。

你将需要：

CI/CD 工作流：能够独立部署和测试绿色环境的管道。
监控和可观察性：你需要在将流量从蓝色切换到绿色之前检查指标。
清晰的回滚策略：最好是自动化的，并且肯定要经过实践。
跨职能协调：开发、运维、质量保证（QA）和产品团队都应该理解整个流程如何运作。

如果你不确定你的团队处于什么状态，可以考虑学习 CI/CD for Machine Learning。它全面分解了一个成熟的部署设置应该是什么样子，以及如何实现它。

技术实现

到目前为止，我们已经讨论了为什么要使用蓝绿部署。在本节中，我将向你展示如何实现它。

我将详细阐述一个典型的蓝绿部署生命周期，重点关注处理数据库这一具有挑战性的方面。

你将了解到需要自动化什么，需要监控什么，以及哪些步骤不应跳过。

标准部署生命周期

一个良好实施的蓝绿部署遵循精确的顺序。在实践中，它通常看起来是这样的：

准备绿色环境：启动一个生产级别的环境，它与你当前的（蓝色）环境完全镜像，无论是在云端、本地还是使用 Kubernetes。
将新版本部署到绿色环境：你的 CI/CD 管道应该在此处构建和部署代码，理想情况下将其标记为当前的发布候选版本。
运行自动化测试：这包括冒烟测试（smoke tests）、集成检查以及任何模拟用户行为的健康探针。你检查绿色环境是否已为用户做好准备。
监控日志和指标：如果你的仪表盘看起来干净，没有警报，那么你就可以继续了。如果没有，请修复问题并重新部署到绿色环境。
切换流量到绿色环境：重新配置你的负载均衡器，将所有流量路由到绿色服务器。
停用蓝色环境：一旦你对绿色环境充满信心，就关闭蓝色环境，或者将其保留作为下一次发布前的备份。

使回滚步骤与发布一样快，这样团队成员可以在不到一分钟的时间内撤销部署。

CI/CD in Data Engineering 指南是设置这些自动化阶段的优秀资源。

数据库同步策略

这部分很棘手。你的应用程序是无状态的，但你的数据库不是。

如果你不仔细处理这部分，你就无法轻松回滚，蓝绿部署的全部意义也就消失了。

以下是你如何处理它的方法：

设计向后兼容性（Backward Compatibility）：在切换期间，用户可能仍然会在几毫秒内访问蓝色环境。在此期间，你的数据库 Schema 需要同时支持两个应用程序版本。
- 不要立即删除或重命名字段。
- 添加新的列/表，使用默认值。
- 避免硬约束，直到两个版本都支持该更改。
版本化迁移（Version your Migrations）：使用 Flyway 或 Liquibase（用于 Java-based 系统），或 Alembic（用于 Python + SQLAlchemy）等工具。
处理会话状态（Handle Session State）：如果你的应用程序使用内存会话存储，切换环境可能会导致用户注销或功能中断。使用 Redis、Memcached 或共享数据库来避免这种情况。
切换后验证数据一致性（Validate Data Consistency post-switch）：自动化检查关键数据以确保一致性。
- 用户能否登录？
- 最近的更改是否已保存？
- 分析管道是否仍正确摄取数据？
监控缓慢漂移（Monitor Slow Drifts）：有时更改不会抛出错误，看起来似乎正常工作，但它们可能会导致微妙的问题，例如事件处理延迟或记录格式错误。使用日志和可观察性工具尽快发现此类问题。

如果你对如何在生产级别使用 MLOps 感兴趣，我推荐课程 MLOps Deployment and Life Cycling。

与其他部署策略的比较分析

蓝绿部署通常作为其他部署策略的基础，提供各种变体以解决部署过程中的不同问题。

根据你的架构、发布频率和对复杂性的容忍度，你可以考虑替代方案，甚至将几种方法混合使用，形成新的策略。

让我们比较最常见的场景：蓝绿部署 vs. 金丝雀部署。

蓝绿部署 vs. 金丝雀部署

这两种策略经常被混淆，但它们建立在不同的目标之上。

蓝绿部署是一种完全切换的发布模型。你将新版本部署到绿色环境，测试它，一旦准备就绪，就将 100% 的流量切换过去。

金丝雀部署则是一种渐进切换。你将新版本与旧版本一同部署，并逐步将一小部分流量（例如 1%，然后 10%，然后 50%）转移到新版本，同时监控潜在问题。

两种策略之间的主要区别：

功能	蓝绿部署（Blue-Green）	金丝雀部署（Canary）
流量切换	一次性全部切换	渐进式切换
回滚	即时（切换回蓝色环境）	部分或渐进式回滚
风险暴露	如果绿色环境出问题，影响大	风险较低（问题能及早发现）
基础设施需求	两个完整的环境	路由层以分割流量
发布可见性	清晰、受控的切换	需要更复杂的观测性
最适合	小型团队、稳定应用	关键服务、庞大用户群体

我个人曾使用蓝绿部署将新的 ML 模型部署到生产环境，但用户群体也相对有限。如果我的模型需要面对更庞大的用户群体，我可能会更倾向于金丝雀发布。

基础设施与操作权衡

这两种策略都需要良好的工具支持，但它们的复杂性体现在不同领域。

蓝绿部署需要相同的环境，这增加了基础设施成本。然而，路由相对简单，因为它只涉及在两个环境之间切换流量。

另一方面，金丝雀部署在基础设施成本方面更轻量，但需要更复杂的逻辑来实现流量的渐进式切换。它还需要更详细的可观察性来尽早发现问题。

以下是一些你需要考虑的其他因素：

监控：金丝雀部署需要更细粒度的指标（例如，每个用户或每个请求的延迟），而蓝绿部署只需知道应用程序是否健康。
自动化工具：像 Argo Rollouts 和 Flagger 这样的工具在 Kubernetes 中同时支持这两种模型，但金丝雀部署需要更多的设置。
部署时间：蓝绿部署速度快。金丝雀部署则更为谨慎，耗时更长。

那么，哪种策略适合你呢？

如果你的团队的 CI/CD 成熟度仍在提升中，蓝绿部署可能是建立信心的最佳方式。蓝绿部署也是一个很好的起点，能让你积累一些经验。

然而，如果你拥有庞大的用户群体或部署具有显著风险的变更（例如价格逻辑），金丝雀部署可能是一个不错的选择。

对于专注于 Azure 的团队，Azure DevOps Tutorial 展示了如何在 Azure 上实现良好的 CI/CD。

平台特定实现

好了，理论部分就到此为止。让我们更深入地探讨技术层面。我们将了解蓝绿部署是如何在数据团队日常使用的平台（如 Kubernetes、托管云服务和自动化工具）中实现的。

每个平台都提供不同的功能，但核心思想保持不变：你需要两个相同的环境和一个流量切换机制。

Kubernetes 编排模式

使用 Kubernetes 实现蓝绿部署非常简单，因为所有必要的工具都已内置于 Kubernetes 中。

有几种设置方法：

独立部署（Separate deployments）：将 my-app-blue 和 my-app-green 作为两个独立的 Deployment 部署，它们共享标签和服务（Service）。
带有修订的单一部署对象（Single deployment object with revision）：不太常见，但如果你使用注解来跟踪版本，也是可能的。
命名空间（Namespaces）：在独立的命名空间中运行蓝色和绿色环境，以实现完全隔离。

这里的关键组件是 Kubernetes Service。它充当负载均衡器，通过标签选择器将流量路由到蓝色或绿色的 Pod。

假设你有：

# 蓝色环境的 Deployment
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app-blue
spec:
  selector:
    matchLabels:
      app: my-app
      version: blue
  template:
    metadata:
      labels:
        app: my-app
        version: blue
    spec:
      containers:
      - name: my-app
        image: my-app:1.0.0
---
# 绿色环境的 Deployment
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app-green
spec:
  selector:
    matchLabels:
      app: my-app
      version: green
  template:
    metadata:
      labels:
        app: my-app
        version: green
    spec:
      containers:
      - name: my-app
        image: my-app:2.0.0 # 新版本
---
# Service， initially points to blue
apiVersion: v1
kind: Service
metadata:
  name: my-app-service
spec:
  selector:
    app: my-app
    version: blue # 初始指向蓝色环境
  ports:
  - protocol: TCP
    port: 80
    targetPort: 8080

在验证绿色版本后，你更新 Service 的选择器（selector）为 version: green，流量就会立即重新路由。

我建议使用 readinessProbes 来确保新版本完全就绪，然后再路由任何流量。

这个过程可以使用 Argo Rollouts 和 Flagger 等工具进行自动化，它们可以处理：

渐进式流量转移
健康检查和监控
崩溃时的自动回滚

你想深入了解以 ML 为中心的 Infra 吗？请查看 Fully Automated MLOps。

云原生托管服务

如果你使用 AWS、Azure 或 GCP，好消息是蓝绿部署功能已经内置，你只需启用它即可。

AWS CodeDeploy (与 Elastic Beanstalk 或 EC2)：

提供专门的蓝绿部署策略。
你定义哪个环境是绿色，CodeDeploy 处理流量切换和回滚。

Azure Container Apps 或 Azure App Service：

Azure 允许你将版本作为“槽位”（slots）进行分阶段部署，并以零停机时间进行交换。
将其与 Azure DevOps 管道结合，可实现全面的 CI/CD 自动化。

Google Cloud (Cloud Run 或 GKE)：

Cloud Run 支持在不同修订版本之间进行渐进式流量拆分，非常适合测试和发布。
使用 GKE，可以通过负载均衡器规则或 Istio 来管理蓝绿逻辑。

每个云提供商都有其独特的设置和功能，但它们都能让你的工作变得更轻松，因为你无需自行实现太多功能。

使用托管服务也总有一个好处，就是你无需自行维护这些东西，因为云提供商会更新他们的服务，你只需担心如何正确配置它们。

刚接触 GCP？请查看 Cloud Run: A Guide to Deploying Containerized Apps in GCP。

Cloud Foundry 及其他工具示例

Cloud Foundry 是一个开源的平台即服务（PaaS），它抽象了大部分底层基础设施，让开发者能够专注于代码推送。它因其自动化、合规性功能和快速部署工作流而在大型企业中特别受欢迎。

以下是使用官方 CLI 在 Cloud Foundry 中进行典型蓝绿部署的步骤：

推送你的应用程序的蓝色版本，使用子域名 demo-time：
```
cf push my-app-blue -d example.com -n my-app-time -m 256M
```
蓝色版本现在正在运行，路由器将所有流量发送到 my-app.example.com。
推送你的应用程序的绿色版本，使用新的名称和路由：
```
cf push my-app-green -d example.com -n my-app-temp -m 256M
```
现在应用程序的两个实例都已启动并运行，但它提供了两条可以发送流量的路由（my-app.example.com 用于蓝色环境，my-app-temp.example.com 用于绿色环境）。
将生产路由映射到绿色环境：
```
cf map-route my-app-green example.com -n my-app-time
```
此时，旧版本（蓝色）和新版本（绿色）都已上线，但流量会同时路由到两者，除非你明确移除蓝色版本。
验证绿色版本是否正常工作。你可以通过其路由进行测试，或在切换后监控实际流量。
从蓝色版本中取消映射路由，完全切换到绿色部署：
```
cf unmap-route my-app-blue example.com -n my-app-time
```
路由器不再向蓝色版本发送流量。

删除旧应用程序和绿色路由（可选但推荐）：

cf delete my-app-blue
cf delete-route example.com -n my-app-temp

此过程最大限度地减少了停机时间，并让你完全控制何时以及如何切换版本。

如果你想通过可视化管道、手动审批或自动回滚来进一步改进此工作流，像 Octopus Deploy、Codefresh 或 Spinnaker 这样的工具是可靠的选择。它们与 CI/CD 管道无缝集成，使团队能够自动化复杂的部署生命周期。

最佳实践与优化策略

蓝绿部署听起来很棒，并且能带来巨大帮助，但如果成本、风险或自动化管理不当，它也可能很快变得非常混乱。我见过一些团队因过于复杂的设置或意外的边缘情况而陷入困境。

让我们看看你应该如何避免这些问题，并使你的蓝绿部署策略取得成功。

成本管理技巧

复制环境当然会带来额外成本。

但你可以通过以下策略将它们最小化：

自动扩缩（Auto-scaling）：利用水平 Pod 自动扩缩器（Horizontal Pod Autoscalers）或云原生自动扩缩功能，以匹配实际工作负载并防止资源浪费。
竞价实例和抢占式实例（Spot instances & preemptibles）：非常适合绿色环境，如果你只是进行测试（并且可以接受可能的干扰）。
临时资源调配（Temporary provisioning）：不要让绿色环境运行时间超过所需。通过 CI/CD 管道启动它，然后在使用后将其销毁。
容器化（Containerization）：它们轻量、快速且成本高效，尤其是在 Kubernetes 或 Azure Container Apps 等平台上运行时。

自动化验证框架

在没有完全确信你的绿色应用程序按预期工作之前，你绝不应该切换流量。

在切换前使用这些测试层级来建立信任：

冒烟测试（Smoke tests）：关键端点是否存活且健康？
集成测试（Integration tests）：核心工作流（身份验证、数据访问等）在绿色版本中是否正常工作？
端到端测试（End-to-end tests）：针对临时绿色路由模拟实际用户行为（在 Cloud Foundry 和 Azure 中特别有用）。

将这些测试集成到你的 CI/CD 管道中，以便它们在成功部署后自动运行。

需要回顾如何构建这些流程吗？CI/CD for Machine Learning 涵盖了如何将自动化验证整合到你的部署生命周期中。

数据库迁移方法论

这是一个棘手的部分，因为你的应用程序可以在两个环境中运行，但你的数据库通常最终是相同的。

以下是安全过渡的方法：

向后兼容的 Schema 更改：始终假定在绿色版本上线时，蓝色版本可能仍在访问数据库。
功能切换（Feature toggles）：仅在部署新 Schema 后，才发布依赖于 Schema 的功能。
版本化迁移（Versioned migrations）：使用 Flyway、Alembic 或 Liquibase 等工具来保持更改可追溯和可逆。
会话/数据一致性（Session/data consistency）：如果你依赖会话状态，请使用外部存储（如 Redis），两个环境都可以共享。

功能开关与渐进式交付

将蓝绿部署与功能开关（Feature Flags）结合使用，可以提供更大的灵活性。

通过功能开关，你可以：

在绿色环境中向部分用户发布新功能。
部署功能但保持其隐藏。
安全地测试边缘情况或性能影响，而无需暴露完整功能集。

利用 LaunchDarkly、ConfigCat 或 Unleash 等工具来简化管理，而无需修改代码。

健全的监控与可观察性

监控和可观察性对于安全地切换流量至关重要，因为它们能让你评估绿色环境是否可以安全地部署到生产环境。

你应该具备：

健康检查：Kubernetes 的 readinessProbes、Azure 的修订 URL 等。
日志记录：集中化、可搜索，并按环境（蓝色 vs. 绿色）进行标记。
警报：设置阈值，并在错误率增加时收到通知。
流量分析：比较蓝色和绿色环境之间的行为（例如，延迟、错误率和吞吐量）。

然而，健全的监控和可观察性无论你是否使用蓝绿部署，都应该是你基础设施的一部分。

回滚与灾难恢复规划

事情总会时不时地出错。我们的目标是尽可能轻松快速地从故障中恢复。

以下是实现方法：

即时回滚：始终保持蓝色环境运行，直到你确认绿色环境稳定为止。
自动化回滚触发器：使用 Argo Rollouts 或 Spinnaker 等工具，如果关键指标失败，则回滚流量。
运行手册和操作指南（Runbooks and playbooks）：为团队预先编写步骤，以便每个人都知道该怎么做。

有关更实用的 DevOps 自动化技巧，请查看 Azure DevOps Tutorial。

安全强化

拥有两个环境意味着你也拥有两个潜在的攻击点。

以下是一些确保适当安全措施的建议：

隔离环境：使用独立的子网、命名空间或云资源组来确保隔离。
频繁轮换密钥：特别是如果蓝绿环境之间使用共享凭证。
修补两个环境：不要仅仅因为绿色环境尚未上线，就让其安全更新滞后。
审计日志：捕获部署事件和环境切换，以便进行可追溯性。

总结

蓝绿部署不仅仅是一种花哨的部署策略，并非只有过度工程化的流程才会采用。它是一种实用且可靠的策略，适用于那些优先考虑正常运行时间、快速反馈和良好睡眠的团队。

它为你带来：

当出现问题时，可以即时回滚。
无需真实用户风险的生产级别测试。
更清晰、更自信的发布，即使在周五（不是开玩笑）。

但它适用于所有情况吗？我认为不是。你需要有一个坚实的 CI/CD 设置，并有支持整个过程的工具。否则，它可能会很快变得混乱。

但这并不是避免它的理由。相反，它是一个信号，表明你应该改进你的部署实践。

通过采用蓝绿部署，我们极大地改进了我们的发布流程，并且此后拥有了异常轻松的发布日，我们甚至有信心在周五进行发布。

如果你想深入了解，可以从 DevOps Concepts 或 MLOps Deployment and Life Cycling 开始，它们将帮助你构建蓝绿部署所依赖的基础。

现在，充满信心地发布你的应用程序吧！

蓝绿部署常见问题解答（FAQs）

蓝绿部署有哪些好处？

它提供了无缝回滚、快速发布、更安全的生产测试，以及通过降低风险和接近零停机时间带来的更愉悦的用户体验。

蓝绿部署与金丝雀部署有何区别？

金丝雀发布逐步向部分用户暴露新版本，而蓝绿部署则一次性将所有流量切换到新版本。

如何在蓝绿部署中管理数据库更改？

通过向后兼容的 Schema 更改、版本化迁移和仔细的数据同步策略。

蓝绿部署需要哪些基础设施？

两个相同的环境（蓝色和绿色）、一个类似负载均衡器的流量切换机制，以及一种强大的 CI/CD 思维方式是必不可少的。

关于

关注我获取更多资讯

📢 公众号

💬 个人号