2. 蓝绿发布架构：双环境架构设计、负载均衡器角色、DNS切换机制
蓝绿发布（Blue-Green Deployment）的核心思想是维护两套完全独立的生产环境——蓝环境（当前运行稳定版本）与绿环境（待发布新版本）。通过负载均衡器与DNS的协同切换，实现零停机、瞬时回滚的发布能力。本节将深入剖析双环境架构设计原则、负载均衡器的关键角色以及DNS切换的机制与风险。
2.1 双环境架构设计
双环境架构要求蓝、绿两套环境在基础设施层面完全隔离，但共享同一套数据库与存储层（或采用兼容的双写/回切策略）。典型架构包含以下核心组件：
| 组件 | 蓝环境（当前稳定） | 绿环境（待发布） |
|---|---|---|
| 应用服务器集群 | 运行 v1.0 代码，处理100%流量 | 运行 v2.0 代码，零流量或内部测试流量 |
| 负载均衡器目标组 | 注册到活跃目标组（Active Target Group） | 注册到备用目标组（Standby Target Group） |
| 数据库/缓存 | 主库读写，从库同步 | 共享主库，或使用独立从库验证 |
| 配置/密钥 | 使用当前生产配置 | 使用新版本配置，需兼容旧数据格式 |
| 监控与日志 | 生产告警链路已激活 | 预生产告警链路，需在切换前激活 |
架构要点：双环境必须使用独立的计算资源（如独立的ECS自动伸缩组、独立的Kubernetes命名空间或集群），避免资源争抢。网络层面建议使用独立的子网或安全组，确保蓝绿环境之间无意外流量串扰。
下图展示了蓝绿双环境的物理与逻辑隔离架构：
2.2 负载均衡器角色
负载均衡器是蓝绿发布的核心流量调度组件。它负责将用户流量精确地导向蓝环境或绿环境，并在切换瞬间完成目标组的原子性变更。主流负载均衡器（如AWS ALB/NLB、Nginx Plus、HAProxy、Kubernetes Ingress Controller）均支持目标组/后端池的动态切换。
2.2.1 负载均衡器在蓝绿发布中的关键职责
- 流量隔离：通过独立的目标组（Target Group）或后端服务器池（Backend Pool）隔离蓝绿环境，确保流量不会意外混流。
- 健康检查：对蓝绿环境分别执行健康检查，只有通过检查的实例才会被纳入流量分发。切换前必须确认绿环境健康检查全部通过。
- 权重切换：支持权重从 100:0 瞬间切换为 0:100，实现原子性流量转移。部分场景支持灰度权重（如 90:10、50:50）用于金丝雀验证。
- 连接耗尽（Connection Draining）：在切换前对蓝环境启用连接耗尽，等待正在处理的请求完成后再断开连接，避免用户请求中断。
- 会话保持（Sticky Session）：若应用依赖会话保持，需在切换时注意会话迁移策略，或使用外部会话存储（如Redis）解耦。
切换原子性：负载均衡器的目标组切换操作必须是原子性的——即所有新连接立即导向新环境，旧环境不再接收新连接。这是实现零停机切换的技术基础。
下表对比了不同负载均衡器在蓝绿发布中的关键能力：
| 负载均衡器类型 | 目标组切换方式 | 连接耗尽支持 | 权重灰度支持 | 健康检查协议 |
|---|---|---|---|---|
| AWS ALB | 修改监听器规则转发至不同目标组 | 是（可配置 deregistration_delay.timeout_seconds） | 是（通过转发规则权重） | HTTP/HTTPS/gRPC |
| AWS NLB | 修改目标组关联 | 是（通过目标组 deregistration_delay） | 否（仅支持单一目标组） | TCP/HTTP/TLS |
| Nginx Plus | 重新加载 upstream 配置（reload） | 是（通过 slow_start 和 max_fails） | 是（通过 upstream 权重配置） | HTTP/TCP |
| HAProxy | 通过 stats socket 动态切换 backend | 是（通过 option http-keep-alive 和 timeout） | 是（通过 server weight 动态调整） | HTTP/TCP |
| Kubernetes Ingress | 修改 Service selector 或使用多个 Service | 是（Pod 终止前等待 terminationGracePeriodSeconds） | 是（通过 Service weight 或 Istio 流量路由） | HTTP/HTTPS |
2.3 DNS切换机制
DNS切换是蓝绿发布的另一种流量调度方式，通常作为负载均衡器切换的补充或替代方案。其核心原理是修改DNS A记录或CNAME记录，将域名解析从蓝环境负载均衡器指向绿环境负载均衡器。
2.3.1 DNS切换的典型流程
- 预切换验证：在绿环境负载均衡器上配置完整TLS证书、健康检查、安全组规则，确认绿环境可正常处理请求。
- 降低TTL：在切换前将DNS记录的TTL（Time To Live）从默认值（如300秒或600秒）临时降低至60秒甚至30秒，加速DNS传播。
- 执行切换：修改DNS记录，将域名解析指向绿环境负载均衡器。等待TTL过期后，新客户端请求将导向绿环境。
- 监控与回滚：持续监控绿环境错误率、延迟、5xx状态码。若发现问题，立即将DNS记录改回蓝环境。
- 恢复TTL：确认绿环境稳定运行后，将DNS TTL恢复为正常值，减少DNS查询频率。
DNS切换的固有风险：由于DNS缓存的存在，切换并非瞬时完成。客户端、递归解析器、中间代理可能缓存旧DNS记录长达TTL时间。这意味着在切换后的TTL窗口期内，部分用户仍会访问蓝环境，造成流量分裂。因此，DNS切换不适合需要严格原子性切换的场景。
下图展示了DNS切换与负载均衡器切换的协同工作流程：
2.3.2 DNS切换 vs 负载均衡器切换
| 对比维度 | DNS切换 | 负载均衡器切换 |
|---|---|---|
| 切换速度 | 受TTL限制，通常30秒~5分钟 | 毫秒级，原子性切换 |
| 原子性 | 非原子性，存在流量分裂窗口 | 原子性，所有新连接瞬间切换 |
| 回滚速度 | 同样受TTL限制，回滚慢 | 毫秒级回滚 |
| 依赖组件 | DNS服务商、域名管理 | 负载均衡器API或配置管理 |
| 适用场景 | 跨区域发布、多云环境、LB无法动态切换时 | 单区域、单LB集群、需要快速回滚 |
| 缓存影响 | 客户端/递归解析器缓存导致流量残留 | 无缓存影响 |
最佳实践：生产环境中推荐以负载均衡器切换为主，DNS切换为辅。在LB切换完成后，再通过DNS切换将域名指向新的LB（如从蓝LB改为绿LB），用于长期流量迁移或LB维护场景。对于需要严格零停机与瞬时回滚的发布，应优先使用负载均衡器目标组切换。
2.4 蓝绿发布架构的关键设计原则
- 环境一致性：蓝绿环境的配置、依赖版本、操作系统补丁、网络策略必须保持一致，避免因环境差异导致发布失败。
- 数据库兼容性：新版本代码必须兼容旧版本数据库Schema，或采用渐进式Schema变更（如向后兼容的列添加、读写分离）。
- 监控全覆盖：绿环境在切换前必须接入完整的监控、告警、日志链路，确保切换后可立即观测到业务指标。
- 回滚预案：每次发布前必须验证回滚流程——将负载均衡器目标组切回蓝环境，并确认蓝环境仍能正常处理流量。
- 成本考量：双环境意味着双倍的计算资源成本。可通过自动伸缩组在非发布期间缩减绿环境实例数量，降低闲置成本。