3. 蓝绿发布架构设计:双环境设计、负载均衡器切换、流量管理策略
蓝绿发布的核心思想是维护两套完全独立的生产环境——蓝环境(Blue)和绿环境(Green)。在任何时刻,只有一套环境承载全部生产流量,另一套环境处于待命或部署状态。通过负载均衡器的快速切换,实现零停机发布与即时回滚。
3.1 双环境设计原则
双环境在基础设施层面必须保持对等,避免因环境差异导致发布故障。下表列出了双环境设计的关键维度与要求:
| 维度 | 要求 | 常见反例 |
|---|---|---|
| 硬件规格 | CPU、内存、磁盘类型与容量完全一致 | 蓝环境 8C16G,绿环境 4C8G |
| 软件版本 | 操作系统、内核参数、运行时版本(如 Go、Java)一致 | 蓝环境使用 Ubuntu 20.04,绿环境使用 Ubuntu 22.04 |
| 中间件 | 数据库、缓存、消息队列的版本与配置相同 | 蓝环境连接 Redis 6.x,绿环境连接 Redis 7.x |
| 网络策略 | 安全组规则、ACL、DNS 解析路径一致 | 蓝环境开放 8080 端口,绿环境开放 8081 端口 |
| 监控覆盖 | Prometheus 指标采集、告警规则、日志采集完全对等 | 蓝环境有 PodMonitor,绿环境遗漏 |
实践建议:使用基础设施即代码(IaC)工具(如 Terraform、Pulumi)定义双环境模板,确保每次环境重建后配置一致。在 Prometheus 中为蓝绿环境分别配置独立的 scrape job,通过标签
env="blue" 和 env="green" 区分指标来源。
3.2 负载均衡器切换机制
负载均衡器是蓝绿切换的执行单元。切换的本质是修改流量转发规则,将入口流量从当前活跃环境指向新环境。常见的负载均衡器切换方式包括:
- DNS 切换:修改域名解析记录,将流量指向新环境的 VIP 或负载均衡入口。生效时间受 DNS TTL 影响,通常需要 60~300 秒。
- 反向代理切换:通过 Nginx、HAProxy、Envoy 等代理的动态配置,实时切换 upstream 后端。生效时间在秒级甚至毫秒级。
- 云负载均衡器切换:使用云厂商的 API(如 AWS ALB Target Group、阿里云 SLB)更新后端服务器组。生效时间通常在 10~30 秒。
- Kubernetes Service 切换:修改 Service 的 selector 或直接切换指向不同 Deployment 的 Service。Kube-proxy 同步时间约数秒。
关键指标:在 Prometheus 中监控切换延迟,推荐使用
probe_http_duration_seconds 或自定义 switch_duration_seconds 指标,确保切换时间在 SLA 范围内(例如 < 5 秒)。
3.3 流量管理策略
流量管理策略决定了蓝绿切换的粒度与风险控制方式。根据业务场景,可以选择以下策略:
| 策略 | 描述 | 适用场景 | 风险等级 |
|---|---|---|---|
| 全量切换 | 一次性将 100% 流量从蓝环境切到绿环境 | 低风险发布、内部工具、非核心服务 | 高 |
| 灰度切换 | 按比例逐步迁移流量(如 10% → 50% → 100%) | 核心业务、用户敏感型服务 | 中 |
| 基于 Header/Cookie 切换 | 根据请求头或 Cookie 值将特定用户路由到新环境 | 内部测试、金丝雀发布、A/B 测试 | 低 |
| 基于 IP/地域切换 | 按来源 IP 或地理位置分流 | 多区域部署、合规性要求 | 低 |
在 Prometheus 监控下,流量管理策略需要配合指标验证。例如,灰度切换时通过 env 标签区分请求量:
# 蓝环境请求量
sum(rate(http_requests_total{env="blue"}[5m]))
# 绿环境请求量
sum(rate(http_requests_total{env="green"}[5m]))
# 流量比例计算
sum(rate(http_requests_total{env="green"}[5m])) / (sum(rate(http_requests_total{env="blue"}[5m])) + sum(rate(http_requests_total{env="green"}[5m]))) * 100
3.4 蓝绿发布架构总览
下图展示了蓝绿发布的完整架构,包含双环境、负载均衡器、Prometheus 监控以及切换流程:
3.5 切换流程与 Prometheus 验证
一次标准的蓝绿切换流程包含以下步骤,每一步都应有 Prometheus 指标验证:
- 部署新版本到非活跃环境(例如绿环境)。验证指标:
deployment_duration_seconds、kube_deployment_status_replicas_available。 - 执行冒烟测试,确认新环境健康。验证指标:
probe_success、http_request_duration_seconds。 - 切换负载均衡器,将流量导向新环境。验证指标:
switch_duration_seconds、env标签下的请求比例。 - 观察新环境指标,持续 5~15 分钟。验证指标:错误率
rate(http_requests_total{status=~"5.."})、P99 延迟、CPU 使用率。 - 确认无误后,将旧环境标记为待命状态,保留用于回滚。验证指标:旧环境实例数缩容至最小副本。
回滚触发条件:在步骤 4 的观察期内,如果新环境的错误率超过基线 20% 或 P99 延迟增加超过 50%,应立即执行回滚——将负载均衡器切回旧环境。Prometheus 告警规则示例:
rate(http_requests_total{env="green",status=~"5.."}[1m]) > 0.05。
3.6 蓝绿切换的 Prometheus 告警规则
为保障切换过程安全,建议配置以下告警规则:
groups:
- name: blue_green_switch
rules:
- alert: SwitchDurationTooLong
expr: switch_duration_seconds > 10
for: 1m
labels:
severity: warning
annotations:
summary: "蓝绿切换耗时超过 10 秒"
- alert: GreenEnvErrorRateSpike
expr: rate(http_requests_total{env="green",status=~"5.."}[2m]) > 0.05
for: 1m
labels:
severity: critical
annotations:
summary: "绿环境错误率超过 5%,建议立即回滚"
- alert: TrafficRatioMismatch
expr: abs(sum(rate(http_requests_total{env="green"}[5m])) / (sum(rate(http_requests_total{env="blue"}[5m])) + sum(rate(http_requests_total{env="green"}[5m]))) * 100 - 100) > 5
for: 2m
labels:
severity: warning
annotations:
summary: "绿环境流量比例未达到预期 100%"
通过上述架构设计与监控策略,蓝绿发布能够在 Prometheus 的实时数据支撑下,实现安全、可观测的零停机发布与快速回滚。