发布软件过去意味着维护窗口和祈祷。现代团队使用使发布例行化的策略，蓝绿部署与金丝雀部署选择是您首先面临的选择之一。两者都降低了风险，但它们的方式相反：一个准备完整的替代品，而另一个则一次对真实用户进行一点测试。

本指南解释了每种方法的工作原理以及实际成本。我们在 Python 3.13 中运行了小型用户路由和回滚示例，并且输出来自该运行。 Kubernetes 示例是说明性的，我们没有运行这些示例。将百分比和阈值视为适应的起始示例。

简短的回答

通过蓝绿部署，您可以运行两个相同的生产环境。一个为用户提供服务，而您在另一个上部署和测试新版本，然后一次性切换所有流量。

通过 canary 部署，新版本将在旧版本旁边运行。您向其发送一小部分实际流量，比较结果，然后逐步增加份额，直到为所有人服务。这个名字来源于金丝雀矿工曾经用作危险的预警。

蓝绿与金丝雀并排

蓝绿部署的工作原理

1. Blue 已上线并为所有流量提供服务。
2. 将新版本部署到 green，该版本不接收任何用户流量。
3. 在真实的生产环境中，使用冒烟测试和内部用户来彻底测试绿色。
4. 将路由器、负载均衡器或 DNS 切换为绿色以发送流量。
5. 仔细观察，蓝色仍在运行并准备就绪。
6. 如果出现问题，请切换回来。如果一切顺利，蓝色将成为下一个空闲环境。

在 Kubernetes 中，您可以通过更改服务的选择器来进行切换，以便流量转移到不同标记的 Pod：

apiVersion: v1
kind: Service
metadata:
  name: shop
spec:
  selector:
    app: shop
    version: green   # was: blue
  ports:
    - port: 80
      targetPort: 8000

优点：它在概念上很简单，您可以在用户看到它之前测试确切的生产设置，并且回滚几乎是即时的。 弱点：重复的基础设施可能会很昂贵，通过测试的错误会立即影响到每个人，并且在切换期间需要小心开放会话和正在进行的工作。如果您对交换机使用 DNS，缓存的记录可能会延迟它。对这些概念不熟悉？请参阅我们的 Kubernetes 初学者教程。

金丝雀部署的工作原理

1. 将新版本与稳定版本一起部署。
2. 将一小部分流量（例如 5%）路由到金丝雀。
3. 将错误率、延迟和业务指标与稳定版本进行比较。
4. 如果健康，增加到 25%，然后 50%，然后 100%。
5. 如果出现任何性能下降，请将所有流量发送回稳定版本。

许多团队先从内部员工开始金丝雀，然后是低风险区域，最后才是更广泛的公众。

优点： 糟糕的版本只会影响一小部分人，并且您可以从真实流量中了解到没有测试环境可以完全重现。 弱点：您需要基于百分比的路由和每个版本的指标，部署需要更长的时间，并且两个版本一起运行一段时间。小金丝雀也可能太安静而无法发出有意义的信号，尤其是在交通流量较少的时候。

稳定的用户路由

根据每个请求随机选择一个版本会给用户带来混乱的体验，因为他们可能会在新旧版本之间来回切换。一个常见的解决方案是将稳定的用户 ID 散列到一个存储桶中，因此每个用户总是得到相同的答案：

import hashlib

def bucket(user_id):
    digest = hashlib.sha256(user_id.encode()).hexdigest()
    return int(digest, 16) % 100

def version_for(user_id, canary_percent):
    return "v2" if bucket(user_id) < canary_percent else "v1"

users = [f"user-{i}" for i in range(10000)]
for percent in (5, 25, 50, 100):
    share = sum(version_for(u, percent) == "v2" for u in users) / len(users)
    print(percent, round(share * 100, 1))

# 5 5.0
# 25 24.5
# 50 49.9
# 100 100.0

