我在生产环境折腾 Nginx 负载均衡的那些坑

上周公司业务量突然暴增，单台服务器已经扛不住了。作为团队里唯一会点 Nginx 配置的”伪运维”，我被临时拉来搭建负载均衡。本以为就是改改配置文件的事，结果踩坑踩到怀疑人生…

为什么需要多层反向代理

我们业务有个特殊场景：前端需要同时对接三个第三方 API 服务，每个服务都有多个节点。理想状态是：用户请求 → 我们的负载均衡 → 自动分配到不同 API 服务节点。

画个示意图就是：

  Client → Nginx (主LB) → [API1集群, API2集群, API3集群]
          每个API集群又有自己的Nginx做二级负载均衡
  

主负载均衡配置踩坑记

最开始我天真的以为这样配置就行：

  upstream api1 {
    server api1-lb.example.com;
  }
  upstream api2 {
    server api2-lb.example.com; 
  }
  # 其他配置...
  

结果上线直接炸了——所有请求都卡在超时。查了半小时日志才发现，原来上游的负载均衡服务器也需要特殊配置，不能简单当普通后端用。

正确的多层代理配置

经过多次测试，最终稳定运行的配置长这样：

  # 主负载均衡配置
  upstream api1_cluster {
    server api1-lb1.example.com:80 max_fails=3;
    server api1-lb2.example.com:80 backup;
    keepalive 32;
  }

  location /api1/ {
    proxy_pass http://api1_cluster;
    proxy_http_version 1.1;
    proxy_set_header Connection "";
    # 关键！必须传递原始Host头
    proxy_set_header Host $host;  
  }
  

特别注意几个关键点：

• keepalive 必须开，否则每次新建连接性能差
• 二级 LB 也要配置 proxy_http_version 1.1
• Host 头不传会导致上游服务器拒绝请求

监控与熔断机制

配置好了只是开始，我们还在主 LB 加了健康检查：

  server {
    listen 8080;
    location /status {
      check_status;
      access_log off;
    }
  }
  

配合 Prometheus 监控各节点状态，当某个 API 集群故障时自动切到备份节点。这个机制在上周三真的救了我们一命——某个第三方服务突然宕机，但用户完全没感知到。

血泪总结

这次经历让我明白：

1. 负载均衡不是简单的请求转发，要考虑连接复用、头信息传递等细节
2. 多层代理时，每一层的配置都会相互影响
3. 监控和熔断比想象中重要，特别是在对接第三方服务时

现在这套架构已经稳定运行一周多了，期间处理了 2000 多万请求。虽然配置过程很痛苦，但看到监控面板上平稳的曲线，还是很有成就感的。