4. 环境架构设计：生产环境（蓝/绿集群）、预发环境、灰度环境的网络拓扑与资源规划

在自动化变更冻结闸口的蓝绿发布体系中，环境架构是保障发布安全、流量平滑切换与快速回滚的物理基础。本章聚焦于生产环境（蓝/绿集群）、预发环境与灰度环境的网络拓扑设计、资源隔离策略与容量规划原则，确保每一套环境都能独立承载流量并支持自动化闸口的决策调度。

4.1 环境角色与隔离原则

四套核心环境承担不同的发布阶段职责，其隔离级别与网络策略直接影响变更冻结闸口的判定逻辑。

4.2 网络拓扑架构设计

网络拓扑采用“统一入口 → 流量调度层 → 环境路由层 → 应用集群”的分层模型。全局负载均衡器（GSLB）与七层反向代理（Nginx/Envoy）协同实现蓝/绿切换与灰度分流。

4.3 蓝/绿集群资源规划

蓝/绿集群的资源规划必须遵循“对称部署、独立故障域”原则。以下为典型中大规模生产环境的资源清单：

4.4 灰度环境部署模型

灰度环境并非独立的全量集群，而是基于绿集群的“子集”或“染色节点”。常见的灰度部署模型有两种：

• 节点级灰度：从绿集群中划出 2~3 个节点，通过 Nginx 的 split_clients 或 Envoy 的 weighted clusters 将 5%~10% 用户流量路由至这些节点。其余绿集群节点保持空闲或运行基准验证。
• 命名空间级灰度（Kubernetes）：在绿集群的命名空间内创建独立的 Deployment（如 app-green-canary），副本数设为总副本的 10%，通过 Service Mesh 的流量权重分配实现精细灰度。

# Nginx 灰度分流配置示例
split_clients "${remote_addr}${http_user_agent}" $canary_group {
    10%     canary;
    *       stable;
}

location / {
    if ($canary_group = "canary") {
        proxy_pass http://green-canary-backend;
        break;
    }
    proxy_pass http://blue-backend;
}

4.5 预发环境与生产环境的网络策略

预发环境需要模拟生产网络拓扑，但必须严格隔离以避免数据污染。推荐以下网络策略：

4.6 自动化闸口与环境的交互流程

变更冻结闸口在环境架构中充当“流量阀门”角色，其决策路径如下：

1. 部署前检查：闸口验证预发环境的集成测试结果、数据兼容性报告、安全扫描状态。任一失败则冻结绿集群部署。
2. 灰度放行：绿集群部署完成后，闸口自动将 5% 流量导入灰度节点，持续观测 10 分钟错误率（< 0.1%）与 P99 延迟（< 基线 + 10%）。
3. 全量切换：灰度验证通过后，闸口修改 GSLB 或七层代理的权重，将 100% 流量从蓝集群切换至绿集群。切换采用“步进式”（每 10% 递增，间隔 30 秒），期间持续监控。
4. 回滚触发：若切换后 5 分钟内错误率或延迟超过阈值，闸口自动将流量切回蓝集群，并冻结绿集群进入“故障调查”状态。

4.7 资源规划检查清单

在环境架构落地前，建议逐项核对以下清单，确保蓝/绿发布体系的基础设施就绪：

• 对称性：蓝/绿集群的节点数、规格、网络带宽是否完全一致？
• 故障域：蓝/绿集群是否部署在不同的物理机架、交换机或可用区？
• 连接池预热：绿集群启动时是否触发数据库连接池与缓存连接池的预热脚本？
• 灰度标签：七层代理是否支持基于 Header/Cookie/IP 的灰度路由规则？
• 监控覆盖：预发、灰度、蓝、绿四套环境是否都有独立的错误率、延迟、吞吐量监控？
• 闸口脚本：自动化闸口能否通过 API 读取各环境的健康状态与指标数据？