2. 蓝绿发布基础：部署模式原理、流量切换机制与环境隔离设计
2.1 蓝绿部署模式核心原理
蓝绿部署（Blue-Green Deployment）是一种通过维护两套完全独立的生产环境来实现零停机发布的策略。两套环境分别称为蓝环境（当前稳定版本）和绿环境（新版本候选），在任何时刻只有一套环境承载全部生产流量。
核心思想： 流量瞬间切换而非逐步滚动。切换失败时，只需将流量切回原环境即可完成回滚，无需重新部署旧版本。
| 特性 | 蓝环境（Blue） | 绿环境（Green） |
|---|---|---|
| 状态 | 当前生产流量指向 | 新版本部署就绪，待验证 |
| 版本 | 稳定运行版本（v1.0） | 待发布版本（v2.0） |
| 数据库 | 兼容旧 Schema | 需与蓝环境共享或双向兼容 |
| 流量权重 | 100% | 0%（验证阶段可内部测试） |
| 回滚方式 | 无需操作（流量已在蓝环境） | 流量切回蓝环境即可 |
2.2 流量切换机制
流量切换是蓝绿部署的核心操作，决定了发布速度与风险控制能力。切换粒度可从DNS 解析到负载均衡器权重，再到服务网格路由规则。
2.2.1 三种主流切换方式对比
| 切换方式 | 切换速度 | 回滚速度 | 适用场景 | 风险等级 |
|---|---|---|---|---|
| DNS 切换 | 分钟级（TTL 生效） | 分钟级（DNS 缓存） | 简单 Web 服务、静态站点 | 中 |
| 负载均衡器切换 | 秒级（API 调用） | 秒级（权重调整） | 微服务、API 网关 | 低 |
| 服务网格路由切换 | 毫秒级（控制面下发） | 毫秒级（规则回退） | Istio/Linkerd 网格环境 | 极低 |
2.2.2 负载均衡器切换流程（推荐）
- 预验证阶段：绿环境部署完成后，通过内部端点或 Header 标记进行功能验证。
- 权重调整：将绿环境权重从 0% 逐步提升至 100%（如 10% → 50% → 100%），观察错误率。
- 全量切换：确认绿环境稳定后，将蓝环境权重降为 0%，绿环境承载全部流量。
- 蓝环境保留：蓝环境保持运行状态，作为回滚目标。
最佳实践：切换过程中建议开启 金丝雀验证窗口，在绿环境权重达到 100% 后保持 5-10 分钟观察期，确认无异常后再关闭蓝环境。
2.3 蓝绿环境隔离设计
环境隔离是蓝绿部署成功的基石。两套环境必须在计算资源、网络、数据层三个维度实现有效隔离，同时保持必要的共享能力。
2.3.1 隔离维度矩阵
| 隔离维度 | 隔离策略 | 共享策略 | 注意事项 |
|---|---|---|---|
| 计算资源 | 独立 Kubernetes Namespace / 独立主机组 | 共享集群控制面 | 资源配额需分别设置 |
| 网络 | 独立 Service / 独立负载均衡器 | 共享入口网关 IP | 路由规则必须精确匹配 |
| 数据层 | 独立数据库实例或 Schema | 共享消息队列（可选） | Schema 变更必须向前兼容 |
| 配置 | 独立 ConfigMap / 独立环境变量 | 共享密钥管理服务 | 配置差异需自动化同步 |
| 监控 | 独立指标标签（env=blue/green） | 共享 Prometheus/Grafana | 告警规则需区分环境 |
2.4 数据库兼容性设计
数据库是蓝绿部署中最棘手的部分。由于两套环境可能同时操作同一数据集，Schema 变更必须遵循向前兼容原则。
关键约束： 绿环境的新 Schema 必须能被蓝环境的旧代码正确读写。任何破坏性变更（如删除列、重命名表）都必须拆分为多个兼容步骤。
2.4.1 兼容性变更步骤示例
| 阶段 | 操作 | 蓝环境兼容性 | 绿环境兼容性 |
|---|---|---|---|
| 1. 扩展 | 新增列（允许 NULL 或默认值） | ✅ 可读可写 | ✅ 可读可写 |
| 2. 迁移 | 绿环境写入新列，蓝环境忽略 | ✅ 可读可写 | ✅ 可读可写 |
| 3. 切换 | 流量切至绿环境 | ✅ 只读（保留回滚） | ✅ 可读可写 |
| 4. 清理 | 蓝环境关闭后，删除旧列 | ❌ 已下线 | ✅ 可读可写 |
2.5 自动化驱动开发切入点
蓝绿部署的自动化驱动开发（ADD）需要覆盖以下关键环节：
- 环境编排：通过 Terraform / Pulumi 声明式定义蓝绿两套基础设施。
- 流量切换 API：封装负载均衡器或服务网格的路由变更接口为 Python SDK。
- 健康检查自动化：部署后自动执行冒烟测试套件，通过/失败决定是否切换。
- 回滚触发器：监控指标异常时自动触发流量切回蓝环境。