蓝绿发布概述：核心原理与关键机制

蓝绿发布（Blue-Green Deployment）是一种通过维护两套完全独立的生产环境（蓝环境与绿环境）来实现零停机、低风险发布的部署策略。在 Secrets 管理自动化中，蓝绿发布的环境隔离特性对密钥的同步、切换与回滚提出了独特要求。本节从原理、流量切换、环境隔离与回滚策略四个维度展开。

2.1 蓝绿发布原理

蓝绿发布的核心思想是：在任何时刻，只有一套环境（例如蓝环境）承载全部生产流量，另一套环境（绿环境）处于空闲或预热状态。当新版本需要发布时，先在空闲环境中完成部署、配置注入（包括 Secrets）、健康检查与验证，然后通过流量切换将用户流量从当前活跃环境瞬间转移至新环境。

2.2 流量切换机制

流量切换是蓝绿发布的核心操作，通常由负载均衡器、API 网关或 DNS 解析完成。切换粒度可以是全量切换，也可以是灰度百分比切换。在 Secrets 管理场景下，切换时必须确保目标环境的 Secrets 已经过验证且与当前应用版本兼容。

2.3 蓝绿环境隔离

环境隔离是蓝绿发布能够安全运行的基础。两套环境必须在网络、存储、计算资源和 Secrets 存储层面实现逻辑或物理隔离。隔离不当会导致蓝绿环境互相干扰，甚至引发 Secrets 泄露或误用。

• 网络隔离： 蓝绿环境应部署在不同的子网或 VPC 中，通过负载均衡器统一对外暴露。内部服务调用应使用独立的内网 DNS 名称。
• 存储隔离： 数据库、缓存、对象存储等有状态服务应使用不同的实例或命名空间。Secrets 存储（如 Vault、AWS Secrets Manager）应为每个环境配置独立的路径或密钥前缀。
• 计算资源隔离： Kubernetes 命名空间、虚拟机分组或容器集群应严格区分。避免蓝环境的 Pod 意外调度到绿环境的节点上。
• Secrets 隔离： 蓝绿环境必须使用独立的 Secrets 版本或密钥路径。禁止共享同一份密钥文件，防止切换后密钥污染。

2.4 回滚策略

蓝绿发布的回滚策略天然具备优势：由于旧版本环境（例如蓝环境）在切换后并未立即销毁，只需将流量切回原环境即可完成回滚。但在 Secrets 管理场景下，回滚不仅仅是流量切换，还涉及密钥版本的恢复与一致性校验。

回滚流程步骤

1. 触发回滚决策： 监控告警、错误率飙升或人工判断触发回滚。
2. 暂停新流量： 立即停止向新环境（绿环境）发送新请求，避免更多错误。
3. 恢复 Secrets 版本： 将 Secrets 管理系统中的密钥版本回退到切换前的版本（蓝环境使用的版本）。
4. 验证 Secrets 一致性： 检查旧环境中的密钥是否仍然有效，且与当前应用版本兼容。
5. 执行流量切换： 将负载均衡器或网关的流量切回旧环境（蓝环境）。
6. 观察与确认： 监控业务指标，确认回滚成功。
7. 清理异常环境： 保留异常环境（绿环境）用于事后排查，确认问题根因后再销毁。