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 监控以及切换流程:

蓝绿发布架构总览 用户请求 DNS / 域名解析 负载均衡器 Nginx / HAProxy / ALB / Envoy 蓝环境 (Blue) 当前活跃 应用实例 v1.0.0 数据库 / 缓存 / 消息队列 绿环境 (Green) 待发布 / 待命 应用实例 v1.1.0 数据库 / 缓存 / 消息队列 Prometheus 监控 实线:当前流量路径 虚线:待切换路径

3.5 切换流程与 Prometheus 验证

一次标准的蓝绿切换流程包含以下步骤,每一步都应有 Prometheus 指标验证:

  1. 部署新版本到非活跃环境(例如绿环境)。验证指标:deployment_duration_seconds、kube_deployment_status_replicas_available。
  2. 执行冒烟测试,确认新环境健康。验证指标:probe_success、http_request_duration_seconds。
  3. 切换负载均衡器,将流量导向新环境。验证指标:switch_duration_seconds、env 标签下的请求比例。
  4. 观察新环境指标,持续 5~15 分钟。验证指标:错误率 rate(http_requests_total{status=~"5.."})、P99 延迟、CPU 使用率。
  5. 确认无误后,将旧环境标记为待命状态,保留用于回滚。验证指标:旧环境实例数缩容至最小副本。
回滚触发条件:在步骤 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 的实时数据支撑下,实现安全、可观测的零停机发布与快速回滚。