我在生产环境折腾 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 集群故障时自动切到备份节点。这个机制在上周三真的救了我们一命——某个第三方服务突然宕机,但用户完全没感知到。
血泪总结
这次经历让我明白:
- 负载均衡不是简单的请求转发,要考虑连接复用、头信息传递等细节
- 多层代理时,每一层的配置都会相互影响
- 监控和熔断比想象中重要,特别是在对接第三方服务时
现在这套架构已经稳定运行一周多了,期间处理了 2000 多万请求。虽然配置过程很痛苦,但看到监控面板上平稳的曲线,还是很有成就感的。
看到keepalive那个配置就头大,之前我们也遇到过类似问题 😅
proxy_set_header配置shiguanjian啊!之前踩过一模一样的坑
大佬能分享下Prometheus监控的具体配置吗?想学习下
2000万请求稳如老狗,这优化可以啊 👍
有没有考虑过用HAProxy替代Nginx?感觉更专业些