内容摘要：```html F5负载均衡器 body { font-family: -apple-system, BlinkMacSystemFont, "Segoe UI", Roboto, "Hel

```html

F5负载均衡器

第一次接触F5是在一个电商大促的压测现场。运维同事指着监控大屏说：“你看，衡器所有流量先打到F5，载均再由它分到后面200台服务器，衡器单台机器挂了根本没人发现。载均”当时我盯着那个黑乎乎的衡器机架式设备，觉得它像个沉默的载均交通警察——不处理业务，但少了它，衡器整个路口立刻瘫痪。载均

F5的衡器核心就干一件事：把进来的请求合理地分给后端服务器。但“合理”这两个字背后有太多门道。载均最简单的衡器轮询，每台机器轮流来一个请求；加权轮询，载均配置高的衡器机器多分点；还有基于响应时间的动态算法，谁快谁多干活。载均我见过一个视频网站用最小连接数算法，结果某台老服务器因为响应慢、连接堆积少，反而被分配了更多新请求，直接雪崩。算法没有绝对好坏，得看业务场景。

很多人以为F5就是硬件盒子，其实它早就软件化了。BIG-IP系列有物理设备，也有VE（虚拟版）跑在VMware或KVM上。前几年帮一个客户做迁移，他们把物理F5上的200多条iRules规则原封不动导到VE上，跑起来一点问题没有。iRules这东西挺有意思，是基于TCL语法的脚本，能改HTTP头、做内容路由、甚至根据用户Cookie做灰度发布。有次排查一个诡异问题：用户登录后偶尔跳回首页。最后发现是iRules里一条HTTP::redirect规则没加条件判断，把POST请求也重定向了。

健康检查是另一个容易被忽视的坑。默认的ICMP ping或者简单TCP端口探测，只能说明机器活着，不代表服务正常。我见过后端Tomcat进程还在，但线程池满了，所有请求都超时。F5的TCP探测显示端口通，继续往那台机器发流量。后来改成HTTP GET探测，检查返回状态码和特定字符串，才算靠谱。但探测频率也得调，太频繁像DDoS自己人，太稀疏故障发现慢。一般5秒一次，连续3次失败标记下线，比较平衡。

性能数字方面，一台中端F5（比如i5800）能扛住每秒几十万的新建连接，吞吐量几十Gbps。但实际瓶颈往往在SSL握手。RSA 2048位握手，单颗CPU核心每秒也就几千次。所以F5高端型号会配专用SSL加速卡。现在流行TLS 1.3，握手快了不少，但密钥交换算法换成ECDHE，计算量又上来了。硬件这东西，永远在追软件的需求。

说到竞品，Nginx和HAProxy在软件层面很能打，LVS在四层性能上甚至更强。但F5卖的不只是负载均衡。它的APM模块能做全链路监控，ASM模块是WAF，GTM做全局负载。一套买齐，价格够买几台服务器。有个客户吐槽：“F5的license比我的宝马还贵。”但真出故障时，厂商工程师远程接入，两小时定位到是某条iRules内存泄漏，这种支持力度开源方案很难比。

最后说个观察：现在容器和Service Mesh流行，很多人觉得F5要过时了。但K8s的Ingress Controller性能有限，大规模场景下还是得靠F5这类硬件设备做入口。只不过角色变了——以前是唯一入口，现在是边缘网关之一。它得学会和Istio、Envoy共存。去年F5收购了NGINX，这步棋挺妙。硬件守高端，软件抢云原生，两头都不放。

如果你正在选型，别只看吞吐量参数。先理清楚：你的SSL卸载需求多大？需要七层内容路由吗？团队有没有能力维护iRules？预算够不够买原厂支持？想明白这些，再决定是上F5、Nginx Plus还是云厂商的LB。工具没有绝对好坏，匹配场景才重要。

```