2. 核心概念：不可变基础设施、蓝绿部署、金丝雀发布、密钥轮换策略

这一章，我们得先把几个地基概念打牢。说白了，后面讲的所有回滚机制和密钥版本控制，都是建立在这些思想之上的。我个人习惯，每次带团队做架构设计时，都会先花半天时间把这几个概念对齐清楚——不然后面全是坑。

2.1 不可变基础设施

这个概念听起来高大上，其实核心思想很简单：一旦部署，绝不修改。

传统服务器运维，我们习惯 SSH 进去，改个配置、打个补丁、升级个包。这叫什么？可变基础设施。你想想看，一个跑了一年的服务器，上面有多少手动改过的痕迹？没人说得清。

不可变基础设施的思路正好相反：

• 每次部署，直接创建全新的实例或容器
• 旧实例直接销毁，绝不原地修改
• 所有配置、代码、依赖，都打包在镜像里

我在项目中遇到过最典型的反面案例：某团队的生产服务器跑了两年，上面有 37 个手动改过的配置文件，没人知道哪些是必要的。后来一次安全审计要求升级 OpenSSL，结果升级后三个服务挂了——因为有人手动改了动态链接库的路径。这就是可变基础设施的代价。

不可变基础设施给回滚带来的最大好处是：回滚就是重新部署上一个版本的镜像。没有残留文件，没有半吊子状态，干净利落。

2.2 蓝绿部署

蓝绿部署，名字很形象。你维护两套完全相同的生产环境：一套叫 Blue，一套叫 Green。

• Blue：当前正在处理流量的环境
• Green：新版本部署的环境，空闲待命

切换的时候，把负载均衡器从 Blue 指向 Green，瞬间完成。如果出问题，再切回 Blue——这就是回滚。

我个人习惯，蓝绿部署最适合的场景是：

1. 数据库变更可以向前兼容（只加字段不改旧字段）
2. 需要秒级回滚
3. 流量可以瞬间切换

嗯，这里要注意：蓝绿部署的回滚速度是所有方案里最快的，但前提是你得提前准备好两套环境。别等到出问题了才去启动 Green——那就晚了。

2.3 金丝雀发布

金丝雀发布的名字来源于煤矿里的金丝雀——先放一只鸟进去，如果鸟死了，人就别进了。

具体做法：

• 先让新版本接收 1%~5% 的流量
• 监控错误率、延迟、业务指标
• 如果一切正常，逐步增加流量比例
• 如果出问题，立即切回旧版本

我记得有一次做电商大促前的版本发布，团队用了金丝雀策略。先放 2% 的流量到新版本，结果发现支付回调接口在高峰期有 3% 的超时。因为只有 2% 的流量受影响，整体影响面极小。我们立刻回滚，修复后重新发布。如果当时是全量发布，那就是事故了。

金丝雀发布的核心依赖：

• 精确的流量路由能力（Service Mesh 或 API Gateway）
• 实时监控和告警
• 自动化的回滚触发机制

2.4 密钥轮换策略

密钥轮换，说白了就是定期更换你的加密密钥、API Token、证书等敏感凭证。为什么要轮换？

• 密钥使用时间越长，泄露风险越大
• 一旦泄露，轮换可以缩小影响范围
• 合规要求（PCI-DSS、SOC2 等）通常强制要求轮换

密钥轮换的核心挑战是：如何在不中断服务的情况下完成轮换。

我常用的策略是双密钥模式：

1. 系统同时持有新旧两个密钥
2. 新密钥先用于加密新数据
3. 旧密钥继续用于解密旧数据
4. 等所有旧数据都被重新加密后，废弃旧密钥

轮换策略	适用场景	回滚难度
手动轮换	低频、非关键系统	高（容易遗漏）
定时自动轮换	常规生产环境	中（需版本管理）
事件驱动轮换	高安全环境（泄露时立即轮换）	低（自动化程度高）

我个人习惯，密钥版本号用时间戳或递增数字，存储在安全的密钥管理服务（KMS）中。应用层只引用版本号，不直接接触密钥明文。这样轮换时，应用层只需要更新版本号引用，不需要重新部署。

2.5 四个概念的关系

这四个概念不是孤立的。它们共同构成了一个完整的回滚保护体系：

你看这张图就明白了：不可变基础设施是底座，保证环境一致性；蓝绿部署和金丝雀发布是部署策略，决定你怎么上线和回滚；密钥轮换是安全防线，确保整个过程中凭证不泄露。

我个人习惯，在设计系统时先确定不可变基础设施的落地方式（容器化还是虚拟机镜像），然后根据业务重要性选择蓝绿或金丝雀，最后把密钥轮换做成自动化流水线的一部分。这样四个概念就串起来了。