得上大学时，我和好友老郭讨论最多的话题便是：“像新浪这样的网站是如何支撑如此巨大的访问量？”也曾通过各种手段，猜测新浪服务器的数量、操作系统和应用软件的版本……一切都是那么神秘。毕业那年，有幸加入新浪，终于一点点地揭开了这层神秘的面纱。2004年某厂商设备介绍会上，我初次接触到了负载均衡技术。之后的几年时间，可以说是负载均衡设备在网站推广的黄金爆发期。
发展到今天，一方面硬件设备依然保持了强劲的实力，另一方面以LVS、Haproxy为代表的软件负载均衡也异军突起，被人们所认可。在新浪，软、硬件负载均衡并存的格局已有三年多的历史了，除了既往积累的经验外，近一年来，我们也看到了负载均衡所面临的一些新挑战，在此跟大家分享。
挑战一：Web应用对七层交换的依赖度越来越大，显著增加了负载均衡器的压力。
七层交换技术的引入，极大地解放了架构师和程序开发人员，同时也使我们越来越习惯依赖于它，甚至直呼上瘾。很难想象，如果没有负载均衡器的话，现有Web架构中的大量需求应该如何实现? 在充分享受其便利性的同时，我们也看到了一些隐忧。一方面越来越多的流量正从四层交换转为七层交换；另一方面七层交换的规则也越来越趋于复杂。在双重作用下，负载均衡器的压力急剧上升。对于任何一台负载均衡器来说：支撑相同的请求量，七层交换所消耗的CPU要远远高于四层交换。特别是在瞬间高并发连接的突发流量面前，负载均衡器面临着严峻的挑战。
挑战二：微博等互联网新兴产品的出现，对负载均衡器的运维工作提出了更高的要求。
微博不仅改变着亿万网民的生活，而且也正悄然推动着运维体系的建设。
首先，与传统的新闻、博客相比，微博用户对服务质量的敏感度更高，而且这种敏感度会伴随着一次次的“@”和“转发”传播扩散。在过去，当用户访问新浪服务感到慢时，反映的渠道多是打客户电话。而现在只需要在微博上一个简单的“@” 就可以与新浪的客服和技术人员直接沟通。作为流量进出的一个关卡，当微博等线上关键业务出现访问异常或故障时，工程师们都迫切地想知道：是负载均衡器的问题吗？此时故障诊断的效率显得至关重要。在实际工作中我们发现：单纯依靠负载均衡器提供的CPU、内存、连接数等统计信息，还不足以发现一些隐蔽问题。传统的抓包分析耗时耗力且效果不佳，再加上有些故障现象与客户端、后台服务器上的某些特殊设置有着千丝万缕的联系，所有这些交织在一起，给我们故障诊断带来了不小的挑战。例如有次我们发现：负载均衡器偶尔会给客户端返回HTTP 5xx的响应，当时特想快速地知道究竟是什么样的HTTP请求会触发这样的现象。但可惜的是，负载均衡器上仅有统计数字而没有请求的完整记录。在花了很大力气抓包分析后，最终定位到是由于后台一个PHP程序不小心给页面设置了一个错误的HTTP Header，导致Web Server的HTTP响应不能被负载均衡器所接受，最终给客户端返回5xx。因此在故障诊断方面，我们需要有更先进的理念和手段。
其次，微博在国内正处于快速成长期，会随时根据访问量来灵活调整服务器的数量和系统架构。在这种快速灵活的变化面前，负载均衡器相关的配置调整工作也随之增加：频繁的上下线服务器、变更七层规则等。面对这种情况，我们需要思考：如何能更加快速安全地完成好这些变更、如何能避免工程师每天被动地陷入这些重复烦琐的工作中等。目前一些硬件设备提供了API接口，像增删Server、调整Server 权重等这类风险性极低的操作可通过API接口操作，以达到提高效率的目的。而Haproxy、LVS则缺乏这样的 API接口，需要单独开发。
除此之外，关键应用对负载均衡器的监控也有越来越多的新需求。比如：有些应用希望当负载均衡器检测到服务器池中活跃的服务器数量少于一定比例后，便提前给系统管理员作出预警；及时发现服务器池中权重等设置不合理的问题等。
挑战三：多核处理器时代下，Haproxy等用户态的软件负载均衡正面临新的性能瓶颈。
近几年来CPU发展进入了多核时代，CPU由过去的单核发展到四核、六核、八核、十二核，甚至更多，而主频则变化不大。在这种趋势下，充分利用多核特性显得尤为重要。但在我们研究中发现，像Haproxy这类基于用户态的软件负载均衡，其对CPU主频的依赖度要远远高于CPU核数。换言之，在高主频、核数少CPU下的性能很有可能要优于低主频、核数多的CPU。这一点，在Haproxy服务器选型时尤为重要。据我们分析，这主要是由于操作系统对多核（多CPU）下的并发支持度还不够好。
挑战四：软件负载均衡发展路上的“鸡蛋-篮子”理论的艰难选择。
硬件负载均衡器往往以单台高性能著称，而Haproxy、LVS为代表的软件负载均衡的优势则在于成本低廉、可灵活定制，其性能与服务器CPU、网卡等硬件直接相关（当然特殊的优化也很重要）。正如前面提到的，当七层交换流量越来越大时，我们究竟是该投入成本让单台LVS、Haproxy足以支撑如此大的流量，还是让更多中等性能的服务器共同分担这些流量呢？这就是所谓的经典的“鸡蛋－篮子”理论：究竟该不该将鸡蛋放到一个篮子里呢？
其实不同的选择各有利弊。2~3年前，我比较赞同将流量分摊到多台软件负载均衡器上，当时主要考虑到风险的分散。而现在，我更倾向于将流量集中于一台上。之所以这样，是从以下四个角度考虑的。
第一，目前国内IDC内每个机架所放服务器数量跟电力配额直接相关。而负载均衡由于其特殊性，往往是两台为一组，这样每增加一组都会增加额外的电力开销，特别是在电力资源紧张的IDC内，提高单台软件负载均衡器的承载能力可以为关键业务腾出更多的机架来。
第二，从服务稳定角度考虑，我们通常会将LVS、Haproxy直连核心交换机，如此一来，每增加一组，就意味着会占用更多的核心交换机端口资源。
第三，是基于管理成本的考虑。LVS、Haproxy之所以能在新浪得到广泛应用，较低的管理成本是重要原因之一。在新浪我们通过一套集中管理平台和快速初始化的办法实现了运维成本的非线性增加。但不可否认的是，每新增一组，运维成本或多或少总会增加一些。之前也曾设计过一套“同机房内负载均衡器的集群池方案”，即：在一个机房内主备机的数量比不再固定为1:1， 虚拟IP（VIP）会根据集群池中每台Haproxy/LVS的负载状况，动态地“漂”在其中某台上。但后来发现这个“听起来很美”的方案，在实际运行中遇到了种种问题，运维成本不降反升。最终我们又回归了传统的1台Active+1台Standby的模式，正所谓简单即是美。
第四，目前硬件负载均衡器正朝着“更高的性价比”方向发展，换句话来讲，如果我们不提升软件负载均衡器的单机支撑能力，则终有一天，其与硬件设备相比的成本优势将会淡去。
挑战五：在新时期下，如何找到负载均衡的最佳软硬结合之道？
朋友、同行聚会时，常有人问我：“你们有了Haproxy、LVS后，会不会不买硬件设备了？”、“你最近又在山寨什么？”每次听到这些，我都会微微一笑。如前文所述，Haproxy、LVS这类的软件负载均衡和硬件设备各有优势，在我看来，负载均衡的“软”、“硬”解决方案并非水火不容，只要找到最佳的软硬结合之道，鱼和熊掌还是可以兼得的。下面是我们在长期摸索中，总结出来的一些经验。
软件负载均衡可优先承担四层交换流量，让硬件设备更专注于七层交换：由于工作方式和原理的不同，专注于四层交换的LVS在稳定性、单机支撑能力、易维护性、管理成本等多方面均要大大优于Haproxy。特别是在DR模式（即单臂）下， 单台LVS足以应对绝大多数业务的访问量。
优先保障“明星”产品占用宝贵的硬件设备资源：这里指的“明星产品”是指那些用户群正处于快速增长，并被广泛追捧的热点互联网产品，例如微博。考虑到负载均衡器一旦发生异常或宕机后，将对产品的美誉度和用户体验产生一定程度的影响，这属于无形成本的损失。正所谓“好钢要用在刀刃上”，我们可以优先将这类流量放到硬件负载均衡器上。
对于必须采用七层交换的重点服务来说，尽量避免同一重点服务的流量全部放在软件负载均衡器上。例如某重点服务分布于四个IDC内，则可考虑两个IDC内使用Haproxy，另外两个IDC使用硬件设备。这样一方面可以在一定程度上规避使用Haproxy可能带来的风险，另一方面也方便对软、硬件负载均衡器的稳定性、响应时间等进行长期对比观察。
要充分利用好同一IDC内的软、硬件负载均衡器，当一方负载高时，另一方可协助其分担流量，缓解燃眉之急。
总而言之，在负载均衡方面的支出正所谓该花则花、该省则省，合理使用可以让你在保障服务稳定的前提下，获得最佳的投入产出比。
挑战六：软件负载均衡器的资源复用，在降低成本的同时，同时也面临着一定的运维风险。
目前我们的软件负载均衡器分布于全国各地，其中一些中小规模IDC内的软件负载均衡器的负载并不是特别高，而这些机房普遍又需要VPN、自动安装等服务，单独为这些服务再放1~2组服务器显得很不划算。因此我们想到对软件负载均衡器进行资源的复用，即：在软件负载均衡器上同时运行VPN等服务。在实际中发现，这种资源复用面临两方面的风险：一是VPN、自动安装、负载均衡可能分属于不同的管理员，这样大家对同台服务器进行操作会增大因配置冲突、操作不当等导致的服务间互相影响的概率；二是非负载均衡的服务可能会突发占用过多的CPU或网络资源，对正常的负载均衡服务造成了一定的影响。由于LVS、Haproxy服务的特殊性，像Xen这类通过虚拟化来实现资源隔离的办法又不太适用；对服务器流量进行QOS设置，虽然可以起到一定的效果，但配置方面还是有些烦琐。还有更好的办法吗？这确实值得我们思考。
当然除了以上六方面挑战外，负载均衡领域还有很多值得研究之处。不同网站有不同的实际情况，希望本文能对大家起到抛砖引玉的作用。