3. 蓝绿部署流量切换：DNS切换、反向代理切换、权重调整

蓝绿部署的核心在于流量切换——将用户请求从旧版本（蓝环境）平滑迁移至新版本（绿环境）。切换方式直接影响切换速度、回滚能力与用户体验。本章深入剖析三种主流切换策略：DNS切换、反向代理切换、权重调整，并结合API延迟诊断场景给出最佳实践。

3.1 三种切换策略对比

3.2 DNS切换：全局入口的“慢切换”

DNS切换通过修改域名解析记录，将流量指向新环境IP。其核心机制是TTL（Time To Live）控制缓存生效时间。

3.2.1 切换流程

1. 预切换：将绿环境IP加入DNS记录（如A记录或CNAME），TTL调低至60秒。
2. 切换：修改DNS记录，将蓝环境IP替换为绿环境IP。
3. 等待传播：等待TTL过期 + DNS缓存刷新（通常5-15分钟）。
4. 验证：确认绿环境流量正常，蓝环境可下线。

3.2.2 延迟诊断痛点

• 流量割裂：切换期间，部分用户仍访问蓝环境，部分已切至绿环境，延迟数据混杂。
• 缓存黑洞：某些递归DNS服务器不遵守TTL，导致切换延迟数小时。
• 无法精细控制：无法按请求特征（如用户ID、API路径）分流。

3.3 反向代理切换：API网关的“秒级手术刀”

反向代理（如Nginx、Envoy、HAProxy）通过upstream配置动态切换后端服务器组。这是微服务架构中最常用的切换方式。

3.3.1 Nginx示例：蓝绿upstream切换

# 定义蓝绿两组后端
upstream backend_blue {
    server 10.0.1.10:8080 weight=100;
    server 10.0.1.11:8080 weight=100;
}

upstream backend_green {
    server 10.0.2.10:8080 weight=100;
    server 10.0.2.11:8080 weight=100;
}

# 默认使用蓝环境
server {
    listen 80;
    location /api/ {
        proxy_pass http://backend_blue;
        # 切换时只需将 backend_blue 改为 backend_green
        # 并执行 nginx -s reload
    }
}

3.3.2 切换步骤与延迟监控

3.4 权重调整：渐进式灰度切换

权重调整通过逐步增加绿环境流量比例，实现灰度发布。这种方式最适合API延迟诊断，因为可以在同一时间窗口内对比蓝绿环境的延迟表现。

3.4.1 权重调整策略

• 5% → 20% → 50% → 100%：典型渐进步骤，每阶段观察10-15分钟。
• 基于延迟的自动调整：如果绿环境P99延迟超过蓝环境20%，自动暂停权重增加。
• 回滚权重：一旦发现延迟异常，立即将权重归零，流量全部切回蓝环境。

3.4.2 Nginx权重配置示例

upstream backend {
    # 初始：蓝100%，绿0%
    server 10.0.1.10:8080 weight=100;  # 蓝
    server 10.0.2.10:8080 weight=0;    # 绿

    # 第一阶段：蓝80%，绿20%
    # server 10.0.1.10:8080 weight=80;
    # server 10.0.2.10:8080 weight=20;

    # 第二阶段：蓝50%，绿50%
    # server 10.0.1.10:8080 weight=50;
    # server 10.0.2.10:8080 weight=50;

    # 最终：蓝0%，绿100%
    # server 10.0.1.10:8080 weight=0;
    # server 10.0.2.10:8080 weight=100;
}

3.5 流量切换与延迟诊断的集成架构

下图展示了蓝绿部署中流量切换与延迟诊断的完整数据流：

3.6 切换策略选择矩阵

根据不同的部署场景与延迟诊断需求，推荐以下选择矩阵：

3.7 实战建议：延迟诊断视角的切换最佳实践

• 切换前：在反向代理层开启全量请求日志，记录每个请求的upstream响应时间、状态码、目标环境（蓝/绿）。
• 切换中：使用权重调整，每10分钟增加20%流量，每次增加后观察延迟分布。如果绿环境P99延迟超过蓝环境基线15%，暂停切换并告警。
• 切换后：保留蓝环境至少30分钟，期间持续对比延迟指标。确认无异常后再下线蓝环境。
• 自动化：将切换流程集成到CI/CD管道，结合监控系统自动判断是否继续或回滚。