DNS 负载均衡

我们知道，DNS 负责提供域名解析服务，当我们访问某个站点时，实际上首先需要通过该站点域名的 DNS 服务器来获取域 名指向的 IP 地址，在这一过程中，DNS 服务器完成了域名到 IP 地址的映射，同样，这种映射也可以是一对多的，这时候， DNS 服务器便充当了负载均衡调度器（也称均衡器） ，它就像前面提到的重定向转移策略一样，将用户的请求分散到多台服 务器上，但是它的实现机制完全不同。

多个 A 记录 

在 DNS 的各种记录类型中，A 记录你一定不陌生，它负责实现 DNS 的基本功能，用来指定域名对应的 IP 地址，常见的比较 成熟的 DNS 系统如 Linux 的 bind，以及 Windows 的 DNS 服务等，都支持为一个域名指定多个 IP 地址，并且可以选择使用各 种调度策略，常见的便是 RR 方式。

 我们先来看看其他站点的 A 记录设置，这毫无疑问是公开的，不存在任何私密，我们使用 dig 命令来查看 facebook.com 的 A 记录设置，如下所示：

这里我们首先看粗体部分，可以看到 facebook.com 拥有三个 A 记录，分别指向三个不同的 IP 地址，这意味着什么呢？接下 来我们通过 ping 命令来测试 facebook.com 域名的 A 记录解析，连续三次的测试结果如下所示：

果然，DNS 服务器使用三个不同的 IP 地址来轮流解析 facebook.com 域名，实现了 RR 调度策略。

 也许你觉得这里 DNS 服务器的职能有点类似于前面提到的重定向调度程序，的确有点，我们现在就对前面的 DNS 设置做一 番修改，让 DNS 来取代所谓主站点的工作，修改后的 DNS 设置如下所示：

这里我们仍然保留了 www1、www2 和 www3 的 A 记录，同时增加了三个别名（CNAME）记录，可以清楚地看到， www.highperfweb.com 指向了这三个 A 记录，从实际效果来看，以上设置也等同于：

这两种设置几乎没有什么性能上的差别，但是前一种设置也许可以满足你的一些需要，比如： 

如果你之前使用了重定向方案，那么你可能希望在一段时期内兼顾到老用户，如果他们愿意，仍然可以通过收藏的 类似 www3 等域名来访问站点，并期待你引导他们放弃旧的 URL。 

当你拥有很多 DNS 记录的时候，这样做使你的维护更加容易，比如你希望多个二级域名都指向同一个 IP 地址，那么 你可以用一个别名来代替 IP 地址，随后当你需要变更 IP 地址的时候，只需要修改别名的 A 记录即可。当然，你可 以起一些有意义的别名，而不像这里的 www1、www2 和 www3。 

可见，DNS 负载均衡的实现主要依赖于 DNS 服务器的设置，如果你的站点拥有自己的 DNS 服务器，那么以上的设置对于 DNS 管理员来说并不困难，但是，大多数站点仍然使用第三方 DNS 服务商，幸运的是，现在有很多 DNS 服务商完全支持多 个 A 记录的轮询设置，你可以根据需要来挑选。

扩展能力和可管理性 

和前面基于重定向的负载均衡方式相比，基于 DNS 的方案完全节省了所谓的主站点，或者说 DNS 服务器已经充当了主站点 的职能。

作为调度器，DNS 服务器本身的性能我们几乎不用担心，因为事实上，DNS 记录可以被用户浏览器或者互联网接入服务商的 各级 DNS 服务器缓存，只有当缓存过期后才会重新向该域名的 DNS 服务器请求解析，所以即便是采用了 RR 调度策略，我 们也几乎不会遇到 DNS 服务器成为性能瓶颈的问题。

另一方面，我们一般会配备至少两台以上的 DNS 服务器来提高可用性，还记得刚才我们通过 dig 命令获得 facebook.com 的 DNS 服务器列表吗？通过 NS 类型记录我们可以看到，它使用了 4 台 DNS 服务器。

既然负载均衡调度器不存在性能的制约，那么在这种方案下，整个系统的扩展能力理论上将可以被无限放大，比如我们通过 dig 命令看到 www.sina.com.cn 指向了 16 台服务器（甚至更多，但这已经足够了）。

