📚 课程目录第2章灰度发布基础

灰度发布基础：概念与部署策略对比

在 Serverless 平台中，发布流水线需要在不中断服务的前提下完成版本切换。灰度发布（Canary Release / Gradual Rollout）正是实现这一目标的核心方法论。本章从概念出发，系统对比金丝雀发布、蓝绿部署、滚动更新三种主流策略，为后续灰度批次伸缩与日志留痕奠定理论基础。

2.1 灰度发布核心概念

灰度发布是指将新版本逐步引入生产环境，先让一小部分用户或流量使用新版本，在验证稳定后逐步扩大范围，直至全量覆盖。其本质是风险控制与可观测性的结合。

  灰度发布三要素：
  灰度批次：将用户/流量划分为多个批次，每个批次对应一个发布阶段。
流量控制：通过权重、Header、Cookie 等方式精确路由灰度流量。
观测与回滚：每个批次执行后收集指标与日志，异常时立即回滚。

💡 关键指标：灰度发布的核心度量是 MTTR（平均恢复时间） 和 错误预算消耗率。灰度粒度越细，MTTR 越低，但发布总时长可能增加。

2.2 三种主流部署策略对比

金丝雀发布、蓝绿部署、滚动更新是业界最常用的三种策略。它们在资源占用、回滚速度、流量控制粒度上各有优劣。

对比维度	金丝雀发布	蓝绿部署	滚动更新
核心思想	小比例验证，逐步放量	两套环境瞬间切换	逐个替换实例
资源占用	低（共享大部分实例）	高（需两套完整环境）	低（逐步替换）
回滚速度	快（调整流量权重）	极快（切换回蓝环境）	慢（需逐个回退）
流量控制粒度	细（支持百分比/用户属性）	粗（全量切换）	中（按实例比例）
适用场景	功能验证、A/B 测试	重大版本、数据库迁移	常规补丁、无状态服务
Serverless 适配性	高（天然支持流量权重）	中（冷启动成本高）	高（实例级替换）

2.3 金丝雀发布详解

金丝雀发布（Canary Release）得名于“矿工金丝雀”的典故——用一只金丝雀检测矿井毒气。在软件发布中，新版本先部署到少量实例（金丝雀组），验证通过后再逐步扩大范围。

  金丝雀发布典型流程：
  基线部署：当前稳定版本（v1）运行在全部实例上。
金丝雀部署：将 v2 部署到 5% 的实例上，流量按比例路由。
观测期：监控错误率、延迟、业务指标，持续 5-15 分钟。
逐步放量：若指标正常，将 v2 比例提升至 25% → 50% → 100%。
全量切换：v2 覆盖全部实例，v1 下线。

2.4 蓝绿部署详解

蓝绿部署（Blue-Green Deployment）维护两套完全独立的环境：蓝环境（当前稳定版本）和绿环境（新版本）。通过负载均衡器瞬间切换流量，实现零停机发布。

⚠️ 注意：蓝绿部署在 Serverless 环境中需要额外关注冷启动问题。切换后绿环境可能经历大量并发冷启动，导致初始延迟飙升。建议在切换前对绿环境进行预热（Pre-warming）。

阶段	蓝环境	绿环境	流量路由
初始状态	v1（活跃）	v2（待命）	100% → 蓝
部署阶段	v1（活跃）	部署 v2，运行验证	100% → 蓝
切换阶段	v1（待命）	v2（活跃）	100% → 绿
回滚（如需）	v1（活跃）	v2（下线）	100% → 蓝

2.5 滚动更新详解

滚动更新（Rolling Update）是 Kubernetes 等编排平台的默认策略。它逐个或逐批替换实例，始终保持一定数量的实例在线，确保服务不中断。

  滚动更新关键参数：
  maxSurge：更新期间允许超出期望实例数的最大数量（如 25%）。
maxUnavailable：更新期间允许不可用实例的最大数量（如 0 或 25%）。
minReadySeconds：新实例就绪后等待的时间，确保稳定后再继续更新。

# Kubernetes 滚动更新配置示例
apiVersion: apps/v1
kind: Deployment
metadata:
  name: serverless-app
spec:
  replicas: 10
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 3          # 最多额外启动 3 个实例
      maxUnavailable: 1    # 最多允许 1 个实例不可用
  template:
    spec:
      containers:
      - name: app
        image: myapp:v2
        readinessProbe:
          httpGet:
            path: /healthz
            port: 8080
          initialDelaySeconds: 5
          periodSeconds: 10

2.6 策略选择建议

场景	推荐策略	理由
新功能 A/B 测试	金丝雀发布	支持按用户属性分流，精细化验证
数据库 Schema 变更	蓝绿部署	需要完整环境隔离，回滚彻底
无状态微服务补丁	滚动更新	资源利用率高，自动化程度高
Serverless 函数更新	金丝雀 + 滚动	利用流量权重 + 实例级替换
紧急安全修复	蓝绿部署	秒级切换，最小化暴露窗口

📌 Serverless 平台实践要点：

金丝雀发布在 Serverless 中天然支持——通过 API Gateway 的流量权重即可实现。
蓝绿部署需注意函数冷启动成本，建议结合预置并发（Provisioned Concurrency）。
滚动更新在 Serverless 中表现为逐步替换函数版本别名指向的底层计算实例。
无论哪种策略，灰度批次伸缩日志留痕都是可观测性的基础——这正是本课程后续章节的核心内容。