实战笔记:如何用 Nginx 配置多后端服务的负载均衡
上周在给公司项目做架构升级时,遇到了一个典型问题:单台反向代理服务器已经扛不住突发的流量高峰了。经过一番折腾,终于搞定了多后端服务的负载均衡配置,今天就把这个踩坑过程记录下来,希望能帮到遇到同样问题的朋友。
为什么需要多反向代理?
记得刚开始搭建服务时,我觉得单台 Nginx 完全够用了。但随着用户量增长,特别是在促销活动期间,服务器经常出现 502 错误。监控显示 CPU 经常跑到 90% 以上,这时候才意识到:反向代理本身也可能成为性能瓶颈。
解决方案很明确:需要把负载分散到多台反向代理服务器上。但具体怎么做?我查了很多资料,最终选择了 DNS 轮询 + Nginx 负载均衡的组合方案。
基础架构设计
我的方案包含三个层级:
- DNS 层:配置多个 A 记录实现初步分流
- 代理层:2-3 台 Nginx 服务器
- 应用层:多台后端服务实例
这里有个小技巧: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,显著减少了内存占用。
写在最后
这次架构升级让我深刻体会到:负载均衡不是简单的配置几个参数就完事了,需要根据实际业务场景不断调整。如果你也在做类似改造,建议先在小流量环境测试,逐步放开。
对了,如果你有更好的方案或者遇到其他问题,欢迎在评论区交流~
干货满满!正好最近也在折腾Nginx负载均衡,这篇文章太及时了 👍
遇到同样的问题!502错误简直噩梦,感谢分享解决方案
大佬能详细讲讲健康检查的具体实现方式吗?不太明白那段配置