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应用对系统的性能压力;
·为用户提供持续稳定的高质量访问体验;
Array APV Web Accelerator通过集成应用以下独特的技术来到达以上目的：
·基于七层内容的智能负载均衡算法(Hash Header/Consistent Hash Header)，更智能的根据业务需要分配访问请求;
·TCP连接复用极大的降低了服务器消耗在TCP连接处理上的性能;
·基于内存的快速缓存提供行业内最快速度的用户访问响应速度
·Web内容压缩降低了在网络上传输的数据量，提高Web应用访问速度
四、增加Cache系统的整体利用率
Cache系统的利用率过低的原因是每个Squid服务器缓存了同样的内容，追源宿底，是由于传统的Cache应用模式(Squid+四层负载均衡)的工作原理造成的。最好的解决办法就是利用Array APV Web Accelerator的Hash Header技术，把用户对不同内容的请求分配到不同的Squid服务器上，最终使得每个Squid服务器缓存不同的内容。
Hash Header技术是Array独有的七层负载均衡算法，他基于七层的HTTP Proxy，分析每个请求中的HTTP Header，并对Header中的特定字段值执行Hash算法，根据算法结果把用户请求分配到特定的服务器上。
最常用到的是Hash URL的方法，根据HTTP Header中的URL，进行Hash计算，并做智能分配，可以到达以下效果：
1， 根据不同的URL，用户请求被分配到不同的服务器上;
2， 对同样的URL的用户请求，都会由同一台服务器进行响应。
回忆前面谈到的例子，同样还是2TB的图片存储，配置10个200GB的Squid服务器做Cache，在传统的Cache应用模式(Squid+四层负载均衡)下，整个Cache系统的缓存量最终趋向于只有200GB;但是如果采用Hash Header-URL的方法，通过把用户对不同内容的请求分配到不同的Squid服务器上，最终使得每个Squid服务器缓存不同的内容，最终整个Cache系统的缓存量将趋向于2TB;而且每个后续的用户访问请求都被智能的分配到已经有相应内容缓存的Squid服务器上，不会产生回到后台服务器的请求。如下图：Hash
Header-URL帮助ICP有效解决了以下两个问题：
1， 充分利用在Squid服务器上的投资，成倍的提高了Cache系统的利用率——上面的例子中，Cache系统的利用率被提高了10倍;
2， 由于回后台服务器的请求大大减少，因此不需要在服务器上做更多的投资。
五、降低Web2.0应用的性能压力
随着(不论是Squid还是Web)服务器上的TCP连接的增加——这是Web2.0应用的一个重要特征，也是Web2.0应用的性能压力的主要原因——最后服务器会用完全部的资源。这并不一定意味着服务器没有足够可用的内存或带宽，而是表明这个服务器的TCP/IP处理能力不能接受如此高的连接建立/拆除速率。引入TCP连接复用的技术，可以有效降低服务器消耗在处理TCP连接方面的资源。
TCP连接复用的目的是把大量的HTTP/TCP短连接转变为可以承载更多吞吐量的较少的HTTP/TCP长连接。这允许客户可以在不需要改变任何配置或内容的前提下，利用服务器的优化的批量吞吐处理能力。
TCP连接复用是通过利用HTTP/1.1中允许在同一个TCP连接中发出多个HTTP请求这一特性而设计的。因此Array APV Web Accelerator把许多用户端发来的单独的HTTP请求/TCP连接，捆绑到相对较少的连接服务器的TCP长连接中，而不是采用一对一的方式把每一个HTTP请求/TCP连接从用户端传递到后台服务器，这样Array APV Web Accelerator在处理多个用户端请求时，与服务器的TCP连接始终保持打开状态，从而消除了服务器消耗大量资源处理TCP连接的现象。
TCP连接复用技术的一个重要价值，是它将服务器频繁建立和拆除TCP连接的负担转移到了更加优化的TCP连接处理设备上——Array APV Web Accelerator。Array独特的SpeedStack技术和优化的TCP/IP协议栈，可以保证高性能的TCP连接处理。这样在没有对后台服务器进行任何改变或升级的情况下，相同的服务器硬件配置，却可以获得更好的业务性能。另一个可以降低Squid服务器性能压力的技术是Array APV Web Accelerator特有的基于内存的Cache技术。不同于传统的Cache技术，Array的Cache是完全基于内存的，用户经常请求的内容以Frame的方式存储在2GB的内存Cache中，可以快速响应用户的请求。如下图：
由于用户请求被Array的内存Cache直接响应，因此不再需要先后台Squid服务器发送请求，也进一步降低了Squid服务器的性能压力。
以下是一组说明组合使用TCP连接复用和内存Cache技术后，对降低Web应用性能压力的效果：
Stress parameters：99 threadsReal server statusRequests per Second
Client->Server
No APVCPU:33%135.86
Client->APV->Server
APV(Cache + connect reused)CPU:3% (Imporved 30%)151.76 (Imporved 12%)
很重要的一点，由于Web2.0应用的特点，Array APV Web Accelerator的内存Cache并不能取代Squid Cache系统，但是一起使用他们，会给ICP带来最佳的投资回报率(ROI)。
六、为用户提供持续稳定的高质量访问体验
Hash Header-URL对Blog应用具有非常大的应用价值。当某个用户的Blog在被访问时，访问请求中的URL通常会包含该用户的UserID，比如：http://blog.sina.com.cn/array，这里array就是一个UserID，因此基于Header-URL的Hash算法，可以使得每个用户的Blog内容都被固定的缓存在确定的Squid服务器上。
然而要彻底解决Blog应用的特殊需求――可以持续性的保持对某个用户内容的更新、访问请求与某个Squid服务器之间的对应关系——我们需要在Hash Header-URL基础上更进一步。这里的关键是如何解决内容更新的保持性，以及系统维护后的保持性恢复的问题。
内容更新涉及到HTTP Post和Purge的方法(通常我们访问Web应用时用到的是Get的方法)。Array APV Web Accelerator的Hash Header-URL算法不仅支持一般性的Get方法，而且也支持Post和Purge方法，因此如果Blog网站的IT管理员希望Preload或者清除某个用户在Squid中的内容缓存，Array APV Web Accelerator可以将这类操作请求定向到与这个用户的UserID对应的Squid服务器上，当下一个对该用户的Blog内容的访问请求到达时，这台Squid服务器就可以准确的把更新的内容响应给请求者。
Squid服务器下线维护是每个ICP必须要做的工作。下线维护必然带来保持性的暂时中断，这时Blog网站可以利用Array APV Web Accelerator的其他算法，把对下线服务器上缓存的用户内容的访问，暂时定向到一个友好的提示页面上，或者一个作为备份的Squid服务器上进行响应。但是当维护工作结束后，怎样能恢复原有的，对某个用户内容的更新、访问请求与某个Squid服务器之间的对应关系呢?
Array APV Web Accelerator提供了一种增强型的Hash Header-URL算法——Consistent Hash Header算法，他通过在系统启动时就预先确定某个用户内容与一台Squid服务器之间的保持性对应关系，使得即使短暂的对应关系中断，但是一旦这台Squid服务器恢复服务，仍然可以立刻恢复原有的某个用户内容与这台Squid服务器之间的保持性对应关系。
Consistent Hash Header算法的另外一个重要价值在于，为了提供高可靠性保障，Array APV Web Accelerator往往配置成两台以上的主备集群工作模式，如果集群中的主用设备出现故障，服务被切换到备用设备上时，某个用户内容与一台Squid服务器之间的保持性对应关系也不会发生中断。
总而言之，Array APV Web Accelerator的Hash Header-URL/Consistent Hash Header算法可以帮助Blog网站在充分利用Squid服务器资源的基础上，为用户提供持续稳定的访问体验。
Array APV Web Accelerator还提供增值的功能——Web内容压缩，提高用户访问Web系统的服务质量。Web内容压缩技术采用所有浏览器都支持的压缩算法，动态的根据浏览器的特性调整压缩策略，实时对多种Web内容进行压缩，包括：
·Text (text/plain)
·HTML (text/HTML)
·XML (text/XML)
·DOC (application/MSWord)
·Java Scripts (application/x-javascript)
·Cascade Style Sheets (text/css, application/x-pointplus)
·PDF documents (application/pdf)
·PPT documents (application/powerpoint)
·XLS documents (application/MSExcel)
经过压缩后的数据在Internet上传输时速度更快，特别是在低带宽，或者带宽质量不稳定的网络环境中(在中国，这样的网络环境还比较多，特别考虑到电信和网通的互联互通问题)，因此用户访问的体验得到很大提升。
七、提高Web2.0 Cache系统的ROI
面对Web2.0的挑战，ICP企业综合利用Array APV Web Accelerator负载均衡的各项特有的技术，可以为Web2.0应用带来巨大价值：
1.充分利用在Squid服务器上的投资，成倍的提高了Cache系统的利用率;
2.由于回后台服务器的请求大大减少，因此不需要在服务器上做更多的投资;
3.在没有对Squid服务器进行任何改变或升级的情况下，相同的服务器硬件配置，却可以获得更好的业务性能;
4.可以帮助Blog网站在充分利用Squid服务器资源的基础上，为用户提供持续稳定的高质量访问体验。
现在ICP企业可以修正他们的投资曲线，用有限的投资带来更多的回报，即更高的ROI!