两种维护思路
不可变（immutable）思路把服务器或容器当作制品：需要升级时构建新版本镜像或镜像模板，起新实例、切流量、销毁旧实例，现场不修改。配置管理（configuration management）思路则承认节点会长期存在，通过工具周期性收敛节点状态。前者的回退是「切回上一个制品」，后者是「改回上一个配置值」。选择取决于节点生命周期、变更频率与是否允许替换。
基本信息
| 不可变载体 | 镜像、镜像模板、容器镜像与发布制品 |
|---|---|
| 配置管理载体 | 状态描述文件、角色与模块任务 |
| 回退方式 | 切换制品版本 与 恢复配置值 |
| 判断依据 | 节点生命周期、替换成本、变更频率 |
选择依据
- 容器与弹性伸缩环境：天然适合不可变，替换成本低、启动快。
- 长期运行的物理机：替换成本高，配置管理与补丁维护更实际。
- 网络设备：不支持重建式交付，只能走配置管理与模板化。
- 需要快速回退的发布：不可变配合灰度切流更简单。
- 配置频繁微调的中间件：配置管理改一处即收敛，重建反而更慢。
- 混合环境：对弹性部分不可变，对固定部分配置管理，边界写进规范即可。
两种方式对比
| 对比项 | 不可变基础设施 | 配置管理 |
|---|---|---|
| 变更方式 | 构建新制品并替换 | 就地收敛现有节点 |
| 回退 | 切回上一制品 | 恢复上一配置值 |
| 漂移 | 节点被替换，漂移自然消失 | 需持续检测与收敛 |
| 启动开销 | 每次替换需重建 | 改动小、开销低 |
| 适用生命周期 | 短、可替换 | 长、难替换 |
| 常见场景 | 容器、弹性集群 | 物理机、网络设备、传统中间件 |
两条路线可以组合：常见做法是镜像里只放不变的运行时，具体环境配置在启动时注入，避免为每个环境构建一份镜像，也避免把环境差异写进镜像造成不可复用。
不可变不等于免维护：镜像本身仍需版本管理、漏洞扫描与清理，否则旧镜像堆积会产生存储与合规问题。