负载均衡选型常见的误区，是把厂商排名直接当成结论。实际上设备能不能扛住业务，取决于流量是七层HTTP还是四层TCP、是否需要SSL卸载、后端节点数量、健康检查频率，以及运维团队对命令行和API的熟悉程度。如果只看哪家名气大，很容易买到一台纸面吞吐很高、真实业务中新建连接数上不去的设备。下面先把厂商分成三类，再说评估指标和常见坑。
主流负载均衡厂商的三类产品形态
第一类是硬件ADC和应用交付设备，代表产品包括F5 BIG-IP、Citrix ADC、深信服AD、Array Networks等。硬件ADC的优点是专用操作系统和专用硬件带来的稳定性能，尤其是SSL卸载、四层转发和会话保持等方面通常表现稳定，适合金融、政务、大型数据中心等场景。缺点是采购成本高、扩容周期长，部分老型号的自动化接口不够开放，授权模型复杂，运维团队需要投入专门人员学习。
第二类是开源软件负载均衡，常见的有Nginx、HAProxy、LVS、Traefik和Envoy。开源方案成本低、部署灵活，在容器化和微服务环境中，Nginx Ingress和Envoy已经成为事实标准。团队可以根据业务需求修改配置，但生产环境的支持、安全更新和性能调优都要自己负责。没有商业支持的情况下，线上出问题只能靠内部排障，对团队能力要求不低。
第三类是云厂商提供的负载均衡服务，例如阿里云SLB和ALB、腾讯云CLB、华为云ELB、AWS ALB和NLB。云负载均衡的优势在于按量付费、控制台配置直观、能跟云监控和弹性伸缩联动。但它本质上是黑盒服务，健康检查来源IP、连接复用策略、VIP漂移机制不完全透明，跨云或回传到本地机房时容易出现链路不通、源IP丢失等问题。
| 产品类型 | 代表厂商 | 适合场景 | 主要短板 |
|---|---|---|---|
| 硬件ADC | F5、Citrix、深信服 | 金融、政务、大型数据中心 | 成本高、扩容慢、API开放度不一 |
| 开源软件 | Nginx、HAProxy、Envoy | 互联网、容器、微服务 | 无商业支持、需自行维护 |
| 云负载均衡 | 阿里云SLB、AWS ALB、腾讯云CLB | 云上业务、混合云入口 | 黑盒、跨云回传可能受限 |
评估厂商时不能只看吞吐量
设备参数表上的吞吐量都是在理想条件下测出来的，实际选型时至少应该把下面四项拆开验证。否则很容易出现设备上线后带宽没跑满，CPU已经接近百分之百的情况。
新建连接数与并发连接数
吞吐量通常指每秒转发的比特数，对七层负载均衡来说，真正容易被压垮的是新建连接数和并发连接数。许多HTTP短连接业务，每秒新建连接数比带宽更先触顶。后端服务响应变慢时，并发连接数会迅速堆积，如果设备的会话表满了，新连接会被直接丢弃。评估时要让厂商提供小包吞吐、不同HTTP keep-alive比例下的CPS，以及并发连接数上限，不能只看大包吞吐。
测试时可以用压测工具模拟真实业务，重点观察设备CPU、内存和会话表占用率。比如同样是10万CPS，开启日志、访问控制和应用层检查后，有效处理能力可能下降一半以上。
SSL卸载能力与证书管理
现在业务普遍走HTTPS，SSL/TLS握手对CPU消耗很高。要确认设备支持的TLS版本、加密套件、是否具备硬件SSL加速，以及RSA和ECC证书混合情况下性能下降多少。证书管理也不能忽略，多域名、泛域名证书、到期告警和自动化续期接口，都会影响日常运维效率。
有些设备标称的SSL性能只测了RSA 2048证书，业务启用更安全的ECC证书或更长的证书链后，QPS会明显变化。建议使用真实业务证书做压测，而不是只看厂商手册。
健康检查与故障切换准确性
健康检查不是简单能连通就行。检查URL返回200不代表业务可用，后端返回302、401或响应体异常都可能造成误判。不同厂商对检查间隔、超时、成功和失败阈值的默认值也不同，默认配置可能不适合长接口业务。以下是一段HAProxy的健康检查配置示例：
backend web_backend
balance roundrobin
option httpchk GET /healthz
http-check expect status 200
server web1 10.0.0.11:80 check inter 3s rise 2 fall 3
server web2 10.0.0.12:80 check inter 3s rise 2 fall 3
inter 3s表示每3秒检查一次，rise 2表示连续2次成功才认为节点上线，fall 3表示连续3次失败才摘除节点。实际业务中，如果健康检查URL依赖数据库，数据库慢查询可能让检查超时，反而把后端节点全部摘掉，所以超时时间和阈值要结合业务特点调整。
API、日志与运维体系
现代负载均衡不应该只靠Web控制台手工操作。要确认厂商是否提供完整API、是否支持声明式配置、能否接入Terraform或GitOps流程。日志和指标输出也很关键，至少要能看到客户端IP、后端IP、请求时延、响应码和SSL握手耗时。如果这些字段缺失，线上出问题时很难定位流量打到哪台后端。
部分硬件厂商的API是后来补充的，调用复杂度高，配置文件导出再导入容易丢失注释和顺序。选型时最好写几个自动化脚本实际调用一遍，验证批量上下线后端、查询会话表和修改健康检查等高频操作是否顺畅。
选择靠谱厂商的常见问题与注意事项
在采购或上线前，有几个高频问题几乎每次都会遇到，提前确认能避免后期扯皮。
会话保持怎么做？源IP哈希有什么坑？
负载均衡常用会话保持方式有源IP哈希、Cookie插入和SSL Session ID等。源IP哈希在客户端经过NAT网关或公司出口代理时，会出现大量用户共享公网IP，导致流量倾斜到同一台后端，移动网络场景更明显。HTTP协议优先使用应用层Cookie保持，但需要后端应用配合写入Cookie。四层TCP业务无法插入Cookie，只能依赖源IP或代理协议，建议先做真实环境测试。
吞吐量标称值和真实业务差距大
厂商标称吞吐量通常基于大包、无SSL、无应用层检查的理想条件。真实业务小包比例高，加上SSL握手、HTTP解析、访问控制和连接复用，有效吞吐可能只有标称的百分之三十到五十。测试时要用真实业务流量回放，或至少用ab、wrk等工具压测，同时观察设备CPU、内存和会话表占用率。很多项目上线后才发现带宽占用不高，但CPU已经超过百分之九十，就是SSL和HTTP解析吃掉了资源。
高可用方案要防止脑裂
主备双机通常通过VRRP或厂商私有协议做VIP漂移。配置不当可能出现主备同时持有VIP，也就是脑裂。要确认心跳线是独立网口还是业务网口复用，心跳超时时间是否过短，故障恢复后是否自动回切。自动回切有时候会造成二次中断，一般建议手工确认后再回切。云负载均衡虽然省去硬件高可用配置，但可用区故障、跨Region容灾和流量切换时间仍然需要提前验证。
厂商支持、备件与版本升级
硬件设备出故障后，备件响应速度直接影响业务恢复。原厂服务、代理商服务和第三方维保差别很大。还要问清楚版本升级策略，大版本升级是否需要重启、是否会中断流量、新版本是否存在已知问题。开源软件虽然没有许可费，但生产环境问题需要靠自己或商业支持公司解决，评估团队能力后再决定。
总结来说，负载均衡选型没有绝对第一，只有是否匹配业务和团队。把流量模型、协议特征、SSL要求、健康检查策略和自动化能力列清楚，再拿真实业务做测试，比任何厂家排名都可靠。