3. 蓝绿环境架构：蓝环境与绿环境定义、负载均衡器角色、DNS切换原理
蓝绿部署的核心在于维护两套完全独立的生产级环境——蓝环境（Blue）与绿环境（Green）。在任何时刻，只有其中一套环境承载全部在线流量，另一套则处于待命或预热状态。这种架构通过负载均衡器与DNS切换实现流量的瞬间转移，从而达成零停机发布与快速回滚。
3.1 蓝环境与绿环境定义
| 维度 | 蓝环境（Blue） | 绿环境（Green） |
|---|---|---|
| 运行状态 | 当前承载全部生产流量（Active） | 空闲或预热中（Standby / Pre-warmed） |
| 应用版本 | 当前稳定版本（v1.0） | 新版本候选（v2.0） |
| 数据库状态 | 读写生产数据库 | 通常共享同一数据库，或使用独立只读副本 |
| 网络策略 | 开放公网入口，安全组规则严格 | 仅允许内部/测试流量，公网入口关闭 |
| 回滚能力 | 切换后即成为回滚目标 | 切换后即成为新生产环境 |
关键原则：蓝绿环境在基础设施层面（计算、网络、存储）必须保持配置一致，差异仅体现在应用版本与流量路由上。任何环境漂移都会导致切换后出现非预期行为。
3.2 负载均衡器角色
负载均衡器是蓝绿架构的流量中枢，负责将用户请求精确路由到当前活跃环境。其核心职责包括：
- 流量分发：根据预设权重（如 100:0 或 0:100）将请求转发至蓝或绿环境的后端实例池。
- 健康检查：定期探测后端服务的 /health 端点，自动摘除异常实例，确保流量只到达健康节点。
- 连接耗尽（Connection Draining）：在切换前，允许旧环境中的正在处理请求完成，再切断连接，避免用户会话中断。
- 灰度权重调整：支持从 100:0 逐步过渡到 0:100，实现金丝雀式流量迁移。
实践建议：在云原生环境中，优先使用应用层负载均衡器（如 AWS ALB、GCP HTTP(S) LB、Nginx Plus），它们支持基于路径、主机头、Cookie 的精细化路由，便于蓝绿切换与灰度发布策略组合。
3.3 DNS切换原理
DNS切换是蓝绿部署中最外层的流量控制手段，通常作为负载均衡器切换的补充或备用方案。其工作原理如下：
- 记录映射：将业务域名（如 app.example.com）通过 CNAME 或 ALIAS 记录指向当前活跃环境的负载均衡器 DNS 名称。
- TTL控制：在切换前将 DNS 记录的 TTL（生存时间）临时降低至 60 秒甚至 30 秒，加速全球 DNS 缓存刷新。
- 记录更新：将 CNAME 目标从蓝环境负载均衡器切换为绿环境负载均衡器。
- 缓存等待：等待 TTL 过期 + 传播延迟（通常 1~5 分钟），新流量逐渐导向绿环境。
- 验证与回滚：确认绿环境运行正常后，将 TTL 恢复为常规值（如 300 秒）；若异常，立即将 CNAME 切回蓝环境。
风险提示：DNS 切换存在最终一致性问题——由于客户端和递归解析器的缓存，部分用户可能在 TTL 窗口期内仍访问旧环境。因此，DNS 切换不适合需要毫秒级精确切换的场景，通常与负载均衡器权重切换配合使用，作为兜底回滚手段。
3.4 蓝绿切换决策矩阵
| 切换方式 | 切换速度 | 精确性 | 回滚速度 | 适用场景 |
|---|---|---|---|---|
| 负载均衡器权重切换 | 秒级 | 精确到每个请求 | 秒级 | 生产环境主切换、灰度发布 |
| DNS CNAME 切换 | 分钟级（TTL 依赖） | 受缓存影响 | 分钟级 | 跨区域容灾、负载均衡器故障兜底 |
| 混合策略 | 秒级 + 分钟级 | 高（双重保障） | 秒级回滚 LB，分钟级回滚 DNS | 关键业务、金融、医疗等合规场景 |
架构总结：蓝环境与绿环境是部署的物理基础，负载均衡器是切换执行者，DNS 是全局流量入口。三者协同工作，才能实现安全、快速、可回滚的蓝绿发布。在流水线集成中，CI/CD 系统应自动编排负载均衡器权重调整与 DNS 记录更新，并将健康检查结果作为切换的准入条件。