2. 蓝绿发布架构详解：蓝环境与绿环境的定义、负载均衡器/路由切换机制、数据层兼容性设计
2.1 蓝环境与绿环境的定义与角色
蓝绿发布的核心思想是维护两套完全独立的生产环境——蓝环境（Blue）与绿环境（Green）。在任何时刻，只有一套环境承载全部生产流量，另一套环境处于待命或部署状态。这种物理隔离的设计从根本上消除了“部署中”与“运行中”的冲突。
| 维度 | 蓝环境（Blue） | 绿环境（Green） |
|---|---|---|
| 当前状态 | 承载 100% 生产流量（活跃） | 空闲或正在部署新版本（待命） |
| 版本 | 稳定版本（v1.0） | 新版本（v2.0） |
| 资源规模 | 与生产容量一致 | 与生产容量一致 |
| 数据库连接 | 连接生产数据库（主库） | 连接生产数据库（兼容模式） |
| 切换后角色 | 变为待命环境，保留旧版本用于回滚 | 变为活跃环境，承载 100% 流量 |
关键原则：蓝绿环境必须保持配置对称性——CPU、内存、实例数、网络策略、日志采集等基础设施配置完全一致。任何不对称都会导致切换后出现容量或行为差异，增加故障定位难度。
2.2 负载均衡器与路由切换机制
路由切换是蓝绿发布的核心操作，由负载均衡器（LB）或网关层完成。切换的本质是修改流量分发规则，将入口流量从蓝环境的目标组/后端池，原子性地指向绿环境。
2.2.1 常见切换模式
- DNS 切换：修改 DNS A 记录或 CNAME，指向绿环境的 VIP。生效依赖 TTL，存在分钟级延迟，不适合快速回滚。
- 负载均衡器后端池切换：在 ALB/NGINX/Envoy 中更新 upstream 或 target group，将流量从 Blue 池切换到 Green 池。切换可在秒级完成，支持健康检查联动。
- 流量权重灰度切换：逐步调整权重（如 10% → 50% → 100%），用于金丝雀验证。蓝绿发布通常要求一次性全切，但权重切换可作为前置验证步骤。
MTTR 关键指标：路由切换的原子性直接影响故障恢复时长。如果切换操作需要手动修改多个配置项（如 LB + DNS + 防火墙规则），MTTR 会显著增加。建议将切换封装为一键式自动化操作，并记录切换耗时作为 SLO 指标。
2.3 数据层兼容性设计
数据层是蓝绿发布中最容易引发故障的环节。两套环境共享同一数据库，新版本（绿环境）的代码可能读写与旧版本（蓝环境）不兼容的数据结构。一旦切换后发现问题需要回滚，数据状态可能已被新版本污染，导致回滚失败或数据丢失。
2.3.1 兼容性设计原则
- 向前兼容（Backward Compatible）：新版本代码必须能正确读写旧版本写入的数据。数据库 Schema 变更必须采用增量兼容模式：只新增列（允许 NULL 或默认值），不删除/重命名列，不修改列类型。
- 向后兼容（Forward Compatible）：旧版本代码在回滚后，必须能处理新版本写入的数据。这意味着新版本写入的数据格式不能破坏旧版本的读取逻辑。
- 双写/双读策略：在 Schema 变更期间，新版本同时写入新旧两种格式的数据，或通过特性开关控制写入路径，确保两套环境都能正确读取。
| 变更类型 | 兼容性要求 | 典型风险 | 推荐做法 |
|---|---|---|---|
| 新增列 | 高（允许 NULL/默认值） | 低 | 直接执行 ALTER TABLE ADD COLUMN |
| 删除列 | 低（破坏向前兼容） | 高 | 标记废弃，两个发布周期后再删除 |
| 修改列类型 | 低（可能导致数据截断） | 极高 | 新增列 + 数据迁移 + 逐步切换 |
| 新增索引 | 高（只读操作） | 低 | 在线创建（CONCURRENTLY） |
| 修改存储过程/函数 | 中（需版本共存） | 中 | 使用版本化命名（如 get_user_v2） |
故障案例警示：某团队在蓝绿发布中执行了 RENAME COLUMN 操作，绿环境新代码使用新列名写入数据。回滚后，蓝环境旧代码无法识别新列名，导致所有写入操作报错，最终需要从备份恢复数据，MTTR 超过 4 小时。教训：永远不要在蓝绿发布周期内执行破坏性 Schema 变更。
2.3.2 数据层兼容性策略矩阵
根据变更风险等级，选择不同的数据层策略：
- 低风险变更（新增列、新增索引）：在切换前预先执行 DDL，两套环境共享同一 Schema。
- 中风险变更（新增表、新增函数）：使用特性开关（Feature Flag）控制新代码路径，切换后逐步放开。
- 高风险变更（列类型修改、数据迁移）：采用扩展-迁移-收缩（Expand-Migrate-Contract）模式，分多个发布周期完成。
2.4 架构设计对 MTTR 的影响
蓝绿发布的架构设计直接决定了故障发生时的恢复速度。以下是关键设计决策与 MTTR 的关联：
- 切换原子性：一键切换 vs. 多步操作 → 影响 MTTR 分钟级 vs. 小时级。
- 数据层兼容性：兼容 Schema 变更 → 回滚无需数据修复，MTTR 低；不兼容变更 → 回滚需数据回档，MTTR 显著增加。
- 环境对称性：配置一致 → 切换后无容量异常；配置不一致 → 切换后触发级联故障，MTTR 延长。
- 可观测性覆盖：两套环境独立监控 → 快速定位故障环境；监控缺失 → 需要人工排查，MTTR 不可控。
MTTR 度量建议：在蓝绿发布架构中，建议将切换耗时和回滚耗时作为两个独立的 MTTR 子指标进行监控。切换耗时反映自动化程度，回滚耗时反映数据层兼容性设计的质量。理想目标：切换耗时 < 30 秒，回滚耗时 < 60 秒。