Nginx 负载均衡多机集群切流量演练方案

目标： 逐步切换流量，确保新环境稳定，防止一次性切换导致业务中断。
适用场景： 多台后端服务器，通过 Nginx 进行流量调度。

---

1. 现状分析 & 目标切换方式

假设当前 Nginx 负载均衡的架构如下：

• 老环境（现有服务器）：
  • 192.168.1.101
  • 192.168.1.102
• 新环境（目标服务器）：
  • 192.168.1.201
  • 192.168.1.202
  • 192.168.1.203

切换目标

• 方式 1：逐步增加新环境的权重（灰度发布） ✅ 推荐
• 方式 2：按照用户分流（AB 测试）
• 方式 3：一次性切换（高风险，需回滚方案）

---

2. 逐步增加新环境的权重（灰度发布）

修改 Nginx upstream

upstream backend {
    # 现有老环境（初始时保持较高权重）
    server 192.168.1.101 weight=3;
    server 192.168.1.102 weight=3;
    
    # 新环境（初始时低权重，逐步提升）
    server 192.168.1.201 weight=1;
    server 192.168.1.202 weight=1;
    server 192.168.1.203 weight=1;
}

切换流程

1. 初始配置（老环境权重较高）

   • 老环境 80% 流量
   • 新环境 20% 流量

2. 10 分钟后，调整新环境权重

   upstream backend {
       server 192.168.1.101 weight=2;
       server 192.168.1.102 weight=2;
       server 192.168.1.201 weight=2;
       server 192.168.1.202 weight=2;
       server 192.168.1.203 weight=2;
   }
   

   • 老环境 50% 流量
   • 新环境 50% 流量

3. 30 分钟后，完全切换至新环境

   upstream backend {
       server 192.168.1.201 weight=3;
       server 192.168.1.202 weight=3;
       server 192.168.1.203 weight=3;
   }
   

   • 老环境 0%
   • 新环境 100%

⚠️ 注意： 每次调整权重后，都要执行：

nginx -t && systemctl reload nginx

并观察日志，确认无误再继续下一步。

---

3. 按用户分流（AB 测试）

如果想让部分用户先体验新环境，可以按照 IP、Cookie 或 Header 来分流：

map $cookie_test_user $backend_group {
    ~^test_group backend_new;
    default backend_old;
}

upstream backend_new {
    server 192.168.1.201;
    server 192.168.1.202;
    server 192.168.1.203;
}

upstream backend_old {
    server 192.168.1.101;
    server 192.168.1.102;
}

server {
    listen 80;
    location / {
        proxy_pass http://$backend_group;
    }
}

步骤：

1. 先给测试用户设置 Cookie

   curl -b "test_user=test_group" http://your-service/
   

2. 监控新环境访问日志

   tail -f /var/log/nginx/access.log | grep backend_new
   

---

4. 监控切换情况

切流量时，重点监控日志、后端健康状态、业务异常率。

监控 Nginx 访问日志

查看访问 IP 统计，确认流量是否正确进入新服务器：

awk '{print $1}' /var/log/nginx/access.log | sort | uniq -c

如果发现新环境 IP 访问量过低，可能是 Nginx 负载均衡策略未生效。

监控后端服务健康

curl -s http://192.168.1.201/health
curl -s http://192.168.1.202/health
curl -s http://192.168.1.203/health

返回 200 OK 说明新环境正常。

实时监控接口响应时间

watch -n 2 "curl -o /dev/null -s -w '%{time_total}\n' http://your-service/api"

如果发现新环境的响应时间过高，可能是服务器性能有问题。

---

5. 预设回滚方案

一键回滚脚本

如果新环境不稳定，可以秒级回滚：

#!/bin/bash
echo "回滚 Nginx 负载均衡配置..."
cp /etc/nginx/nginx.conf.bak /etc/nginx/nginx.conf
systemctl reload nginx
echo "回滚完成!"

执行：

chmod +x rollback.sh
./rollback.sh

⚠️ 提前备份配置！

cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.bak

---

6. 复盘 & 优化

每次切换后，复盘总结：
✅ 是否有请求失败？
✅ 后端服务 CPU、内存是否正常？
✅ 访问日志是否符合预期？
✅ 用户反馈是否有异常？

---

最终方案总结

✅ 最推荐：逐步增加新环境的权重（灰度发布）
✅ 可以做 AB 测试，先让部分用户访问新环境
✅ 每次调整后监控 Nginx 日志 + 后端健康状态
✅ 写好回滚脚本，确保问题出现时可以秒级恢复

---

你的 Nginx 是前端负载均衡，还是后端 API 网关？有没有 Redis、MySQL 这些数据库切换需求？