公司架构师常常提起的DNS负载均衡是个什么鬼？

「爱情、让人受尽委屈。」 2023-01-13 09:00 68阅读 0赞

点击上方蓝色“石杉的架构笔记”，选择“设为星标”
    回复“PDF”获取独家整理的学习资料！

![8e4c6b6195dd01b917d753a266de2b19.png][]

**![a31282a36ff89f4ce79459c3a7fbf13b.png][]**

![b73cc39d9183a6f056ae9c51c1f446c8.png][]

长按扫描上方免费领取

![715280f1134d04b06eaf27d3530234ac.png][]

*  传统思路的局限性
 *  CDN是怎么做的？
 *  神奇的解释权机制（SOA）
 *  DNS负载均衡的基本原理
 *  总结

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

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

![3180c14bb7e771afaf343bf2e3b8e1e3.png][]

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

##     ##

## **传统思路的局限性** ##

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

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

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

## **CDN是怎么做的** ##

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

![2b4cd39c3a444b30de20381bf62d42b0.png][]

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

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

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

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

答案就是：**DNS**

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

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

![911d6ee5c180067629e5979ccf466486.png][]

我们只需要问它域名所对应的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，走你

![78a3e1791babca9cb694658cc1dbff17.png][]

##     ##

##  ##

## **DNS负载均衡的基本原理** ##

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

1.  dns系统本身是一个分布式的网络，它是相对可靠的，起码比你网站本身可靠的多
2.  dns的最终解释是可以受我们自己控制的

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

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

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

![a4313803c8ecff929d0623af6dce6917.png][]

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

![3e86588fb059404b007e90776f836d98.png][]

我们这里查询了两次，注意 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可以玩的花样远不止这些，还可以做故障转移，也可以按地区解析等等。

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

**END**

作者：默默淡然

来源：

https://www.cnblogs.com/liangxiaofeng/p/5169404.html

本文版权归作者所有

![85bb4ebf397bb9a5255ae42774ee7355.png][]

[8e4c6b6195dd01b917d753a266de2b19.png]: /images/20221022/995f247e8fb949b1bdaa558765be288f.png
[a31282a36ff89f4ce79459c3a7fbf13b.png]: /images/20221022/e4891cabe7e34986a40be5abc596a1fa.png
[b73cc39d9183a6f056ae9c51c1f446c8.png]: /images/20221022/fc4bc32707ce4b0c9fe049948dcfb034.png
[715280f1134d04b06eaf27d3530234ac.png]: /images/20221022/050cc2ef19a44cc0ac75c2b539e93718.png
[3180c14bb7e771afaf343bf2e3b8e1e3.png]: /images/20221022/6624b46486934f4e91315124374760e8.png
[2b4cd39c3a444b30de20381bf62d42b0.png]: /images/20221022/2480e855cd6f48d4a8497788bf5ed666.png
[911d6ee5c180067629e5979ccf466486.png]: /images/20221022/37fece82b932424790dc4128827ce987.png
[78a3e1791babca9cb694658cc1dbff17.png]: /images/20221022/184ed15d31bc4b9ab5090d143d917b34.png
[a4313803c8ecff929d0623af6dce6917.png]: /images/20221022/ddacadc7a21d4abd97bee5ab8c3c0d85.png
[3e86588fb059404b007e90776f836d98.png]: /images/20221022/20f2f31776054e7b8fcb2734ab05f6e0.png
[85bb4ebf397bb9a5255ae42774ee7355.png]: /images/20221022/d6c974b9b4f940e5b6e873d7b68157e1.png