图解 DNS 域名解析与负载均衡

在 DNS 查询 篇中，主要是根据阮一峰老师的文章所做的学习记录。讲述了通过命令 dig 来跟踪域名的查询过程，也提到了 DNS 服务器的层级结构、DNS 记录、DNS 缓存等。整体都是文字叙述，读起来会稍微有些累。这篇会通过图示来进一步简化 DNS 的解析过程，并会提到 DNS 的另一项重要作用， 负载均衡 。

首先我们来了解一下 DNS 服务器。主要有三种类型的 DNS 服务器：

DNS 服务器的层级是树状结构，如下图所示：

假设我们需要在浏览器上访问https://www.baidu.com 网页，浏览器识别到访问的是个域名而不是 ip 地址时，会开始发起域名解析的过程。用户电脑上运行着 DNS 应用客户端，我们把它叫做本地 DNS 解析器。

首先我们先来回顾一下域名解析的整个过程，稍后会以图示的方式展现。

本地 DNS 服务器地址会配置在本机。如果是采用 DHCP 动态获取 IP 地址的方式，那么一般会被配置为网络运营商的 DNS 服务地址；或者可以自己配置为非权威 DNS 服务器地址，比如 google 的 8.8.8.8 。

那么它如何知道根域名服务器的地址呢？很简单，根域名服务器数量少，其地址会配置在本地 DNS 服务器中。

整体流程如下图所示，其中白色箭头表示查询方向，绿色箭头表示返回方向。

DNS 的另一个作用是做负载均衡， Server Load Balance 。

最简单的一种应用情况，在 DNS 服务器上配置某个域名对应的 ip 时，可以配置多个 A 记录，即一个域名对应多个 ip。这里可以配置不同的策略。

当客户端请求域名解析时，DNS 服务器返回全部 ip 地址。客户端拿到多个 ip 后可进行轮询，或者是随机选择一个 ip，或者是按照某种算法选择一个 ip 进行请求。

假设配置了 ip1, ip2, ip3 三个地址。第一次请求返回 ip1，第二次请求返回 ip2，以此类推。

设定各个 ip 的权重，优先返回权重大的 ip。

另外一种复杂的应用情况，做全局的负载均衡，即 GSLB，Global Server Load Balance 。全局上可分为运营商和区域，在同一个运营商上进行访问肯定速度更快；同样，请求的服务器距离客户端越近，速度越快。

那全局负载均衡如何实现呢？跟添加中间层的思想差不多，经过中间层 GSLB 来控制负载均衡策略。下面介绍两种方式。

具体做法是，在权威 DNS 服务器上给目标域名配置一条 NS 记录， A → B ，即 A 对应的域名服务器地址为 B，也就是 GSLB 的地址 ，让 GSLB 来充当 权威域名服务器 。

当 DNS 解析 A 域名时，会返回设置好的 B。这样本地 DNS 服务器就会转到请求 B 也就是 GSLB 去进行域名解析， GSLB 就可按照某种策略进行负载均衡计算，比如根据本地 DNS 服务器的所属运营商和本地 DNS 服务器的位置返回合适的 ip。

假设查询的目标域名为 http://www.company.com ，设置一条 NS 记录为 http://www.company.com → http://www.companyOk.com 。那么当查询 www.company.com 时，DNS 服务器会返回 www.companyGSLB.com 。然后本地 DNS 服务器会去请求 www.companyGSLB.com DNS 服务器，让该权威域名服务器去解析 www.company.com 域名，返回合适的 ip 地址。这样，控制权就交到了 www.companyGSLB.com 手上，具体策略可以由它自己来确定。

但是这种方式只能知道本地 DNS 服务器所属的运营商和 ip 地址，而不是客户端的 ip。

流程如下图所示：

通过给域名添加别名的方式来实现，有两种不同的方式。

a. 设置别名后，再通过 http 重定向

给目标域名 A 配置别名 CNAME，也就是 GSLB 的域名。这样请求解析 A 域名时会返回 CNAME 记录，之后本地 DNS 服务器会转为请求 GSLB 的域名，最后返回 GSLB 的 ip 地址。

这样，客户端就会跟 GSLB 进行通信，GSLB 可以知道客户端的 ip 地址，进而根据一系列的策略进行调度，然后利用 http 重定向将客户端定向到合适的地址。

流程如下图所示：

b. 设置别名，通过 NS 记录转到不同的 GSLB 域名服务器

给目标域名设置别名，对别名设置 NS 记录，转到不同的 GSLB 去查询。

举个栗子：比如在 company.com 的权威服务器上给域名 test.company.com 设置别名 hello.test.comany.com。

当本地 DNS 服务器请求解析 test.company.com 时，流程如下：

流程图如下：

这里只有一层 GSLB，也可以有多层。假设第一层 GSLB 是用来区分运营商，第二层 GSLB 是区分区域。

比如本地 DNS 服务器所在运营商是移动，那么在 xx.GSLB1.com 就可返回另一个别名 yd.test.comany.com 。 yd.test.comany.com 也对应一条 NS 记录， yd.test.comany.com → xx.GSLB2.com ，这样就将 yd.test.comany.com 转到第二层 GSLB 去解析。 GSLB2 就可根据本地 DNS 服务器的位置返回距离用户较近区域的 ip。

