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

星期八职场经验网()【现成经验助你快速完成工作】:..网站负载均衡技术架构经验作为业内的门户大站,新浪每天的访问量是惊人的。究竟如何做好如此大访问量的负载均衡工作,我们还是看看新浪内部技术人员是怎么说的。AD:记得上大学时,我和好友老郭讨论最多的话题便是:“像新浪这样的网站是如何支撑如此巨大的访问量?”也曾通过各种手段,猜测新浪服务器的数量、操作系统和应用软件的版本……一切都是那么神秘。毕业那年,有幸加入新浪,终于一点点地揭开了这层神秘的面纱。2004年某厂商设备介绍会上,我初次接触到了负载均衡技术。之后的几年时间,可以说是负载均衡设备在网站推广的黄金爆发期。发展到今天,一方面硬件设备依然保持了强劲的实力,另一方面以LVS、Haproxy为代表的软件负载均衡也异军突起,被人们所认可。在新浪,软、硬件负载均衡并存的格局已有三年多的历史了,除了既往积累的经验外,近一年来,我们也看到了负载均衡所面临的一些新挑战,在此跟大家分享。挑战一:Web应用对七层交换的依赖度越来越大,显著增加了负载均衡器的压力。七层交换技术的引入,极大地解放了架构师和程序开发人员,同时也使我们越来越习惯依赖于它,甚至直呼上瘾。很难想象,如果没有负载均衡器的话,现有Web架构中的大量需求应该如何实现?在充分享受其便利性的同时,我们也看到了一些隐忧。一方面越来越多的流量正从四层交换转为七层交换;另一方面七层交换的规则也越来越趋于复杂。在双重作用下,负载均衡器的压力急剧上升。对于任何一台负载均衡器来说:支撑相同的请求量,七层交换所消耗的CPU要远远高于四层交换。特别是在瞬间高并发连接的突发流量面前,负载均衡器面临着严峻的挑战。挑战二:微博等互联网新兴产品的出现,对负载均衡器的运维工作提出了更高的要求。微博不仅改变着亿万网民的生活,而且也正悄然推动着运维体系的建设。首先,与传统的新闻、博客相比,微博用户对服务质量的敏感度更高,而且这种敏感度会伴随着一次次的“@”和“转发”传播扩散。在过去,当用户访问新浪服务感到慢时,反映的渠道多是打客户电话。而现在只需要在微博上一个简单的“@”就可以与新浪的客服和技术人员直接沟通。作为流量进出的一个关卡,当微博等线上关键业务出现访问异常或故障时,工程师们都迫切地想知道:是负载均衡器的问题吗?此时故障诊断的效率显得至关重要。在实际工作中我们发现:单纯依靠负载均衡器提供的CPU、内存、连接数等统计信息,还不足以发现一些隐蔽问题。传统的抓包分析耗时耗力且效果不佳,再加上有些故障现象与客户端、后台服务器上的某些特殊设置有着千丝万缕的联系,所有这些交织在一起,给我们故障诊断带来了不小的挑战。例如有次我们发现:负载均衡器偶尔会给客户端返回HTTP 5xx的响应,当时特想快速地知道究竟是什么样的HTTP请求会触发这样的现象。但可惜的是,负载均衡器上仅有统计数字而没有请求的完整记录。在花了很大力气抓包分析后,最终定位到是由于后台一个PHP程序不小心给页面设置了一个错误的HTTPHeader,导致WebServer的HTTP响应不能被负载均衡器所接受,最终给客户端返回5xx。因此在故障诊断方面,我们需要有更先进的理念和手段。其次,微博在国内正处于快速成长期,会随时根据访问量来灵活调整