AJAX应用的客户端负载均衡问题探究

作者 Gavin Terrill译者 王翔(Vision Wang) 发布于 2007年10月10日 下午8时48分

社区 Architecture 主题 RIA, 性能和扩展性

今天，当我们选择负载均衡时，大部分Web应用集群选择基于软件或硬件的服务器端方案，而《Digital Web Magazine》最近发表的一篇文章讨论了一家公司如何在EC2支持的应用中实现客户端负载均衡。

文章从负载均衡方案的需求谈起：

需要在应用服务器集群中分担负载； 温和地应对单个服务器的宕机； 确保在最终用户端可以把这组服务器视为一个单独的服务器。

作者朱磊（音译 Lei Zhu）分析了我们常用的服务端负载均衡手段——循环DNS（Round Robin DNS），文中提到：

很不幸，循环DNS的主要弱点是不能满足上面提到的第二个需求，当两台服务器中的一台宕机时，DNS服务器仍然会继续把请求发给它，这导致一半用户无法获得响应。

他还指出集群前端软、硬件专用方案的不足：负载均衡器（Load Balancer）自己总有一个响应数量上限，尽管可以通过循环DNS配合专用负载均衡器解决这一问题，但维护一个专用负载均衡器需要额外投入数万美元，而且通常后备负载均衡器只有在主设备出现故障后才会发挥作用。

在客户端负载均衡概念的介绍中，作者请读者考虑关于桌面应用如何负载均衡的问题：

桌面程序随机选择一台服务器，然后尝试获取数据，如果服务器不可用或没有在预设的时间内响应，那么就选择另一台服务器，直到可以提取数据。桌面应用与Web应用不同的是，前者是独立于服务器，可以在客户端通过对服务器访问的负载均衡实现应用的可扩展性，而后者把客户端代码（JavaScript或Flash WSF）保存在提供数据和资源的服务器上。

为了把概念延伸到Web应用，作者剖析了典型AJAX应用的关键组成：

客户端代码：JavaScript/Flash客户端的SWF； 资源：图片、级联样式表、音频和视频文件、HTML文档； 服务端代码：用于反馈客户端所需数据的后台逻辑。

其中1、2两类内容相对静止，一般不像第3类那样有负载均衡的需要。关注于第3类组成，作者建议采用可靠的服务器或者像亚马逊S3那样的服务，它描绘的策略如下：

就像桌面应用一样，我们可以把一个应用服务器列表嵌到客户端代码里，Web客户端包括一个称为Servers.XML的文件，它保存了可用服务器的列表。客户端通过AJAX或者Flash访问列表中的每一个服务器，直到找到一台可响应的。

尽管浏览器可以禁止客户端代码向它所来源的那些服务器之外的服务器发起服务端调用，但作者还是建议采用Flash或JavaScript的方案解决这个问题。采用客户端负载均衡有两个好处：

不需要额外的服务器设备，“不需要专用负载均衡设备，无需配置负载均衡硬件或确认备份功能和主负载均衡器是否正常工作”； 服务器可以被物理隔离，“由于是客户端选择服务器而不是由一个固定的负载均衡器重定向调用，所以服务器的位置不受限制”。

文章结尾，作者介绍了上述技术如何在亚马逊的EC2和S3基础上构造一个叫VoxLite的具有高可用性和可扩展性的视频资讯应用，不过作者并没有架构出一个没有单点故障的负载均衡方案。

很多Web应用会面向特定区域，通过一个动态DNS支持的EC2实例实现调用的负载均衡。如果提供负载均衡的这个实例出现故障，在动态DNS映像到另一个EC2实例前，整个系统就不可用了。

为了克服这个问题，VoxLite通过向S3发起HTTP GET调用获得可用的服务器列表，该列表由EC2实例的一系列任务维护：

1. 加载并解析http://s3.amazonaws.com/voxlite/?prefix=servers。
2. 如果当前运行实例没有被列出来，就向一批EC2实例的关键服务器各发送一个空文件；
3. 通过测试到亚马逊内部Web服务IP地址的连接情况，可以验证该批其他服务器的是否运行正常，如果无法建立连接就把该服务器从这批服务器的列表中删掉。

根据你的需求，客户端负载均衡在统一负载均衡的架构下，提供了一个有趣且具创新性的选择。作者总结道：

通过在客户端负载均衡中采用S3和EC2，可以简化搭建一个具有弹性、扩展性、健壮性Web应用的工作。

查看英文原文：Client side load balancing of Ajax applications