六个步骤。1.用户向本地DNS服务器发出查询请求；2.本地DNS服务器进行递归查询；3.授权DNS服务器其返回一条NS记录给本地DNS服务器；4.本地DNS服务器向其中一个GSLB地址发出域名查询请求；5.GSLB设备选出最优解析结果，返回一条A记录给本地DNS服务器；6.本地服务器将查询结果通过一条记录返回给用户，并将缓存这条记录。以上内容根据牙木科技网络素材整理

当网站的访问量大了就会考虑负载均衡，这也是每一个架构师的基本功了，其基本地位就相当于相声里的说学逗唱，活好不好就看这个了 :)

传统的负载均衡思路是单点的，不管你是硬件的还是软件的基本都是这样的原理，如下图所示：

对于一般的需求来说，这样的架构基本就可以解决问题了，而且维护起来也相对简单，大多数公司也都是这么干的。

传统思路的局限性

就如同上图所示，传统思路也存在非常明显的局限性。

也就是说，网站的响应速度很大程度上局限于负载均衡节点的能力，而且一旦负载均衡节点本身挂掉的话，整个网站就完全瘫痪了。

后端的服务可以水平扩展，但是对于单个节点来说就算你再增大机器的配置也是有极限的，而且这也不符合互联网技术的发展规律。

CDN是怎么做的

作为互联网上承载大部分流量的一大基础设施，CDN对负载分流的解决思路很具有启发性，如下图：

从上图可以看到，用户的访问被分流了，所有的请求不再是聚集到一个节点上，而是被分担在了各个合适的节点上。

这样即使存在单点故障，也仅仅只会影响到一部分用户，况且我们还可以使用其他手段做故障转移。

同样的做法也可以借鉴到传统的 BS 架构中，我们也可以把用户的请求直接分流到不同的服务器上，而不必经过一个统一的节点中转。

这个分流是通过什么做到的呢？

答案就是：DNS

你知道DNS是怎么工作的吗？

大部分人可能天天都用着DNS却不知道它的基本原理，你可能知道我们访问互联网需要查询dns服务器，就是下面的这个玩意

我们只需要问它域名所对应的ip地址就行了。

但事情真的这么简单吗？它是怎么知道这个域名所对应的ip地址呢？

其实dns系统是一个典型的树状架构，上图所示的dns服务器其实应该叫dns缓存查询服务器，它是为了减轻互联网上dns查询的负载所设计的。

如果你的请求没有命中缓存，那么这个缓存服务器就会自己进行一次标准查询，然后再把结果缓存起来，简单来说就是从根服务器开始一级一级的问。

我们以前经常谈到根服务器的重要性其实就体现在这里了，它保留了对所有域名的起始解释权

神奇的解释权机制(SOA)

上面讲到根服务器拥有一切域名的起始解释权，但是如果你去问根服务器它是不会直接告诉你最终答案的。

因为如果它要存储所有的记录，那它也太累了，这个负载和开销是惊人的。

那它会告诉你什么呢？它会告诉你应该去问谁，也就是它授权下一级服务器来解答你的问题。

我们来看下面的拟人化过程：

1.我: root, root 告诉我， segmentfault.com 怎么走？

2.root: 呵呵，你可以去问.com的dns服务器，地址是xxxxxx

3.我: .com, .com 告诉我，segmentfault.com 怎么走？

4..com: 呵呵，你可以去问segmentfault.com的dns服务器(dnspod之类的)，地址是xxxxxx

5.我: dnspod, dnspod 告诉我，segmentfault.com 怎么走？

6.dnspod: 拿着 xxxxxx，走你

DNS负载均衡的基本原理

了解了上述过程，我们得到两个基本结论

1.dns系统本身是一个分布式的网络，它是相对可靠的，起码比你网站本身可靠的多

2.dns的最终解释是可以受我们自己控制的

有了这两条结论，剩下的事情就简单了，我们只需要在最终解释的查询结果上做文章就可以了。

简单来说，就是将你的所有服务器地址，按照自己需求制定的频次，返回给用户。

以github.com为例，我们首先获取它的SOA服务器（因为dns缓存查询服务器会缓存结果，如果你直接去查询域名，会每次返回一样的结果），.com的dns域名服务器也是13台，它们是[a-m].gtld-servers.net，我们随便选一台来找找github.com的SOA.如下图：

OK，我们获取了四个SOA服务器 ns[1-4].p16.dynect.net，再随便选一个来问问github.com对应的记录吧，顺便试几次看看最终的ip地址会不会变化

我们这里查询了两次，注意 ANSWER SECTION 部分返回了两个结果，一次是192.30.252.129，一次是192.30.252.128。

这就是利用dns实现了负载均衡，你的最终访问会到达不同的ip地址。

有哪些DNS服务商支持负载均衡呢？

这是一种比较高级的服务，一般域名注册商的dns服务器不会支持，目前我已知支持它的服务商有：

1.AWS Route 53

2.NSONE

3.Dyn

4.dnspod

其中1和4是我们已经在使用的，效果比较理想。

总结

其实DNS可以玩的花样远不止这些，还可以做故障转移，也可以按地区解析等等。

域名从互联网诞生之初就开始存在了，但是对它的研究以及衍生出来的使用方法才刚刚开始发掘，随着大家对互联网利用的提升，这类技术肯定会越来越多。

---