|
使用服务器负载均衡的用户，按照简单分类，可以为以下3大类： 第一类，性能要求。 流量猛增，单个服务器自然招架不住。这里面的客户包括各个上规模的网站，不管是做内容，做社区，做婚介，做直销，也不管你是卖衣服，卖包包还是卖茶叶，用户数增长带来的流量增长，使用负载均衡是早晚的事。而且针对广大的网站客户，通常简单的4层流量分担已经不能够满足他们的需求。内存缓存，硬件压缩，连接复用等等可以降低服务器负载的ADC功能越来越成为网站客户的必备手段。另外一点是网站客户的应用复杂，经常会有多个域名对应同一个IP以及同一服务器响应多个不同域名的情况，根据host （域名）做switch, 甚至7层的流量分发脚本要求也是非常常见的需求。 迫于性能压力里面的另外一大类是各个运营商。各个运营商的网上营业厅，内部的DNS系统，Radius用户认证系统，几乎是必须配置服务器负载均衡。但是运营商使用负载均衡的地方很广，几个关键系统是由于性能压力，其他大多数应用可能更多的是出于其他方面的考虑。 第二类，扩展要求。 这个类别有时很难和性能要求严格区分。最常见的是由于软件平台或者软件开发带来的瓶颈而不得不考虑负载均衡。例如一个很早就使用负载均衡的企业用户，并不是因为服务器的硬件或者带宽的要求不满足，而是基于软件开发的重要的内部ERP系统的软件性能限制，单台服务器根本无法满足内部需求，从而不得已使用负载均衡进行扩展。 这里典型的用户是大型企业的内部系统，很多企业由于内部需求，必须根据自身特点制作量身定制的众多内部应用，这些应用通常交给内部或者外包开发，着重点在于系统的功能完整性，通常对性能的考虑比较弱。在大规模使用时常常容易暴露出潜在的性能缺陷，必须通过简易的扩展功能加以解决。运营商的部分应用其实也属于这个范畴。 这类应用有个明显的特点，就是仍有众多应用使用C/S架构，使用自己的特有客户端做TCP通讯，负载均衡部署时通常需要考虑改变客户的网路结构，因为或者服务器需要记录客户源地址，或者服务器对NAT类同一地址发起的多个请求处理存在问题。 第三类，可靠性要求。 这个类别，相对来说对性能的要求比较低。例如政务网站，流量通常并不高，但是要求保持相对高可靠的在线时间。 四个9（即99.99%的可靠性）换算下来每个月故障时间<4分钟，一年不能超过一个小时。手工或者冷备几乎不可能达到这个标准。负载均衡，永不当机。针对这类需求，负载均衡设备已经成为一种必备的保障 SLA（服务水平协议）的手段。需要注意的是，在这类部署中，包括负载均衡本身也需要提供双机HA热备，和用户连接信息备份的机制，在单台负载均衡本身由于软硬件故障时刻，仍旧可以保证整个系统的可靠运行。 以上是简单的使用服务器负载均衡客户的总结，刚好也针对服务器负载均衡可以提供的三个功能， 也就是 Performance Scalability Availability,高性能，扩展性和可靠性。其实很多情况下三者互相相关，真正只因为其中一个原因才部署负载均衡的客户并不多见。 |
