4. 灰度发布基础

4.1 灰度发布定义

灰度发布（Gray Release / Canary Release）是一种渐进式的软件发布策略，其核心思想是让新版本代码先在一小部分用户或服务器上运行，在验证其稳定性和性能符合预期后，再逐步扩大范围，直至覆盖所有用户。它本质上是风险控制与业务连续性之间的平衡手段。

与传统的“Big Bang”全量发布不同，灰度发布将发布过程拆解为多个可观测、可控制、可回滚的阶段，从而将潜在故障的影响面限制在最小范围内。

4.2 常见灰度策略

业界主流的灰度策略有三种：金丝雀发布、蓝绿部署和滚动发布。下表从流量切换、资源消耗、回滚速度等维度进行了对比：

4.2.1 金丝雀发布（Canary Release）

金丝雀发布是最贴合“灰度”本意的策略。它从集群中抽取一小部分实例（金丝雀组）部署新版本，通过路由规则将特定比例的流量导入金丝雀组。监控系统持续观测错误率、延迟、CPU 等指标，只有当指标在 Error Budget 允许范围内时，才逐步扩大金丝雀比例。

4.2.2 蓝绿部署（Blue-Green Deployment）

蓝绿部署维护两套完全独立的生产环境：蓝环境（当前稳定版本）和绿环境（新版本）。发布时，将流量一次性从蓝环境切换到绿环境。由于两套环境完全隔离，回滚只需将流量切回蓝环境即可，速度极快。但缺点是资源成本翻倍。

4.2.3 滚动发布（Rolling Release）

滚动发布通过逐步替换旧实例来完成升级。例如，在 Kubernetes 中设置 maxSurge=1 和 maxUnavailable=0，系统会先启动一个新 Pod，待其 Ready 后再停止一个旧 Pod，如此循环直到所有 Pod 都被替换。滚动发布对资源要求适中，但回滚速度较慢，且难以精确控制流量比例。

# Kubernetes 滚动更新示例
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 10
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1        # 允许超出期望副本数的最大 Pod 数
      maxUnavailable: 0  # 更新期间不可用 Pod 的最大数量
  template:
    spec:
      containers:
      - name: app
        image: my-app:v2.0.0

4.3 灰度发布与全量发布的区别

灰度发布并非全量发布的简单替代，而是对发布流程的精细化管控。两者的核心区别体现在以下五个维度：

• 风险暴露面：全量发布是一次性暴露所有用户；灰度发布是逐步暴露，风险可控。
• 回滚代价：全量发布回滚通常需要重新部署，耗时较长；灰度发布回滚只需调整路由或停止扩容，秒级完成。
• 容量验证：全量发布无法在发布前验证新版本的容量；灰度发布可以在小流量阶段完成容量评估，避免全量上线后因性能劣化导致故障。
• 用户体验：全量发布可能导致所有用户同时遭遇故障；灰度发布仅影响小部分用户，且可通过分流策略（如只灰度内部用户）进一步降低影响。
• 决策依据：全量发布依赖发布前的测试结果；灰度发布依赖实时的 Error Budget 消耗数据，决策更科学。