实战笔记：如何用 Nginx 配置多后端服务的负载均衡

上周在给公司项目做架构升级时，遇到了一个典型问题：单台反向代理服务器已经扛不住突发的流量高峰了。经过一番折腾，终于搞定了多后端服务的负载均衡配置，今天就把这个踩坑过程记录下来，希望能帮到遇到同样问题的朋友。

为什么需要多反向代理？

记得刚开始搭建服务时，我觉得单台 Nginx 完全够用了。但随着用户量增长，特别是在促销活动期间，服务器经常出现 502 错误。监控显示 CPU 经常跑到 90% 以上，这时候才意识到：反向代理本身也可能成为性能瓶颈。

解决方案很明确：需要把负载分散到多台反向代理服务器上。但具体怎么做？我查了很多资料，最终选择了 DNS 轮询 + Nginx 负载均衡的组合方案。

基础架构设计

我的方案包含三个层级：

1. DNS 层：配置多个 A 记录实现初步分流
2. 代理层：2-3 台 Nginx 服务器
3. 应用层：多台后端服务实例

这里有个小技巧：DNS TTL 要设置短一些（比如 300s），这样当某台代理服务器故障时能快速切换。

Nginx 具体配置

核心配置其实很简单，主要是在 http 块中定义 upstream：

upstream backend {
    server 192.168.1.101:8000 weight=3;
    server 192.168.1.102:8000;
    server 192.168.1.103:8000 backup;
    
    keepalive 32;
    least_conn;
}

这里有几个值得注意的参数：

• weight：给性能更好的服务器分配更多流量
• backup：备用服务器，平时不参与负载
• least_conn：使用最少连接算法，比默认的轮询更智能

遇到的坑和解决方案

本以为配置完就万事大吉，结果上线后发现了几个问题：

问题1：会话保持失效
用户登录状态频繁丢失，因为请求被随机分配到不同后端。解决方案是启用 ip_hash：

upstream backend {
    ip_hash;
    server 192.168.1.101:8000;
    ...
}

问题2：健康检查不灵敏
有台后端服务挂了，但 Nginx 还在往那台机器转发请求。后来增加了健康检查配置：

server {
    location /health {
        access_log off;
        return 200;
    }
}

监控和调优

配置完成后，我通过这几个指标来监控系统状态：

• Nginx 的 active connections
• Upstream 各个节点的响应时间
• 错误日志中的 502/504 错误

经过一周的观察和调整，最终将 keepalive_timeout 从默认的 75s 降到了 30s，显著减少了内存占用。

写在最后

这次架构升级让我深刻体会到：负载均衡不是简单的配置几个参数就完事了，需要根据实际业务场景不断调整。如果你也在做类似改造，建议先在小流量环境测试，逐步放开。

对了，如果你有更好的方案或者遇到其他问题，欢迎在评论区交流～