实际份额紧随目标。该方法有两个更有用的属性，我们的运行证实了这两个属性。同一用户始终收到相同的版本。 5% 组中的每个人仍包含在 25% 中，因此随着部署的扩展，已经拥有新版本的人都不会被退回。

在实际系统中，服务网格、负载均衡器或 Argo Rollouts 或 Flagger 等工具通常会处理此路由，因此您不需要自己编写。了解他们在做什么仍然很有帮助。

自动化决策

金丝雀仅在有人实际比较版本时才起作用。自动检查比人看图表更可靠。这是核心思想，将金丝雀的错误率与稳定版本的错误率进行比较：

def should_rollback(canary_errors, canary_total, base_errors, base_total,
                    tolerance=1.5, min_requests=500):
    if canary_total < min_requests:
        return False   # not enough data to decide
    return (canary_errors / canary_total) > (base_errors / base_total) * tolerance

should_rollback(3, 100, 10, 5000)        # False: too few requests
should_rollback(30, 1000, 100, 10000)    # True:  3% against 1%
should_rollback(12, 1000, 100, 10000)    # False: 1.2% is within tolerance

注意第一种情况。它的错误率看起来很高，但只有 100 个请求，还没有足够的证据。真正的工具会应用更仔细的统计数据，并且它们会一起查看多个信号：

数据库问题

应用程序代码可以在几秒钟内交换，但数据不能。两种策略通常共享一个数据库，因此在部署期间和回滚之后，新旧版本必须都使用相同的架构。

标准答案是扩展和收缩模式。假设您要将 name 重命名为 full_name：

1. 展开：添加新列。旧代码不受影响。
2. 迁移：发布写入两列的代码，并回填旧行。
3. 开关：释放从新列读取的代码。
4. 契约：一旦没有任何东西使用旧列，就在以后的版本中将其删除。

这需要多次发布，但每一步都可以安全地回滚。一次性运行 RENAME COLUMN 会破坏任何需要另一个名称的版本。还要小心长时间运行的架构更改，因为它们可以持有锁。有关这方面的更多信息，请阅读 SQL 事务。

滚动策略和其他策略

Kubernetes 部署默认进行滚动更新，这适合许多服务。滚动更新也会逐渐变化，但其份额与实例数量相关，并且它本身不会分析结果或因不良指标而暂停。

功能标志怎么样？

部署将代码放在服务器上，发布 使功能可供用户使用。功能标志将这些功能分开，让您无需部署任何内容即可为选定的用户打开功能。它们对于这两种策略都非常有效：在关闭标志的情况下进行部署，然后逐渐启用它。它们不会取代这些策略，因为标志无法保护您免受启动时崩溃的版本的影响。请记住删除旧标志，因为它们会累积为技术债务。

如何选择

它们也可以组合起来。有的团队部署了绿化环境，然后逐步将流量转移到绿化环境中，获得了干净的环境和有限的爆炸半径。无论您选择什么，都可以通过您的 CI/CD 管道 实现自动化，正如我们的 GitHub Actions 指南 所解释的那样。

常见错误

• 进行重大架构更改。 如果旧代码无法读取数据，则回滚没有帮助。
• 没有回滚标准。 在发布开始之前而不是在事件期间确定“坏”的含义。
• 让环境发生变化。如果绿色与蓝色不同，则您的测试证明的结果较少。使用基础设施作为代码定义两者。
• 仅测量技术指标。 发布可以没有错误，但仍会中断签出。
• 永远不要练习回滚。排练它，以便它在你面临压力时发挥作用。
• 忘记后台作业。工作人员和计划任务在切换期间也需要一个计划。

最后的话

蓝绿色为您提供干净、快速的切换。金丝雀给你一个小而谨慎的曝光。如果您的监控仍然是基础的，请从滚动更新或蓝绿开始，并在尝试金丝雀之前投资每个版本的指标。然后演练下一个版本的回滚，包括数据库。这个单一的练习往往会揭示出真正需要解决的问题。

常见问题

继续学习