蓝绿部署架构设计：负载均衡器、蓝绿环境、数据库切换策略

蓝绿部署的核心思想是维护两套完全独立的生产环境——蓝环境（当前运行版本）与绿环境（新版本候选）。通过负载均衡器在两者间瞬间切换流量，实现零停机发布。本章聚焦于该架构的三个关键组件：负载均衡器、蓝绿环境与数据库切换策略。

1. 架构总览：蓝绿部署三层模型

一个标准的蓝绿部署架构由三层构成：流量入口层、应用环境层、数据持久层。下图展示了这三层之间的交互关系与切换路径。

2. 负载均衡器：流量切换的枢纽

负载均衡器是蓝绿部署的“交通警察”，负责将用户流量导向当前活跃的环境。其核心职责包括：

• 健康检查：定期探测蓝绿环境的健康端点（如 /health），自动摘除异常实例。
• 权重路由：支持将流量按权重分配，可用于金丝雀发布（如 5% 流量到绿环境）。
• 会话保持：可选启用 sticky session，确保切换过程中用户会话不中断。
• 零秒切换：通过更新 upstream 配置或 DNS 解析，瞬间完成流量重定向。

3. 蓝绿环境：基础设施即代码

蓝环境与绿环境在基础设施层面必须保持完全对等：相同的实例规格、网络配置、环境变量、日志采集、监控告警。差异仅在于部署的应用程序版本。

环境配置清单示例：

# 蓝环境（当前生产）
BLUE_ASG: min=6, max=12, instance_type=t3.large
BLUE_DB_ENDPOINT: db-blue.cluster-xxx.rds.amazonaws.com
BLUE_REDIS_ENDPOINT: redis-blue.xxx.ng.0001.use1.cache.amazonaws.com
BLUE_DEPLOY_TAG: v1.2.0

# 绿环境（新版本候选）
GREEN_ASG: min=6, max=12, instance_type=t3.large
GREEN_DB_ENDPOINT: db-green.cluster-xxx.rds.amazonaws.com
GREEN_REDIS_ENDPOINT: redis-green.xxx.ng.0001.use1.cache.amazonaws.com
GREEN_DEPLOY_TAG: v1.3.0

4. 数据库切换策略：最棘手的环节

数据库是蓝绿部署中最具挑战的组件。应用代码可以瞬间切换，但数据库 schema 变更往往需要向前/向后兼容。以下是三种主流策略：

4.1 共享数据库 + 兼容模式（推荐）

蓝绿环境共享同一个数据库实例，但新版本的 schema 变更必须兼容旧版本。例如：只新增列（允许 NULL 或默认值），不删除列，不改动已有索引类型。

• 优点：切换瞬间完成，无需数据迁移。
• 缺点：限制了 schema 变更的自由度，需要严格的代码审查。
• 适用：大多数微服务场景，尤其是 API 层。

4.2 独立数据库 + 数据同步

蓝绿环境各自拥有独立的数据库实例，通过数据同步工具（如 Debezium、AWS DMS）保持双向或单向同步。

• 优点：schema 可以完全独立，支持破坏性变更。
• 缺点：同步延迟可能导致数据不一致；切换后需要处理“追赶同步”。
• 适用：离线分析、报表系统、非核心业务。

4.3 读写分离 + 灰度切换

将数据库操作拆分为读流量和写流量。读流量先切换到新环境，写流量保持旧环境，观察一段时间后再切换写流量。

• 优点：风险最低，可逐步验证新版本的数据处理逻辑。
• 缺点：架构复杂度高，需要应用层支持读写分离路由。
• 适用：核心交易系统、金融支付场景。

5. 切换流程与回滚机制

一次标准的蓝绿切换流程包含以下步骤：

1. 预部署：在绿环境部署新版本应用，执行自动化集成测试。
2. 预健康检查：验证绿环境的 API 延迟、错误率、资源使用率。
3. LB 切换：将负载均衡器的 upstream 从蓝环境切换到绿环境。
4. 观测窗口：保持观测 15-30 分钟，监控关键业务指标。
5. 蓝环境回收：确认稳定后，将蓝环境缩容或保留为回滚环境。

回滚操作是蓝绿部署的核心优势：只需将 LB 切回蓝环境即可，通常耗时不超过 1 秒。

6. 延迟诊断：蓝绿切换中的关键指标

在蓝绿切换过程中，API 延迟是衡量切换是否成功的核心指标。建议在切换前后持续采集以下数据：

• P50 / P95 / P99 延迟：切换后 P99 不应超过切换前的 1.2 倍。
• 错误率：5xx 错误率应保持为 0，4xx 错误率不应异常升高。
• 数据库连接池使用率：切换后绿环境的连接池使用率应平稳，无陡增。
• 慢查询数量：新版本可能引入新的查询模式，需监控慢查询日志。