前端工程师-网站负载均衡技术架构经验

1、.星期八职场阅历网xingqiba【现成阅历助他快速完成任务】：.；网站负载平衡技术架构阅历作为业内的门户大站，新浪每天的访问量是惊人的。终究如何做好如此大访问量的负载平衡任务，我们还是看看新浪内部技术人员是怎样说的。AD： 记得上大学时，我和好友老郭讨论最多的话题便是：“像新浪这样的网站是如何支撑如此宏大的访问量？也曾经过各种手段，猜测新浪效力器的数量、操作系统和运用软件的版本一切都是那么奥秘。毕业那年，有幸参与新浪，终于一点点地揭开了这层奥秘的面纱。2004年某厂商设备引见会上，我初次接触到了负载平衡技术。之后的几年时间，可以说是负载平衡设备在网站推行的黄金迸发期。开展到今天，一方面硬件设

2、备依然坚持了强劲的实力，另一方面以LVS、Haproxy为代表的软件负载平衡也异军突起，被人们所认可。在新浪，软、硬件负载平衡并存的格局已有三年多的历史了，除了既往积累的阅历外，近一年来，我们也看到了负载平衡所面临的一些新挑战，在此跟大家分享。挑战一：Web运用对七层交换的依赖度越来越大，显著添加了负载平衡器的压力。七层交换技术的引入，极大地解放了架构师和程序开发人员，同时也使我们越来越习惯依赖于它，甚至直呼上瘾。很难想象，假设没有负载平衡器的话，现有Web架构中的大量需求应该如何实现? 在充分享用其便利性的同时，我们也看到了一些隐忧。一方面越来越多的流量正从四层交换转为七层交换；另一方面七层

3、交换的规那么也越来越趋于复杂。在双重作用下，负载平衡器的压力急剧上升。对于任何一台负载平衡器来说：支撑一样的恳求量，七层交换所耗费的CPU要远远高于四层交换。特别是在瞬间高并发衔接的突发流量面前，负载平衡器面临着严峻的挑战。挑战二：微博等互联网新兴产品的出现，对负载平衡器的运维任务提出了更高的要求。微博不仅改动着亿万网民的生活，而且也正悄然推进着运维体系的建立。首先，与传统的新闻、博客相比，微博用户对效力质量的敏感度更高，而且这种敏感度会伴随着一次次的“和“转发传播分散。在过去，当用户访问新浪效力感到慢时，反映的渠道多是打客户。而如今只需求在微博上一个简单的“ 就可以与新浪的客服和技术人员直接

4、沟通。作为流量进出的一个关卡，当微博等线上关键业务出现访问异常或缺点时，工程师们都迫切地想知道：是负载平衡器的问题吗？此时缺点诊断的效率显得至关重要。在实践任务中我们发现：单纯依托负载平衡器提供的CPU、内存、衔接数等统计信息，还缺乏以发现一些隐蔽问题。传统的抓包分析耗时耗力且效果不佳，再加上有些缺点景象与客户端、后台效力器上的某些特殊设置有着千丝万缕的联络，一切这些交错在一同，给我们缺点诊断带来了不小的挑战。例如有次我们发现：负载平衡器偶尔会给客户端前往HTTP 5xx的呼应，当时特想快速地知道终究是什么样的HTTP恳求会触发这样的景象。但惋惜的是，负载平衡器上仅有统计数字而没有恳求的完好记

5、录。在花了很大力气抓包分析后，最终定位到是由于后台一个PHP程序不小心给页面设置了一个错误的HTTP Header，导致Web Server的HTTP呼应不能被负载平衡器所接受，最终给客户端前往5xx。因此在缺点诊断方面，我们需求有更先进的理念和手段。其次，微博在国内正处于快速生长期，会随时根据访问量来灵敏调整效力器的数量和系统架构。在这种快速灵敏的变化面前，负载平衡器相关的配置调整任务也随之添加：频繁的上下线效力器、变卦七层规那么等。面对这种情况，我们需求思索：如何能更加快速平安地完成好这些变卦、如何能防止工程师每天被动地堕入这些反复烦琐的任务中等。目前一些硬件设备提供了API接口，像增删S

6、erver、调整Server 权重等这类风险性极低的操作可经过API接口操作，以到达提高效率的目的。而Haproxy、LVS那么缺乏这样的 API接口，需求单独开发。除此之外，关键运用对负载平衡器的监控也有越来越多的新需求。比如：有些运用希望当负载平衡器检测到效力器池中活泼的效力器数量少于一定比例后，便提早给系统管理员作出预警；及时发现效力器池中权重等设置不合理的问题等。挑战三：多核处置器时代下，Haproxy等用户态的软件负载平衡正面临新的性能瓶颈。近几年来CPU开展进入了多核时代，CPU由过去的单核开展到四核、六核、八核、十二核，甚至更多，而主频那么变化不大。在这种趋势下，充分利用多核特性

7、显得尤为重要。但在我们研讨中发现，像Haproxy这类基于用户态的软件负载平衡，其对CPU主频的依赖度要远远高于CPU核数。换言之，在高主频、核数少CPU下的性能很有能够要优于低主频、核数多的CPU。这一点，在Haproxy效力器选型时尤为重要。据我们分析，这主要是由于操作系统对多核多CPU下的并发支持度还不够好。挑战四：软件负载平衡开展路上的“鸡蛋-篮子实际的困难选择。硬件负载平衡器往往以单台高性能著称，而Haproxy、LVS为代表的软件负载平衡的优势那么在于本钱低廉、可灵敏定制，其性能与效力器CPU、网卡等硬件直接相关当然特殊的优化也很重要。正如前面提到的，当七层交换流量越来越大时，我们

