负载均衡-DNS

发表于   |   分类于   |     |   阅读次数

前言

上一篇讲到HTTP重定向.这里我们将两一种类似的方式

什么是DNS?

DNS:域名解析服务器
为什么需要DNS? 我们访问一个网站, 比如www.baidu.com.其实最后访问到的是一台远程服务器, 服务器返回一个页面给我们.如果我们直接使用IP的形式访问呢?

其实一样的结果,那为什么还要有域名呢? 结果就是方便记忆.如果让我们上网的时候记住所有的IP那估计是意见多么痛苦的事情
但是一台服务器就是一个IP, 机器之前都是通过IP进行识别,如果使用域名必然要有一个东西来进行翻译了,哪个域名对应哪个IP
我们在安装宽带的时候, 比如电信的宽带, 都会告诉我们DNS服务器

加深了解


我们在自己的CMD中输入如下命令, 查看百度的DNS服务器, 发现5个DNS服务器

CDN

CDN是什么?内容分发网络,其基本思路是尽可能避开互联网上有可能影响数据传输速度和稳定性的瓶颈和环节，使内容传输的更快、更稳定.

我们可以看到这个图,一个用户的请求都是指向的某一个CDN, 所有的用户请求都是分散的, 被分流到各个节点
同样的道理, 我们可以应用到传统的B/S架构中,将用户的请求分流到不同的服务器,这里就用到DNS

DNS怎么工作?

简单的理解就是我们根据域名像DNS服务器询问域名对应的IP地址,然而却没有这么简单,DNS是一个典型的树状结构,我们设置的dns(IP)就是一个DNS缓存服务器,是为了减轻DNS查询的负载设计出来的,如果你的请求没有命中缓存,那么这个缓存服务器就会进行一次标准查询,然后再把结果缓存下来,简单的来说就是从根服务器一级级的问

根域名

目前，全球有13台根域名服务器，其中1台为主根，在美国；12台为辅根，其中9台在美国，2台在欧洲，1台在日本。这些根域名服务器之间是冗余的关系，主要防止其中每台出现问题，另外，可以让其他服务器就近选择。每一个域名都要经过根域名服务器，才能获得顶级索引。现在，全球有200多个根域名服务器的镜像服务器。
由于根域名服务器都是固定的，本地域名服务器要知道根服务器在哪里，只要在本地的配置文件当中记录那些根服务器的IP地址，而不是域名，需要的时候直接使用就可以了

模拟DNS工作

上面讲到根服务器拥有一切域名的起始解释权，但是如果你去问根服务器它是不会直接告诉你最终答案的。因为如果它要存储所有的记录，那它也太累了，这个负载和开销是惊人的。那它会告诉你什么呢？它会告诉你应该去问谁，也就是它授权下一级服务器来解答你的问题。拟人化这个过程

  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，走你

A记录

在DNS系统中有一个比较重 要的的资源类型叫做主机记录也称为A记录，A记录是用于名称解析的重要记录，它将特定的主机名映射到对应主机的IP地址上。如果你有一个自己的域名，那么 要想别人能访问到你的网站，你需要到特定的DNS解析服务商的服务器上填写A记录，过一段时间后，别人就能通过你的域名访问你的网站了

CNAME

（别名记录）：将多个名字映射到同一计算机

DNS负载均衡


看图我们知道,DNS服务器中记录了很多的A记录:

1
2
3
www.apusapp.com IN A 114.100.20.201;
www.apusapp.com IN A 114.100.20.202;
www.apusapp.com IN A 114.100.20.203;

我们在DNS上设置一些规则,比如按照用户请求的地址然后返回离用户最近的一台服务器,这就是简单的负载均衡了

亲身检测

我们可以使用dig命令来最终一个网站的域名解析全过程
这里测试百度www.baidu.com

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
thunder@ubuntu:~$ dig www.baidu.com +trace

; <<>> DiG 9.9.5-3-Ubuntu <<>> www.baidu.com +trace
;; global options: +cmd
.            91852    IN    NS    j.root-servers.net.
.            91852    IN    NS    k.root-servers.net.
.            91852    IN    NS    a.root-servers.net.
.            91852    IN    NS    l.root-servers.net.
.            91852    IN    NS    f.root-servers.net.
.            91852    IN    NS    i.root-servers.net.
.            91852    IN    NS    c.root-servers.net.
.            91852    IN    NS    d.root-servers.net.
.            91852    IN    NS    g.root-servers.net.
.            91852    IN    NS    b.root-servers.net.
.            91852    IN    NS    m.root-servers.net.
.            91852    IN    NS    e.root-servers.net.
.            91852    IN    NS    h.root-servers.net.
;; Received 239 bytes from 114.114.114.114#53(114.114.114.114) in 159 ms

com.            172800    IN    NS    d.gtld-servers.net.
com.            172800    IN    NS    k.gtld-servers.net.
com.            172800    IN    NS    e.gtld-servers.net.
com.            172800    IN    NS    c.gtld-servers.net.
com.            172800    IN    NS    a.gtld-servers.net.
com.            172800    IN    NS    j.gtld-servers.net.
com.            172800    IN    NS    h.gtld-servers.net.
com.            172800    IN    NS    m.gtld-servers.net.
com.            172800    IN    NS    l.gtld-servers.net.
com.            172800    IN    NS    f.gtld-servers.net.
com.            172800    IN    NS    b.gtld-servers.net.
com.            172800    IN    NS    i.gtld-servers.net.
com.            172800    IN    NS    g.gtld-servers.net.
com.            86400    IN    DS    30909 8 2 E2D3C916F6DEEAC73294E8268FB5885044A833FC5459588F4A9184CF C41A5766
com.            86400    IN    RRSIG    DS 8 1 86400 20160401160000 20160322150000 54549 . LqboDk04GTjylUk0qL+pfJ22XZIN8iAhRCArexGMixFpNrkURbJExgP2 DfoulGThk1dWNxSza8HobxPVKrmIRS7zx8e31f9Xls7UDUoCKNbqDxRM ZVnDCL31QZMbrOaYyG6WfIa0mj0NVmh44T8yk/1UrYe1Eu7QvfYkeh8+ xuM=
;; Received 737 bytes from 192.228.79.201#53(b.root-servers.net) in 410 ms

