负载均衡关键在“接得稳、分得准、扛得住”，需确保服务暴露一致性、流量入口统一化、连接生命周期可控，并规避DR模式ARP冲突、least_conn滥用及云上SLB与Nginx重复部署等典型坑点。
负载均衡不是加一台机器就完事，关键在“接得稳、分得准、扛得住”。很多团队一上来就配Nginx轮询，结果上线后响应变慢、连接超时、会话丢失、健康检查误判——问题往往不出在算法本身，而在于接入方式和环境适配没对齐。下面从配置主线和典型坑点两个维度说清楚。
接入配置三步主线
无论用LVS、Nginx、ALB还是Nacos客户端，接入逻辑都绕不开这三步：
-
服务暴露一致性：所有后端实例必须提供相同接口、相同健康检查路径（如
/health或/v1/models），且响应状态码规范（200才视为健康）； -
流量入口统一化：把真实IP、协议版本、请求头等关键信息透传过去，比如Nginx里必须配
proxy_set_header X-Real-IP $remote_addr，否则日志和限流全失效； -
连接生命周期可控：设置合理的超时（
proxy_connect_timeout、proxy_read_timeout）、复用连接（keepalive 32）、失败重试（max_fails=3 fail_timeout=30s），避免慢节点拖垮整条链路。
DR模式下ARP抑制必须做
LVS的DR模式性能高，但生产中最常翻车的地方就是real server没关ARP响应。现象是：客户端能连上VIP，但返回包直接发给客户端，不经过director，导致TCP三次握手卡在SYN-ACK，连接一直establishing。根本原因是real server和director在同一网段，收到ARP请求后自己应答了VIP的MAC地址。
解决方法是在每台real server上执行：
echo "1" > /proc/sys/net/ipv4/conf/all/arp_ignoreecho "2" > /proc/sys/net/ipv4/conf/all/arp_announce- 并写入
/etc/sysctl.conf持久化，否则重启失效。
Nginx upstream里的least_conn别乱用
很多人看到“最少连接”就觉得更智能，其实它只看当前活跃连接数，不看CPU、内存、响应延迟。在gRPC或长连接场景下容易造成雪崩：一个慢实例连接数始终偏低，流量越压越多，最终打满。
更稳妥的做法是：
- HTTP短连接服务优先用
ip_hash（需会话保持）或加权轮询（weight按机器规格设）； - 长连接或gRPC服务建议配合主动健康检查+
slow_start参数，让新上线实例逐步承接流量； - 真要用
least_conn，务必加上max_conns限制单实例最大连接数，防止单点过载。
云上SLB与自建Nginx别混着用
阿里云ALB/NLB已经是托管服务，自带SSL卸载、WAF、自动扩缩容能力。但不少团队还在ALB后面再挂一层Nginx，理由是“想自定义header”或“要加rewrite规则”。这不仅多了一跳延迟，还可能引发重复健康检查、X-Forwarded-For嵌套、证书管理混乱等问题。
正确姿势是：
- 七层路由、灰度发布、URL重写等逻辑尽量交给ALB完成；
- 只有Nginx特有的模块需求（如lua脚本、复杂geoip策略）才保留在后端；
- 如果必须保留Nginx，记得关掉它的access_log中记录上游IP的字段，避免日志膨胀。
