部署完负载均衡，别急着交差
公司上新项目，前端流量猛增，领导拍板上了负载均衡。设备配好了，策略写完了，主备切换也测试了，看起来一切正常。可上线没几天，用户反馈页面卡顿，后台监控发现某台服务器CPU飙到95%，而旁边的兄弟才用了30%。问题出在哪？很可能——负载压根就没“均衡”。
配置不等于生效
很多人觉得，Nginx或HAProxy配置文件里写了upstream，加了几台后端，再配上轮询或权重，就万事大吉。但实际流量是不是按预期分发的？有没有节点被漏掉？会话保持有没有误伤？这些都得靠验证说话。
比如我们之前做过一个电商系统，开发说购物车用的是IP Hash保持会话。结果压测时发现三台应用服务器，一台扛了70%请求。一查日志，原来是前端有统一出口IP，所有用户在负载设备看来都是同一个源IP，全被Hash到同一台去了。这种坑，不测根本发现不了。
怎么动手验证？真实请求最靠谱
最简单的办法：模拟多用户并发访问，看后端日志分布。可以用ab（Apache Bench）或者wrk这类工具发起请求，同时在每台后端服务器上用tail命令实时查看访问日志。
wrk -t12 -c400 -d30s http://vip.domain.com/api/user/profile跑完看各台机器的日志条数，如果差距超过15%，就得回头检查负载策略。如果是轮询，理论上每台应该接近均等；如果用了权重，那就按比例来核对。
别忽略健康检查的细节
负载均衡器通常会定期探测后端节点。配置里可能写了每5秒发一次GET /health，返回200才算存活。但现实中，网络抖动、后端短暂GC都可能导致探测失败，节点被错误摘除。
建议把健康检查日志打开，观察一段时间。有一次我们发现某节点每隔几分钟就被踢出去又加回来，最后定位是防火墙拦截了探测包。这种问题不看日志，光看配置永远找不到。
会话保持要谨慎
有些业务确实需要会话保持，比如传统Web系统依赖本地Session。但启用sticky session后，负载容易倾斜。这时候可以用带Cookie的curl测试：
curl -H "Host: www.example.com" --cookie "route=abc123" http://lb-vip/多次执行，看是否始终转发到同一台。同时也要测试无Cookie请求，确认新用户能正常被调度。
监控才是长期保障
一次性验证只能管上线前。真正重要的是把负载分发情况纳入日常监控。比如在Prometheus里抓取Nginx的stub_status，或者用ELK收集后端访问日志做请求计数聚合。一旦某台服务器请求数异常飙升或归零，立马告警。
技术不是一锤子买卖。部署只是开始，验证才是确保它真正在干活的关键步骤。别让“我以为”变成线上事故的开头。