2. 流量切换基础：DNS切换、负载均衡器切换、反向代理切换的原理与差异

在蓝绿部署与灰度发布中，流量切换是决定 MTTR 的核心环节。不同的切换层（DNS、负载均衡器、反向代理）在生效速度、粒度、安全性和可观测性上存在本质差异。本章从原理出发，逐一拆解三种切换方式的机制与适用场景。

2.1 DNS 切换：全局生效，但受缓存制约

DNS 切换通过修改域名解析记录（A 记录 / CNAME）将流量指向新环境。其核心优势在于无需修改应用架构，但生效时间受 TTL（Time To Live）和客户端 DNS 缓存影响。

2.2 负载均衡器切换：四层流量调度

负载均衡器（如 AWS NLB、GCP TCP/UDP LB、F5、LVS）工作在 OSI 第四层（传输层），基于 IP + 端口转发流量。切换时只需修改后端服务器池的成员关系，无需等待 DNS 缓存，生效时间通常在秒级。

• 切换粒度：IP 级别，无法识别 HTTP 请求头或 Cookie。
• 会话保持：依赖源 IP Hash 或 sticky session，切换时可能导致会话中断。
• 健康检查：支持 TCP 端口探测，可自动摘除异常后端。
• 典型场景：数据库读写分离、TCP 长连接服务、游戏服务器。

2.3 反向代理切换：七层精细化控制

反向代理（Nginx / HAProxy / Envoy）工作在第七层（应用层），可解析 HTTP 请求头、Cookie、URI 等。切换时通过修改 upstream 配置或动态路由规则实现灰度、金丝雀、A/B 测试等复杂策略。

# Nginx 蓝绿切换示例：通过 weight 控制流量比例
upstream backend {
    server 10.0.1.10:8080 weight=90;  # 蓝环境（旧）
    server 10.0.2.10:8080 weight=10;  # 绿环境（新）
}

server {
    listen 80;
    location / {
        proxy_pass http://backend;
        proxy_set_header Host $host;
    }
}

# 切换命令：修改 weight 后 reload
# nginx -s reload

# HAProxy 蓝绿切换示例：通过 Runtime API 动态调整
backend blue-green
    balance roundrobin
    server blue 10.0.1.10:8080 weight 100 check
    server green 10.0.2.10:8080 weight 0 check

# 动态切换命令（通过 socat 或 haproxy-runtime-api）
# echo "set server blue-green/green weight 100" | socat stdio /var/run/haproxy.sock
# echo "set server blue-green/blue weight 0" | socat stdio /var/run/haproxy.sock

2.4 三种切换方式的核心差异对比