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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

文章结尾，作者介绍了上述技术如何在亚马逊的 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