作者: 佚名, 出处:IT专家网, 责任编辑: 郭秋爽, 2008-06-03 17:14
本文分七个方面为大家介绍了Web2.0的负载均衡应用优化问题。
一、Web应用的发展-Web2.0
什么是Web2.0
Web2.0是2003年之后互联网的热门概念之一,不过目前对什么是Web2.0并没有很严格的定义。一般来说Web2.0是相对Web1.0的新的一类Internet应用的统称。Web1.0的主要特点在于用户通过浏览器获取信息,Web2.0则更注重用户的交互作用,用户既是网站内容的消费者(浏览者),也是网站内容的制造者。
所以,到目前为止,对于Web2.0概念的说明,通常采用Web2.0典型应用案例介绍,加上对部分Web2.0相关技术的解释,这些Web2.0技术主要包括:博客(BLOG)、RSS(也叫聚合内容的技术)、百科全书(Wiki)、网摘、社会网络(SNS)、P2P、即时信息(IM)、AJAX技术等。
国内典型的Web2.0网站主要包括一些以Blog和社会网络应用为主的网站,尤其以Blog网站发展最为迅速,影响力也更大,例如博客网( www.bokee.com)、DoNews IT社区(www.donews.com)、百度贴吧 (post.baidu.com)、新浪博客 (blog.sina.com.cn)等。
Web2.0应用的特点
海量的内容:Blog、播客、Wiki等应用在国内大量普及,每个用户都可以建立自己的网站,上传照片、Flash,甚至视频和音频,形成了Internet上前所未有的海量内容,因此部署Web2.0应用的网站都有一个共同的特点,就是需要海量的存储空间来储存这些内容。
大量的用户交互应用:Ajax技术的广泛使用提高了Web应用的丰富程度和交互性。相对于传统的Web应用——先下载一系列更新的HTML内容,然后在浏览的方式——Ajax应用通过客户端的Javascript“异步”的向后台服务器获取动态内容,再更新到客户端的浏览器界面上,使用户获得更好的访问体验。
用户自主的内容制作和分类:Web2.0应用最重要的是背后的人——数据不再和页面或网站混粘在一起,它开始跟着用户走。这也是为什么Blog是Web2.0的代表的原因。在Blog、播客这些应用中,每个用户都自主的创建自己希望和别人分享的内容,并且由这些个性化的内容,产生出大量的个性化的服务要求。
二、Web2.0给ICP企业带来的挑战
Web2.0会改变我们熟知的Internet生态,所以作为Web技术的先锋,各种大大小小的ICP似乎都在一夜间,宣称提供对于Web2.0的支持。然而Web2.0的特点也让很多ICP企业的IT支持人员伤透了脑筋。
先让我们看看现在多数ICP在Web应用架构吧:
为了适应海量内容的需求,同时也希望提高用户访问的体验(这关系到每个网站的服务质量),多数ICP通过在服务器前部署大量的Squid(一种被普遍采用的Cache系统)服务器,来起到对Web内容的缓存作用,同时部署负载均衡产品,通过简单的四层算法(比如Round Robin),将访问请求分配到不同的Squid服务器上,这也是传统Web应用(Web1.0)下最有效的应用模式,似乎到了Web2.0的时代,只需要线性的增加Squid服务器就可以了。
事情真的是这么简单吗?
海量的内容使传统Cache系统的利用率下降
在Web1.0的时代,Internet上的内容由有限的几个门户网站提供,内容量也很有限,因此经典的“8:2”原则非常有效-80%的用户只关心20%的内容,因此Squid这样的传统Cache应用模式(Squid+四层负载均衡)不但能提高用户访问的体验,而且可以降低后台服务器的压力。ICP不需要关心并优化不同内容在不同的Squid上面的分布情况(如果有1TB的内容,Cache系统只需要大约200~300G的硬盘空间,而现在一个服务器很容易就可以配置这样的硬盘存储容量)。
但是,Web2.0使Internet变得更加扁平化,“8:2”原则不再适用,每个用户都在寻找个性化的内容,80%的用户甚至在访问80%的内容,同时内容量也在指数性增长,因此Web2.0的,Cache系统需要应付一种离散的海量的内容请求特点(相对于Web1.0的集中的有限的内容请求)。而传统的Cache应用模式(Squid+四层负载均衡),会造成所有Squid服务器缓存的内容最终趋于一致,而无法服务于离散的海量内容请求的特点。如下图:
如果网站有2TB的图片(这对大型的Blog网站是非常容易达到的),配置10个200GB的Squid服务器做Cache,IT人员的期望是Cache系统至少能服务1TB以上的图片请求,但是随着时间的积累,由于Squid的Cache特点,以及传统的四层负载均衡设备的工作原理,10个Squid服务器上缓存的内容逐级趋于一样,实际上最后整个系统只能服务200GB的图片请求,这带来了两个重要的问题:
1,ICP在Squid服务器上的投资被浪费;(一个问题是:既然如此,为什么我们还需要很多Squid服务器呢?答案在于一个Squid服务器可以处理的流量有限。)
2,大量的请求会回到服务器上进行处理,增加了服务器的负载,进而要求ICP在服务器上更多的投资。
Ajax技术对系统形成巨大的性能压力:
Ajax“异步”更新内容的特点使Web应用具有更好的用户互动性,同时也鼓励Web应用开发者通过Ajax技术频繁的向Web服务器更新小量的数据或内容。这带来的负面效果是Web服务器需要处理更频繁的TCP连接和HTTP请求/响应。
虽然通过Squid服务器可以拦截大量的HTTP请求,但是Squid服务器和Web服务器有同样的弱点——对TCP连接的处理性能比较差。传统的服务器TCP/IP协议栈不是为了处理大量的TCP连接建立和拆除的工作而设计的,他们比较适合应用在少量TCP连接处理和大量数据传输的环境中。而大量的HTTP请求必然带来大量的TCP连接建立和拆除的工作。
传统的Cache应用模式(Squid+四层负载均衡)中,四层负载均衡设备只是简单的根据策略把HTTP请求和TCP连接分配到不同的Squid服务器上,因此前端有多少TCP连接,Squid服务器就要处理多少TCP连接,这对Squid服务器(以及后台Web服务器)是一个巨大的性能挑战。如下图:
用户个性化的内容访问需要保持性的流量分配
在Web2.0的时代,用户大量制作并访问自己感兴趣的内容,他们希望每次访问自己的需要的内容时,都能快速准确的获得服务。Blog就是典型的这类应用。很多Blog网站为了提高用户的体验,会预先把用户内容Preload到所有Squid服务器中,期望让用户获得更好的访问体验;但是这又进一步降低了Cache系统的整体利用率。
有些Blog网站希望把一个用户的内容只Preload到某一台Squid服务器上,然而传统的四层负载均衡设备没有智能将对该用户内容的访问请求,保持性的分配到对应的Squid服务器上,比如:用户A的内容被放到Squid A上,当有对用户A的内容的访问时,四层负载均衡设备很有可能把这个请求分配到Squid B,C,D…上,这带来的后果不仅是降低了用户访问的体验,而且进一步增加了后台服务器的负载。
更深入的挑战在于,每一个Squid服务器都需要下线维护,如果在维护后,这种保持性不能维持,那必然带来更多的IT负担和不稳定的用户体验。
因此,Blog网站需要找到一种方法,可以持续性的保持对某个用户内容的更新、访问请求与某个Squid服务器之间的对应关系。
对硬件环境的投资成指数增长
不论是希望对海量内容进行更多的缓存,还是应付频繁的TCP连接和HTTP请求,都使得ICP在服务器上的投资不断增加,而且随着Web2.0应用的进一步普及,这种增加的趋势正在成指数级的增长。
投资如果能带来合理的回报,那就不成问题;问题是,在服务器上的投资所带来的回报正在逐渐降低。ICP需要找到一种更合理的IT投资方法。
三、Web2.0与Array应用加速系统APV Web Accelerator
解决Web2.0带来的各种挑战的“钥匙”在于部署更加智能的应用加速和负载均衡产品,以更有效的发挥在现有硬件服务器上投资的作用。
Array APV Web Accelerator代表了新一代的应用加速和负载均衡产品,通过强大的Web应用智能处理引擎,APV可以提供高度集成的应用交付功能,包括七层的服务器负载均衡,TCP连接复用,内存Cache,集群和Web安全的功能。APV能够在极大地提高Web应用和业务平台的可用性、性能以及安全性的同时,降低网站系统的成本和复杂性。
Array APV Web Accelerator可以帮助支持Web2.0应用的ICP:
·增加Cache系统的整体利用率;
·降低Web2.0应用对系统的性能压力;
·为用户提供持续稳定的高质量访问体验;
·提高Web2.0Cache系统的ROI(投资回报率)
Array APV Web Accelerator通过集成应用以下独特的技术来到达以上目的:
·基于七层内容的智能负载均衡算法(Hash Header/Consistent Hash Header),更智能的根据业务需要分配访问请求;
·TCP连接复用极大的降低了服务器消耗在TCP连接处理上的性能;
·基于内存的快速缓存提供行业内最快速度的用户访问响应速度
·Web内容压缩降低了在网络上传输的数据量,提高Web应用访问速度