当你不必为扩展担忧的时候，另一方面的问题便开始暴露，如何管理这么多的服务器呢？诸如内容同步、数据共享、状态监 控等问题都尤为重要，不过还好，在后续章节中我们会详细探讨这些内容，在这里，它们还不至于阻碍我们对 DNS 负载均衡 的热衷。

智能解析

尽管基于 HTTP 重定向的负载均衡系统受到主站点性能的制约，但是不可否认这种方案中的调度策略具有非常好的灵活性， 你完全可以通过 Web 应用程序实现任何你能想到的调度策略。

相比之下，为 DNS 服务器开发自定义的调度策略就不那么容易了，但幸运的是，类似 bind 这样的 DNS 服务器软件提供了丰 富的调度策略供你选择，其中最常用的就是根据用户 IP 来进行智能解析，这意味着 DNS 服务器可以在所有可用的 A 记录中 寻找离用户最近的一台服务器。

当然，如何利用这种策略，完全取决于你，你可以为用户比较集中的一些城市提供专用的服务器，接入城市核心节点，也可 以为各互联网运营商网络中的用户提供专用的服务器，并接入该运营商骨干节点，要做到这些，你还需要收集到相应的网络 地址分布数据，并添加到 DNS 服务器的智能解析策略中。

拿刚才的 www.sina.com.cn 域名来说，我们用另一台位于其他城市的服务器再次进行 dig 命令操作，结果如下所示：

这次看到的 A 记录指向了一个新的 IP 地址，这说明 DNS 服务器根据我们的来源进行了智能解析。有趣的是，我们再次更换 一个城市，结果又发生了变化，如下所示：

的确，IP 地址又变了。那么这些策略是否达到了“就近”解析的目的呢？这个任务还是交给你吧，你可以用 ping 命令来测试 你的 PC 到这些 IP 地址的响应时间，看看 DNS 服务器返回给你的 IP 地址是否就是最快的那个。

最后，如果你的站点在使用第三方 DNS 服务，也没有关系，有很多提供 DNS 轮询设置的服务商也都提供了智能解析服务， 你可以灵活地使用它们。

故障转移

对于负载均衡调度器后端的多台实际服务器，我们完全可以通过监控系统来实时了解它们的状态，一旦发现某台服务器出现 故障，这时候就需要立刻将它从调度策略中拿掉，也就是暂停指向该服务器的 DNS 记录，以免用户访问到发生故障的服务器 而感到莫名其妙。

对于基于 DNS 的负载均衡系统，要做到这一点的确让人非常头疼，因为有一个现实的问题是，我们一般不会将 DNS 记录的 TTL 设置为 0，这使得所有对 DNS 记录的修改都需要一定时间才能生效，比如一个 DNS 记录的 TTL 为 3600 秒，那么对它 的更新最多要过一个小时才会生效，这是我们无法容忍的，当然，用户更无法容忍。

另一方面，如何在意识到故障后的第一时间修改 DNS 记录，也是我们需要考虑的问题，在迫不得已需要容忍 DNS 记录更新 延迟的情况下，我们唯一能做的就是尽早修改 DNS 记录.

听起来一点也不难，也许你为站点搭建了专用 DNS 服务器，那么你可以通过修改配置来快速完成任务，如果你是在使用第三 方 DNS 服务，也没有关系，通过域名管理平台同样可以完成 DNS 修改工作。但是，这些都得依赖人力，的确，它们显得不 够快速和自动化，关键的时候时间就是一切，特别是当需要和监控系统集成实现自动故障转移时，这些方法都显得力不从心.

也许你听过动态 DNS，这其实是 DNS 协议的一个特性（Standard Dynamic update DNS，DDNS，RFC2126），它允许 DNS 服 务器开放特定的服务，为我们自动化远程修改 DNS 记录提供了可能。WWW.vxzsk.com整理。

这让我想起了现在几乎所有宽带路由器都支持的一个功能，那就是动态域名解析，你还有印象吗？当你的主机使用动态 IP 地 址接入互联网，并且你希望将某个域名指向这台主机时，所谓的动态域名解析便发挥了作用，它做的事情很简单，就是在每 次 IP 地址变更时及时地更新 DNS 服务器，当然，一定的延迟仍然是在所难免的，同样是因为 DNS 记录的 TTL。

