前段时间参与了一个跨境电商平台的架构优化，技术团队在负载均衡器选型上吵得不可开交。市场部急着要上HTTP/3协议，运维组死守着四层负载不放，开发那边又吵着要七层的流量镜像功能——这种场景你是不是也遇到过？说真的，选择合适的负载均衡器就像给系统挑心脏，一旦选错，轻则性能打折，重则业务瘫痪。那次我们花了三周时间做压力测试才最终敲定方案，过程中发现很多文档里根本不会写的实战经验。
先把业务需求拆解得明明白白
千万别急着比较技术参数！那次踩坑后我养成了个习惯——先画业务流量地图。比如直播平台每秒20万UDP包的场景，硬要用Nginx做七层负载就是自找苦吃。记住这三个关键指标：QPS要求（我们电商大促时峰值到过35万）、协议类型（HTTP/3现在越来越多见了）、会话保持需求（金融类业务必须考虑）。上次看到某支付平台因为忽视SSL卸载，导致CPU占用飙升到90%，就是典型的需求分析漏项。
性能与功能的博弈艺术
四层负载的性能确实诱人，LVS能轻松跑满40Gbps网卡，但看到有人试图用它做URL路由我就头皮发麻。七层负载虽然吞吐量可能只有1/3，但去年我们用Nginx的map功能实现灰度发布，省了三台中间件服务器。这里有个计算公式经常被忽略：理论最大并发=单连接内存消耗×可用内存。像HAProxy每个连接吃2KB内存，32GB机器理论上能扛1600万并发——但实际能到七八成就不错了。
混合架构才是终极答案
如今的智能选型早过了非此即彼的阶段。我们现在主力架构是：F5做四层扛流量（心疼钱包但确实稳），Envoy处理七层路由，再加个云厂商的LB做跨可用区容灾。特别要说下Kubernetes Ingress的选择，原来用Nginx Ingress差点被gRPC长连接搞崩，换成Contour后才稳定下来。对了，千万别相信”万能型”产品的宣传，上周刚帮朋友排查了个号称全能的负载均衡器，结果HTTP/2支持居然有内存泄漏！
说到最后，选型时记得问自己三个致命问题：是否需要解析应用层协议？TLS终止放在哪层？监控接口能否对接现有系统？那次我们就是忘记确认监控协议兼容性，导致Prometheus监控断了整整两天。现在我的决策流程里永远留着20%余量给”没想到”，在负载均衡这个领域，意外总是比明天来得更快。
评论