3. 回滚策略基础概念：定义与区别
在集群升级与持续交付流水线中，回滚（Rollback）、回退（Revert）、金丝雀发布（Canary）和蓝绿部署（Blue-Green）是四个核心概念。它们共同构成了升级失败时的安，但各自的触发时机、作用范围和操作粒度存在本质差异。本节从升级上下文出发，厘清它们的定义、区别与联系。
3.1 核心定义
| 术语 | 英文 | 定义（升级上下文） |
|---|---|---|
| 回滚 | Rollback | 将集群或服务从当前版本整体恢复到上一个已知稳定版本的操作，通常由自动化流水线触发，涉及数据、配置和二进制包的全量恢复。 |
| 回退 | Revert | 在版本控制（如 Git）中撤销某次提交，生成一个新的逆向提交来抵消变更。回退是代码层面的操作，不直接作用于运行时环境。 |
| 金丝雀发布 | Canary | 先让小部分流量（如 5%–10%）流向新版本，观察指标无异常后再逐步扩大范围，直至全量。若发现问题，立即切回旧版本。 |
| 蓝绿部署 | Blue-Green | 同时维护两套完整环境（蓝/绿），通过切换路由一次性将流量从旧环境（如蓝）全部导向新环境（如绿）。若新环境异常，只需将路由切回旧环境。 |
关键区分：回滚是运行时恢复动作，回退是代码库撤销动作。金丝雀和蓝绿是发布策略，它们通过控制流量切换来避免或最小化回滚的发生。
3.2 区别与联系：四象限对比
以下从作用域、触发时机、影响范围和自动化程度四个维度进行对比：
| 维度 | 回滚（Rollback） | 回退（Revert） | 金丝雀（Canary） | 蓝绿（Blue-Green） |
|---|---|---|---|---|
| 作用域 | 运行时环境（集群、服务、数据） | 代码仓库（Git commit） | 运行时环境 + 流量路由 | 运行时环境 + 流量路由 |
| 触发时机 | 升级后检测到严重故障 | 代码审查或 CI 阶段发现逻辑错误 | 升级过程中实时监控指标 | 升级完成后验证阶段 |
| 影响范围 | 全量用户（短暂中断） | 仅代码库，不影响线上 | 小部分用户（受控） | 全量用户（瞬间切换） |
| 自动化程度 | 全自动或半自动 | 手动或 CI 自动 | 全自动（渐进式） | 全自动（路由切换） |
| 恢复速度 | 分钟级（需重新部署旧版本） | 秒级（git revert 提交） | 秒级（切回旧版本流量） | 秒级（DNS/负载均衡切换） |
联系：在完整的升级流水线中，这四个概念通常串联使用。例如：先通过金丝雀验证新版本，若发现问题则执行回滚；同时开发人员对代码库执行回退修复；而蓝绿部署可以作为回滚的快速切换手段。
3.3 概念关系图
下图展示了四个概念在升级流水线中的位置与关系：
3.4 典型场景对比：何时使用哪种策略？
| 场景 | 推荐策略 | 原因 |
|---|---|---|
| 新功能上线，希望逐步验证 | 金丝雀发布 | 小范围暴露，快速回切，风险最低 |
| 基础设施升级（如 Kubernetes 版本） | 蓝绿部署 | 两套独立环境，切换瞬间完成，回滚无延迟 |
| 代码逻辑错误，需撤销提交 | 回退（Revert） | 不破坏 Git 历史，生成逆向提交，适合 CI 自动触发 |
| 升级后出现严重故障，需立即恢复 | 回滚（Rollback） | 全量恢复，不依赖流量切换，适合紧急情况 |
| 数据库 Schema 变更 | 回滚 + 蓝绿 | 蓝绿环境配合数据库回滚脚本，确保数据一致性 |
常见误区：不要将“回退”等同于“回滚”。回退是代码操作，回滚是运行时操作。在升级流水线中，如果只做了代码回退而没有触发运行时回滚，线上故障依然存在。
3.5 组合使用：流水线中的典型链路
在实际的集群升级流水线中，这四个概念通常按以下顺序组合：
- 代码提交 → 触发 CI 构建。
- 金丝雀发布 → 将新版本部署到 5% 的节点，监控错误率和延迟。
- 蓝绿切换 → 金丝雀验证通过后，将流量全量切换到新环境（绿）。
- 监控验证 → 持续观察 10–30 分钟。
- 回滚（若失败） → 将流量切回旧环境（蓝），同时触发代码回退修复。
这种链路确保了最小化故障影响和快速恢复，是生产级升级流水线的标准实践。