Web2.0负载均衡应用优化

　　作者: 佚名, 　出处: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应用访问速度