baidu.com.        172800    IN    NS    dns.baidu.com.
baidu.com.        172800    IN    NS    ns2.baidu.com.
baidu.com.        172800    IN    NS    ns3.baidu.com.
baidu.com.        172800    IN    NS    ns4.baidu.com.
baidu.com.        172800    IN    NS    ns7.baidu.com.
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN NSEC3 1 1 0 - CK0Q1GIN43N1ARRC9OSM6QPQR81H5M9A NS SOA RRSIG DNSKEY NSEC3PARAM
CK0POJMG874LJREF7EFN8430QVIT8BSM.com. 86400 IN RRSIG NSEC3 8 2 86400 20160327050458 20160320035458 28259 com. ixxm2HR06La9ikLnbD5ct+NwRzxFhc4aAqWLuc1qCZeTef1Ljsb8HK0d Ghi1vQQX2vQiWrvMpb7FWJf9Zhk7wj/po/2nIVTqvflw0e2xmHqRgiKe fgyahipdxdOje63wtqvQU5Qlq0foe/nP6x3rhmPFaQgWQjqs9U0QAxyW SQM=
HPVV2B5N85O7HJJRB7690IB5UVF9O9UA.com. 86400 IN NSEC3 1 1 0 - HQ01H2D8Q0MT897NAE62MCFNM16HPMG6 NS DS RRSIG
HPVV2B5N85O7HJJRB7690IB5UVF9O9UA.com. 86400 IN RRSIG NSEC3 8 2 86400 20160329045104 20160322034104 28259 com. rLbM39bTv0fhSf4l1jUJb/mZD4urpTto0k77nZjLEeGRdZv1wADSvGk7 WfVsYdk04Zhfb9jHEayv5Rkaid9SJ23vM3/biAIihwWyIHNlfKY+uGGO BVidAuXErRCVKPF7ZbzMc7S8YgKlT3HP4DmEIoIMvdHaYNf3Fu1E4GMO 6B4=
;; Received 697 bytes from 192.43.172.30#53(i.gtld-servers.net) in 282 ms

www.baidu.com.        1200    IN    CNAME    www.a.shifen.com.
a.shifen.com.        1200    IN    NS    ns4.a.shifen.com.
a.shifen.com.        1200    IN    NS    ns5.a.shifen.com.
a.shifen.com.        1200    IN    NS    ns3.a.shifen.com.
a.shifen.com.        1200    IN    NS    ns2.a.shifen.com.
a.shifen.com.        1200    IN    NS    ns1.a.shifen.com.
;; Received 239 bytes from 119.75.219.82#53(ns7.baidu.com) in 35 ms

dig +trace会总顶级域名开始追踪

  1. .这个顶级域名开始:一共有13个顶级域名
  2. com.
  3. baidu.com.
  4. www.baidu.com.最后查找到www.a.shifen.com
    (这里百度在外层包裹了一个www.a.shifen.com, 如果想知道真实的IP可以继续使用dig www.a.shifen.com +trace进行追踪)

优点

  1. 将负载均衡的工作交给DNS，省去了网站管理维护负载均衡服务器的麻烦。
  2. 技术实现比较灵活、方便，简单易行，成本低，使用于大多数TCP/IP应用。
  3. 对于部署在服务器上的应用来说不需要进行任何的代码修改即可实现不同机器上的应用访问。
  4. 服务器可以位于互联网的任意位置。
  5. 同时许多DNS还支持基于地理位置的域名解析，即会将域名解析成距离用户地理最近的一个服务器地址，这样就可以加速用户访问，改善性能。

缺点

  1. 目前的DNS是多级解析的，每一级DNS都可能缓存A记录，当某台服务器下线之后，即使修改了A记录，要使其生效也需要较长的时间，这段时间，DNS任然会将域名解析到已下线的服务器上，最终导致用户访问失败。
  2. 不能够按服务器的处理能力来分配负载。DNS负载均衡采用的是简单的轮询算法，不能区分服务器之间的差异，不能反映服务器当前运行状态，所以其的负载均衡效果并不是太好。
  3. 可能会造成额外的网络问题。为了使本DNS服务器和其他DNS服务器及时交互，保证DNS数据及时更新，使地址能随机分配，一般都要将DNS的刷新时间设置的较小，但太小将会使DNS流量大增造成额外的网络问题。

总结

事实上，大型网站总是部分使用DNS域名解析，利用域名解析作为第一级负载均衡手段，即域名解析得到的一组服务器并不是实际提供服务的物理服务器，而是同样提供负载均衡服务器的内部服务器，这组内部负载均衡服务器再进行负载均衡，请请求发到真实的服务器上，最终完成请求。

参考

利用dns解析来实现网站的负载均衡
每天进步一点点——负载均衡之DNS域名解析