8、终究是该投入本钱让单台LVS、Haproxy足以支撑如此大的流量，还是让更多中等性能的效力器共同分担这些流量呢？这就是所谓的经典的“鸡蛋篮子实际：终究该不该将鸡蛋放到一个篮子里呢？其实不同的选择各有利弊。23年前，我比较赞同将流量分摊到多台软件负载平衡器上，当时主要思索到风险的分散。而如今，我更倾向于将流量集中于一台上。之所以这样，是从以下四个角度思索的。第一，目前国内IDC内每个机架所放效力器数量跟电力配额直接相关。而负载平衡由于其特殊性，往往是两台为一组，这样每添加一组都会添加额外的电力开销，特别是在电力资源紧张的IDC内，提高单台软件负载平衡器的承载才干可以为关键业务腾出更多的机架来。第

9、二，从效力稳定角度思索，我们通常会将LVS、Haproxy直连中心交换机，如此一来，每添加一组，就意味着会占用更多的中心交换机端口资源。第三，是基于管理本钱的思索。LVS、Haproxy之所以能在新浪得到广泛运用，较低的管理本钱是重要缘由之一。在新浪我们经过一套集中管理平台和快速初始化的方法实现了运维本钱的非线性添加。但不可否认的是，每新增一组，运维本钱或多或少总会添加一些。之前也曾设计过一套“同机房内负载平衡器的集群池方案，即：在一个机房内主备机的数量比不再固定为1:1， 虚拟IPVIP会根据集群池中每台Haproxy/LVS的负载情况，动态地“漂在其中某台上。但后来发现这个“听起来很美的方

10、案，在实践运转中遇到了种种问题，运维本钱不降反升。最终我们又回归了传统的1台Active+1台Standby的方式，正所谓简单即是美。第四，目前硬件负载平衡器正朝着“更高的性价比方向开展，换句话来讲，假设我们不提升软件负载平衡器的单机支撑才干，那么终有一天，其与硬件设备相比的本钱优势将会淡去。挑战五：在新时期下，如何找到负载平衡的最正确软硬结合之道？朋友、同行聚会时，常有人问我：“他们有了Haproxy、LVS后，会不会不买硬件设备了？、“他最近又在山寨什么？每次听到这些，我都会悄然一笑。如前文所述，Haproxy、LVS这类的软件负载平衡和硬件设备各有优势，在我看来，负载平衡的“软、“硬处理

11、方案并非水火不容，只需找到最正确的软硬结合之道，鱼和熊掌还是可以兼得的。下面是我们在长期探求中，总结出来的一些阅历。软件负载平衡可优先承当四层交换流量，让硬件设备更专注于七层交换：由于任务方式和原理的不同，专注于四层交换的LVS在稳定性、单机支撑才干、易维护性、管理本钱等多方面均要大大优于Haproxy。特别是在DR方式即单臂下， 单台LVS足以应对绝大多数业务的访问量。优先保证“明星产品占用珍贵的硬件设备资源：这里指的“明星产品是指那些用户群正处于快速增长，并被广泛追捧的热点互联网产品，例如微博。思索到负载平衡器一旦发生异常或宕机后，将对产品的佳誉度和用户体验产生一定程度的影响，这属于无形本

12、钱的损失。正所谓“好钢要用在刀刃上，我们可以优先将这类流量放到硬件负载平衡器上。对于必需采用七层交换的重点效力来说，尽量防止同一重点效力的流量全部放在软件负载平衡器上。例如某重点效力分布于四个IDC内，那么可思索两个IDC内运用Haproxy，另外两个IDC运用硬件设备。这样一方面可以在一定程度上躲避运用Haproxy能够带来的风险，另一方面也方便对软、硬件负载平衡器的稳定性、呼应时间等进展长期对比察看。要充分利用好同一IDC内的软、硬件负载平衡器，当一方负载高时，另一方可协助其分担流量，缓解燃眉之急。总而言之，在负载平衡方面的支出正所谓该花那么花、该省那么省，合理运用可以让他在保证效力稳定的

13、前提下，获得最正确的投入产出比。挑战六：软件负载平衡器的资源复用，在降低本钱的同时，同时也面临着一定的运维风险。目前我们的软件负载平衡器分布于全国各地，其中一些中小规模IDC内的软件负载平衡器的负载并不是特别高，而这些机房普遍又需求VPN、自动安装等效力，单独为这些效力再放12组效力器显得很不划算。因此我们想到对软件负载平衡器进展资源的复用，即：在软件负载平衡器上同时运转VPN等效力。在实践中发现，这种资源复用面临两方面的风险：一是VPN、自动安装、负载平衡能够分属于不同的管理员，这样大家对同台效力器进展操作会增大因配置冲突、操作不当等导致的效力间相互影响的概率；二是非负载平衡的效力能够会突发占用过多的CPU或网络资源，对正常的负载平衡效力呵斥了一定的影响。由于LVS、Haproxy效力的特殊性，像Xen这类经过虚拟化来实现资源隔离的方法又不太适用；对效力器流量进展QOS设置，虽然可以起到一定的效果，但配置方面还是有些烦琐。还有更好的方法吗？这确实值得我们思