灰度发布基础：金丝雀发布、蓝绿部署、滚动更新原理对比

灰度发布（Gray Release / Canary Release）是云原生环境下降低发布风险的核心手段。其本质是让新版本流量从小范围逐步扩大至全量，配合可观测性与回滚策略，在异常发生时将影响面控制在最小。本节从原理、流量切换方式、回滚速度与适用场景四个维度，对比三种最主流的灰度发布模式：金丝雀发布、蓝绿部署与滚动更新。

一、三种模式核心原理

二、金丝雀发布（Canary Release）

金丝雀发布得名于“矿工带金丝雀检测毒气”的典故。在软件发布中，新版本先部署到少量实例（金丝雀），仅接收小比例流量，通过监控指标（错误率、延迟、业务成功率）判断是否继续扩大流量。

• 流量控制粒度：支持按百分比、按请求头、按用户ID哈希、按地域等维度分流。
• 典型流程：部署金丝雀 → 观察指标 → 无异常则逐步提升比例 → 达到100%后替换旧版本 → 异常则立即切回。
• 回滚护栏：Policy as Code 可在此处定义“金丝雀最大错误率阈值”，一旦触发自动将流量归零。

三、蓝绿部署（Blue-Green Deployment）

蓝绿部署维护两套完全独立的生产环境：蓝环境（当前稳定版本）与绿环境（新版本）。验证通过后，通过负载均衡器或网关一次性将流量从蓝切到绿。

• 切换原子性：流量切换是瞬间完成的，不存在新旧版本混合流量。
• 回滚优势：只需将流量切回蓝环境，无需重新部署。
• 成本代价：需要双倍计算资源、数据库可能需要双写或共享存储方案。

四、滚动更新（Rolling Update）

滚动更新是 Kubernetes 默认的更新策略。系统逐个（或逐批）替换旧版本 Pod 为新版本 Pod，每次替换后等待新 Pod 通过就绪检查，再继续下一个。

• 更新策略参数：maxSurge（最大超出期望实例数）、maxUnavailable（最大不可用实例数）。
• 回滚方式：通过 kubectl rollout undo 触发，Kubernetes 会自动将 Deployment 回退到上一个 Revision。
• 风险点：回滚过程是“反向滚动”，同样需要逐个替换实例，耗时与更新相当。

# 滚动更新示例：更新镜像并设置滚动参数
apiVersion: apps/v1
kind: Deployment
metadata:
  name: payment-service
spec:
  replicas: 10
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 2        # 最多允许超出 2 个实例
      maxUnavailable: 1  # 最多允许 1 个实例不可用
  template:
    spec:
      containers:
      - name: app
        image: payment:v2.3.1
        readinessProbe:
          httpGet:
            path: /healthz
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 10

五、三种模式流程对比图

下图从流量分配与实例状态两个维度，直观对比三种发布模式在“发布中”与“回滚中”两个阶段的差异。

六、回滚护栏场景下的选择建议

在 Policy as Code 驱动的回滚护栏体系中，三种模式的选择直接影响策略定义方式：

• 金丝雀发布最适合与“渐进式策略”结合：Policy 定义各阶段的流量比例、健康检查阈值、自动回滚条件。回滚动作仅为“调整流量比例”，无需重新部署。
• 蓝绿部署适合“原子性策略”：Policy 只需定义“切换前验证通过”与“切换后健康检查失败则切回”。回滚动作是 DNS 或负载均衡层面的全量切换。
• 滚动更新适合“实例级策略”：Policy 定义每个实例的就绪检查、最大不可用数、回滚触发条件。回滚动作是 Kubernetes 控制器层面的 Revision 回退。