2. 蓝绿部署架构：双环境架构图、负载均衡器角色、流量入口设计
蓝绿部署的核心在于维护两套完全独立的生产级环境——蓝环境（Blue）与绿环境（Green），并通过统一的流量入口实现瞬时切换。本节从架构拓扑、负载均衡器职责、流量入口设计三个维度展开，为后续的配置漂移复测奠定基础。
2.1 双环境架构拓扑
蓝绿部署并非简单的两套副本，而是要求两套环境在网络平面、数据存储、配置管理上具备完整的隔离性与一致性。下图展示了标准蓝绿部署的物理与逻辑结构：
2.2 负载均衡器角色与职责
负载均衡器是蓝绿切换的核心执行组件，它负责将用户流量按策略分发至蓝或绿环境。根据部署场景，负载均衡器可以是硬件设备（F5）、云负载均衡（ALB/NLB）或软件反向代理（Nginx/HAProxy/Envoy）。
| 职责维度 | 具体说明 | 关键指标 |
|---|---|---|
| 流量分发 | 根据权重或全量策略，将请求路由至蓝或绿环境的上游服务器组 | 切换延迟 < 1s |
| 健康检查 | 定期探测后端实例的 /healthz 或 /readyz 端点，自动摘除异常节点 | 检查间隔 5s，超时 2s |
| 会话保持 | 可选启用 sticky session，确保切换过程中用户会话不中断 | Cookie 或 IP hash |
| 灰度权重 | 支持蓝:绿 = 90:10 或 50:50 等比例，用于金丝雀发布 | 权重粒度 1% |
| 故障转移 | 当活跃环境整体不可用时，自动将 100% 流量切至备用环境 | 切换触发时间 < 30s |
实践建议：在蓝绿切换前，务必确认负载均衡器的健康检查阈值已调低（如 2 次失败即摘除），避免因健康检查缓存导致流量仍被路由至已下线的环境。
2.3 流量入口设计模式
流量入口决定了用户请求如何到达负载均衡器，以及蓝绿切换对客户端的影响范围。常见的设计模式有三种：
- DNS 切换模式：通过修改 DNS A 记录或 CNAME，将域名指向蓝或绿环境的负载均衡器 VIP。切换生效依赖 DNS TTL，通常需要 60~300 秒传播时间。
- 反向代理模式：在统一的 Nginx/Envoy 网关层通过 upstream 组切换。修改配置文件并 reload 即可瞬时切换，客户端无感知。
- 云负载均衡器后端池切换：在 AWS ALB / GCP HTTP LB 中，将目标组（Target Group）从蓝实例组切换至绿实例组，API 调用后秒级生效。
2.4 流量入口关键配置参数
无论采用哪种入口模式，以下参数必须在蓝绿切换前完成校验：
| 参数 | 推荐值 | 校验方法 |
|---|---|---|
| 健康检查路径 | /healthz 或 /readyz | curl -I http://<instance>/healthz |
| 健康检查间隔 | 5 秒 | 查看 LB 日志或 API 响应 |
| 不健康阈值 | 2 次 | 手动停止实例后观察摘除时间 |
| 会话超时 | 300 秒（可调） | 压测验证 session 保持 |
| 权重步长 | 10% 或 1% | 灰度发布时逐步调整 |
常见陷阱：负载均衡器的健康检查路径如果指向静态页面而非应用真实就绪状态，会导致切换后流量进入尚未完成初始化的实例，引发 502 或超时。务必使用
/readyz 端点，该端点应同时检查数据库连接、缓存预热、依赖服务可达性。
2.5 蓝绿环境隔离要求
双环境架构的有效性建立在严格的隔离边界之上。下表列出必须隔离与可以共享的资源：
| 资源类型 | 隔离要求 | 说明 |
|---|---|---|
| 应用实例 | 完全隔离 | 不同主机/容器组，独立进程空间 |
| 配置文件 | 完全隔离 | 环境变量、ConfigMap、应用配置独立管理 |
| 网络平面 | 逻辑隔离 | 独立 VPC 子网或安全组，避免 IP 冲突 |
| 数据库 | 共享（主从） | 蓝绿共用同一数据库层，但需确保 schema 兼容 |
| 缓存（Redis） | 建议共享 | 切换后缓存命中率不下降，但需注意 key 前缀隔离 |
| 对象存储 | 共享 | 静态资源、日志、备份统一存储 |
架构要点：蓝绿部署的隔离粒度决定了回滚速度。应用层与配置的完全隔离，使得回滚仅需将负载均衡器切回原环境，无需重新部署。数据库层的共享则要求每次发布前必须验证 schema 变更的向后兼容性，否则切换后可能导致蓝环境数据写入异常。