阿里负载均衡的发展经历了从LVS到VIPServer的过程。负载均衡听起来像是个麻烦，但实际上是系统成长过程中必须面对的难题。任何业务从刚起步到成熟，都会经历流量洪峰和单点瓶颈的困扰。LVS在Linux内核上把分流功能玩到了极致，却也在阿里内部催生了新一代产品VIPServer。故事要从简单的域名和服务器开始说起。传统的负载均衡方案主要有三种：轮询、LB和四层/七层。 轮询方案是通过修改域名A记录来实现的，把请求随机丢进不同的IP池中。这种方案简单方便，但存在会话粘连问题，用户与服务器之间的连接会被打乱，登录信息和订单信息都会混乱。另外还有缓存和TTL带来的问题，一旦手机代理缓存了内容，第二天所有请求都可能只到一个服务器。节点宕机后恢复速度慢，DNS记录要等待全球缓存失效，最长可达10分钟。 硬件负载均衡器方案是把流量先通过一台或几台专用LB设备进行分发。这种方案支持多种调度算法，并且可以集中处理智能分流。但是它也存在缺点，比如请求和响应都要经过LB设备，小设备容易扛不住大流量。单点故障是这个方案最大的问题，如果主设备故障了，整个系统就无法正常运行。另外还有链路多跳带来的问题，网络延迟RTT会翻倍，故障率也会相应增加。 四层和七层方案则是在网络和业务之间进行权衡。四层LB只关心IP和端口，对应用程序没有影响，部署简单但缺乏业务语义。七层LB深入HTTP头部、Cookie甚至业务协议可以做出更多灵活操作，但需要业务修改代码、增加插件等侵入性操作。阿里早年很多业务跑在LVS上也遇到过“业务耦合太深”的问题。 传统负载均衡方案总是绕不开“LB成为新瓶颈”的问题。VIPServer就是为了解决这个问题而被立项的背景就是集团业务把LVS逼到了墙角：双11、春晚红包等大流量场景能把LB打穿；active-standby模式只是增加了一个备用设备；多跳链路导致RTT翻倍；异地多活、跨国容灾成为日常演练；热点大促容量评估全靠经验拍脑袋；硬件成本高企。 VIPServer是阿里中间件团队自研的七层中间层负载均衡系统。它采用P2P架构，把传统LB的大而全拆成小而美的节点网络。VIPServer提供动态域名解析+负载均衡+健康检测+容灾策略等一站式解决方案。它支持同机房优先、同区域优先、流量打散、多活容灾等高级策略，几乎不需要改动业务就能接入。 短短几年时间内VIPServer就能通吃各个核心业务线主要原因有以下几点：分布式节点横向无上限扩容；对称调用拒绝单点瓶颈；多活容灾秒级故障切换；智能调度策略让流量有目标地分配。 不过VIPServer也并非完美无缺，它也面临节点网络复杂度陡增、动态扩容一致性问题以及全球容灾成本高等新KPI挑战。阿里中间件团队正在攻关节点自治与容错网格化、轻量代理协议以及成本可编程化等方面问题。 阿里中间件团队自研的VIPServer把“负载均衡”从“硬件坑”推向了“软件海”，让流量调度像云一样弹性的愿景正在被技术人接力实现。