📚 课程目录第2章发布策略基础

2、发布策略基础：什么是发布策略，灰度发布、蓝绿部署、金丝雀发布、滚动更新的概念对比

2.1 发布策略的本质

发布策略（Deployment Strategy）是指将新版本软件从开发环境迁移到生产环境，并面向用户提供服务的过程模型与流量调度规则。它决定了：

变更速率：一次替换多少实例、多快完成。
风险暴露面：故障时影响多少用户。
回滚能力：发现问题后能否快速切回旧版本。
资源开销：是否需要额外的基础设施（如双倍集群）。

核心原则：没有完美的发布策略，只有适合当前业务场景的折中方案。选择策略时需在发布速度、安全性、成本三者间做权衡。

2.2 四种主流发布策略对比

策略	核心机制	流量切换方式	回滚速度	资源成本	典型场景
滚动更新	逐个或分批替换旧实例	实例级逐步替换	慢（需反向滚动）	低（无额外资源）	无状态微服务、常规迭代
蓝绿部署	维护两套完整环境（蓝/绿）	一次性路由切换	极快（切回旧环境）	高（双倍资源）	关键业务、数据库迁移
金丝雀发布	小比例流量先验证新版本	按权重逐步放量	快（停止放量+切回）	中（少量额外实例）	高风险变更、A/B测试
灰度发布	按用户/地域/属性分批开放	基于规则路由	中等（规则回退）	中低（复用实例）	功能内测、区域试点

2.3 四种策略详解

2.3.1 滚动更新（Rolling Update）

滚动更新是 Kubernetes 等编排平台的默认策略。它通过逐步替换旧版本 Pod 实例来完成发布，期间始终保持一定数量的可用实例。

工作流程：启动新实例 → 等待就绪 → 销毁旧实例 → 重复直到全部替换。
关键参数：maxSurge（最大超出实例数）、maxUnavailable（最大不可用实例数）。
优点：零额外资源、平滑过渡、适合无状态服务。
缺点：回滚需要反向滚动、耗时较长、无法精确控制流量比例。

# Kubernetes 滚动更新配置示例
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
spec:
  replicas: 10
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 2        # 最多允许超出 2 个实例
      maxUnavailable: 1  # 最多允许 1 个实例不可用
  template:
    spec:
      containers:
      - name: app
        image: my-app:v2.0.0

2.3.2 蓝绿部署（Blue-Green Deployment）

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

工作流程：部署新版本到绿环境 → 全面测试 → 切换路由 → 蓝环境作为回滚备用。
关键参数：环境标识、路由权重（0→100%）。
优点：秒级回滚、零停机、测试环境与生产一致。
缺点：资源成本翻倍、数据库兼容性需额外处理（如双向迁移）。

数据库迁移陷阱：蓝绿部署中，如果新版本修改了数据库 schema，切换后旧版本（蓝环境）可能无法兼容新数据。建议使用向前兼容的数据库变更或并行双写策略。

2.3.3 金丝雀发布（Canary Release）

金丝雀发布源自煤矿工人用金丝雀检测毒气的做法。它将新版本先暴露给一小部分流量（如 5%），监控指标正常后再逐步扩大比例，直至全量。

工作流程：部署金丝雀实例 → 路由 5% 流量 → 监控错误率/延迟 → 逐步提升至 10%、25%、50%、100%。
关键参数：初始权重、步进比例、观察窗口、健康阈值。
优点：风险可控、可精确衡量新版本表现、支持自动回滚。
缺点：需要流量管理能力（如 Service Mesh）、监控体系完善度要求高。

2.3.4 灰度发布（Gray Release / Traffic Splitting）

灰度发布与金丝雀类似，但更强调按用户维度而非流量比例进行控制。它通常基于用户 ID、IP 段、地域、设备类型等属性做路由决策。

工作流程：定义灰度规则 → 匹配用户进入新版本 → 收集反馈 → 扩大灰度范围 → 全量发布。
关键参数：灰度规则表达式、白名单、灰度比例。
优点：用户体验一致（同一用户不会反复切换）、适合功能内测。
缺点：规则配置复杂、需要网关或 Service Mesh 支持。

2.4 策略选择决策树

2.5 关键参数配置调优要点

无论选择哪种策略，以下参数直接影响发布的安全性和效率：

参数维度	滚动更新	蓝绿部署	金丝雀发布	灰度发布
批次大小	`maxSurge` / `maxUnavailable`	全量切换	初始 5-10%	按规则比例
等待时间	就绪探针周期	测试验证时长	观察窗口（5-15min）	反馈收集周期
回滚触发	手动 kubectl rollout undo	路由切回蓝环境	自动（错误率 > 阈值）	规则回退
监控指标	Pod 状态、重启次数	端到端可用性	错误率、P99 延迟	用户反馈、功能使用率

  调优建议：金丝雀发布的初始权重建议设为 5%，步进比例采用指数增长（5% → 10% → 25% → 50% → 100%），每个阶段观察至少 5 分钟。滚动更新的 maxUnavailable 建议设为 1（保证绝大多数实例可用），maxSurge 设为 25%（加速发布但不浪费资源）。

2.6 常见误区与避坑指南

误区一：认为蓝绿部署可以解决所有问题。实际上，数据库 schema 变更、缓存预热、会话粘滞等问题在蓝绿切换时依然存在。
误区二：金丝雀发布只关注错误率。新版本可能功能正常但性能下降（如数据库慢查询），必须同时监控 P99 延迟 和 资源消耗。
误区三：灰度发布与金丝雀发布混为一谈。金丝雀按流量比例随机分配，灰度按用户属性定向分配，两者在路由实现上有本质区别。
误区四：滚动更新不需要回滚计划。当新版本启动失败时，滚动更新可能卡住，需提前配置 progressDeadlineSeconds 超时回滚。