1. 灰度发布概述
1.1 灰度发布定义
灰度发布（Gray Release / Canary Release）是一种渐进式的软件发布策略。其核心思想是：将新版本的服务或功能，先小范围地推送给一部分用户（灰度用户），在验证新版本稳定、无重大缺陷后，再逐步扩大发布范围，直至全量覆盖所有用户。整个过程如同“灰度”过渡，从黑到白，平滑切换。
核心特征：灰度发布不是一次性操作，而是一个可观测、可控制、可回滚的持续流程。流量权重是控制发布节奏的关键杠杆。
1.2 灰度发布目的
灰度发布的主要目的可以归纳为以下四点：
| 目的维度 | 详细说明 | 典型收益 |
|---|---|---|
| 风险控制 | 将新版本故障的影响范围限制在最小灰度池内，避免全站宕机或大面积功能不可用。 | 故障爆炸半径缩小 90% 以上 |
| 质量验证 | 在真实生产流量和用户行为下验证新版本的性能、稳定性和正确性，弥补测试环境覆盖不足。 | 线上缺陷发现率提升 60% |
| 业务反馈 | 针对特定用户群体（如 VIP、内测用户）先行体验，收集业务数据和用户反馈，指导后续优化。 | 产品迭代方向更精准 |
| 平滑过渡 | 用户无感知或低感知地完成版本切换，避免因发布导致的流量抖动或用户体验中断。 | 发布期间 P99 延迟波动 < 5% |
1.3 灰度发布与蓝绿发布/金丝雀发布的区别
这三种发布策略常被混淆，但它们的设计理念、流量切换方式和适用场景存在显著差异。以下从多个维度进行对比：
| 对比维度 | 灰度发布（Canary） | 蓝绿发布（Blue/Green） | 金丝雀发布（狭义） |
|---|---|---|---|
| 核心思想 | 渐进式、按权重、分批次 | 全量切换、两套环境 | 小比例、快速验证、快速回滚 |
| 流量切换方式 | 权重逐步调整（如 1% → 5% → 20% → 100%） | 一次性全量切换（从 Blue 切到 Green） | 固定小比例（通常 1% ~ 5%） |
| 基础设施要求 | 支持动态权重路由（如 Service Mesh、网关） | 需要两套完整且独立的生产环境 | 与灰度发布类似，但规模更小 |
| 回滚速度 | 较快，权重归零即可 | 极快，DNS/负载均衡器切换回旧环境 | 极快，直接下线金丝雀实例 |
| 资源成本 | 低，只需少量额外实例 | 高，需长期维护两套环境 | 极低，通常只需 1~2 个实例 |
| 适用场景 | 复杂业务、大规模集群、需要精细化验证 | 关键核心服务、数据库迁移、重大版本 | 简单服务、快速验证、热修复 |
| 用户感知 | 部分用户感知新版本 | 所有用户同时切换，可能有短暂中断 | 极少数用户感知 |
关键辨析：在业界实践中，“灰度发布”常作为“金丝雀发布”的广义代称。本课程后续提到的“灰度发布”，均指代基于流量权重动态调整的渐进式发布流程，并重点围绕“准入中自动回滚”这一核心场景展开。
1.4 三种发布策略的流量切换对比图
下图直观展示了三种策略在流量切换路径上的本质区别：
1.5 灰度发布的核心流程阶段
一个完整的灰度发布流程通常包含以下五个阶段，本课程将重点围绕阶段三（准入验证）和阶段四（自动回滚）展开：
- 阶段一：灰度初始化 — 部署新版本实例，配置初始流量权重（如 1%）。
- 阶段二：灰度观测 — 收集并监控灰度实例的指标（错误率、延迟、资源使用率等）。
- 阶段三：准入验证 — 根据预设的准入规则（指标阈值、日志模式、业务校验）判断当前灰度是否健康。
- 阶段四：自动回滚 / 权重递增 — 若准入验证失败，触发自动回滚，将流量权重归零；若验证通过，则按策略递增权重。
- 阶段五：全量发布 — 权重递增至 100%，完成发布，下线旧版本。
注意：本课程讨论的“自动回滚”特指在准入验证阶段，当检测到异常指标时，系统自动将灰度流量权重恢复为 0 的过程。这与发布后的“手动回滚”或“版本回退”在触发条件和执行速度上有本质区别。