利用同样的思路，当我们监测到某台实际服务器发生故障后，便可以通过动态 DNS 协议来迅速修改 DNS 记录。

一些不足

刚才我们已经提到了由于 DNS 记录的缓存带来的更新延迟，这导致我们对于调度器的控制总是跟不上节奏，这或多或少是一 件令人遗憾的事情。

相比于 HTTP 重定向方式的调度器，DNS 服务器更像魔术师，它可以在用户面前很好地隐藏实际服务器，没有用户能直接 看到 DNS 解析到了哪一台实际服务器，也没有人关心这个，但是与此同时，它也给服务器运维人员的调试带来了一些不便， 人们需要通过修改/etc/hosts 来为域名指定某个实际服务器的 IP 地址，以跳过 DNS 服务器变幻莫测的调度。

除此之外，在这种基于 DNS 的负载均衡框架之下，负载均衡调度器工作在 DNS 层面，这导致它的调度灵活性被或多或少地 削弱，策略的开发存在一定的局限性，比如你无法将 HTTP 请求的上下文引入到调度策略中，而在前面介绍的基于 HTTP 重 定向的负载均衡系统中，调度器工作在 HTTP 层面，它可以在充分理解 HTTP 请求之后根据站点的应用逻辑来设计调度策略， 比如根据请求的不同 URL 来进行合理的过滤和转移。

另一方面，根据实际服务器的实时负载差异来调整调度策略，这需要 DNS 服务器在每次解析操作时分析各服务器的健康状态， 对于 DNS 服务器来说，这种自定义开发存在较高的门槛，更何况大多数站点只是使用第三方 DNS 服务，根本没有自主开发 的可能，所以大多数人只能享受到单一的 RR 调度算法。

事实上，就算是 DNS 服务器能够做到最完美的调度，也不要忘了，DNS 记录缓存的出现将会再次成为毁灭者，各级节点的 DNS 服务器不同程度的缓存会让你晕头转向，如此庞大的体系简直是太复杂了，完全超出我们的分析能力，你得研究地理、 人口、城市、交换节点等，从来没有见过如此复杂的事情，还是算了吧。

的确，DNS 服务器充当了一个粗放型的请求调度器，这给我们带来了一些遗憾，在这种情况下，如何让多台实际服务器最大 程度地保持比较均衡的负载，是我们需要持续考虑的问题。

这里顺便说一下，所谓的“均衡” ，不能狭义地理解为分配给所有实际服务器的工作量一样多，因为有时候，多台服务器的承 载能力各不相同，这可能体现在硬件配置、网络带宽的差异，也可能因为某台服务器身兼多职，我们所说的“均衡” ，也就是希望所有服务器都不要过载，并且能够最大程度地发挥作用。

这里我们拿点真实的数据来看看，在我过去参与开发的一个站点中，同样是基于 DNS 的负载均衡，采用 RR 调度方式，有两 台同样配置的实际服务器 web127 和 web129，作为站点的动态内容服务器，你可以认为这两台服务器的承载能力完全相同， 而且我们希望它们能够完成同样的工作量。

我们分别来看看这两台服务器在最近 24 小时内的 WAN 网卡流量和系统负载，首先看看它们的 WAN 网卡流量图，如图 2-3 和图 2-4 所示。

图 2-3 服务器 web127 的 WAN 网卡流量图

图 2-4 服务器 web129 的 WAN 网卡流量图

注意以上这两幅图的纵坐标比例是不同的，从总体上看，不论是从网卡流入还是流出的数据量，web129 都要明显大于 web127， 而且两者的变化趋势几乎没有太多相似的规律。

接下来我们看两台服务器的系统负载图，如图 2-5 和图 2-6 所示。

图 2-5 服务器 web127 的系统负载曲线图

图 2-6 服务器 web129 的系统负载曲线图

显然，作为调度器的 DNS 服务器并没有很好地完成工作量均衡分配，而且差异比较大，这也在我们的意料之中，当然，这种 差异的程度随着应用场景的不同会发生变化，总之，当你了解了这些内容后，是否选择基于 DNS 的负载均衡方式完全取决于 你的需要。