首先我们来了解一下 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。
192.168.1.100 (电信)192.168.1.101 (电信)
192.168.1.102 (电信)
10.10.10.100 (网通)
10.10.10.101 (网通)
并且5台服务器都在为www提供服务。
本例子再假设域名为qicaispace.com
为电信用户实现负载均衡
根据前面的资料，电信一共有3台www服务器，分别是
192.168.1.100
192.168.1.101
192.168.1.102
首先登陆DNSPod的後台，添加一个qicaispace.com的域名。
然後在 管理域名记录 中添加一条记录
主机记录 www记录类型 A线路类型 电信
记录值 192.168.1.100点击增加接着，再分别添加两条记录
主机记录 www记录类型 A线路类型 电信
记录值 192.168.1.101
主机记录 www记录类型 A线路类型 电信
记录值 192.168.1.102
为网通用户实现负载均衡
电信用户的记录添加完毕後，接着添加网通的。
网通的添加方法跟电信的没太大分别
主机记录 www记录类型 A线路类型 网通
记录值 10.10.10.100
主机记录 www记录类型 A线路类型 网通至此，所有记录添加完毕
在软件系统的架构设计中，对集群的负载均衡设计是作为高性能系统优化环节中必不可少的方案。负载均衡本质上是用于将用户流量进行均衡减压的，因此在互联网的大流量项目中，其重要性不言而喻。
早期的互联网应用，由于用户流量比较小，业务逻辑也比较简单，往往一个单服务器就能满足负载需求。随着现在互联网的流量越来越大，稍微好一点的系统，访问量就非常大了，并且系统功能也越来越复杂，那么单台服务器就算将性能优化得再好，也不能支撑这么大用户量的访问压力了，这个时候就需要使用多台机器，设计高性能的集群来应对。
那么，多台服务器是如何去均衡流量、如何组成高性能的集群的呢？
此时就需要请出 「负载均衡器」 入场了。
负载均衡（Load Balancer）是指把用户访问的流量，通过「负载均衡器」，根据某种转发的策略，均匀的分发到后端多台服务器上，后端的服务器可以独立的响应和处理请求，从而实现分散负载的效果。负载均衡技术提高了系统的服务能力，增强了应用的可用性。
目前市面上最常见的负载均衡技术方案主要有三种：
基于DNS负载均衡
基于硬件负载均衡
基于软件负载均衡
三种方案各有优劣，DNS负载均衡可以实现在地域上的流量均衡，硬件负载均衡主要用于大型服务器集群中的负载需求，而软件负载均衡大多是基于机器层面的流量均衡。在实际场景中，这三种是可以组合在一起使用。下面来详细讲讲：
基于DNS负载均衡
基于DNS来做负载均衡其实是一种最简单的实现方案，通过在DNS服务器上做一个简单配置即可。
其原理就是当用户访问域名的时候，会先向DNS服务器去解析域名对应的IP地址，这个时候我们可以让DNS服务器根据不同地理位置的用户返回不同的IP。比如南方的用户就返回我们在广州业务服务器的IP，北方的用户来访问的话，我就返回北京业务服务器所在的IP。
在这个模式下，用户就相当于实现了按照「就近原则」将请求分流了，既减轻了单个集群的负载压力，也提升了用户的访问速度。
使用DNS做负载均衡的方案，天然的优势就是配置简单，实现成本非常低，无需额外的开发和维护工作。
但是也有一个明显的缺点是：当配置修改后，生效不及时。这个是由于DNS的特性导致的，DNS一般会有多级缓存，所以当我们修改了DNS配置之后，由于缓存的原因，会导致IP变更不及时，从而影响负载均衡的效果。
另外，使用DNS做负载均衡的话，大多是基于地域或者干脆直接做IP轮询，没有更高级的路由策略，所以这也是DNS方案的局限所在。
基于硬件负载均衡
硬件的负载均衡那就比较牛逼了，比如大名鼎鼎的 F5 Network Big-IP，也就是我们常说的 F5，它是一个网络设备，你可以简单的理解成类似于网络交换机的东西，完全通过硬件来抗压力，性能是非常的好，每秒能处理的请求数达到百万级，即 几百万/秒 的负载，当然价格也就非常非常贵了，十几万到上百万人民币都有。
因为这类设备一般用在大型互联网公司的流量入口最前端，以及政府、国企等不缺钱企业会去使用。一般的中小公司是不舍得用的。
采用 F5 这类硬件做负载均衡的话，主要就是省心省事，买一台就搞定，性能强大，一般的业务不在话下。而且在负载均衡的算法方面还支持很多灵活的策略，同时还具有一些防火墙等安全功能。但是缺点也很明显，一个字：贵。
基于软件负载均衡
软件负载均衡是指使用软件的方式来分发和均衡流量。软件负载均衡，分为7层协议 和 4层协议。
网络协议有七层，基于第四层传输层来做流量分发的方案称为4层负载均衡，例如 LVS，而基于第七层应用层来做流量分发的称为7层负载均衡，例如 Nginx。这两种在性能和灵活性上是有些区别的。
基于4层的负载均衡性能要高一些，一般能达到 几十万/秒 的处理量，而基于7层的负载均衡处理量一般只在 几万/秒 。
基于软件的负载均衡的特点也很明显，便宜。在正常的服务器上部署即可，无需额外采购，就是投入一点技术去优化优化即可，因此这种方式是互联网公司中用得最多的一种方式。
上面讲完了常见的负载均衡技术方案，那么接下来咱们看一下，在实际方案应用中，一般可以使用哪些均衡算法？
轮询策略
负载度策略
响应策略
哈希策略
下面来分别介绍一下这几种均衡算法/策略的特点：
NO.1—— Random 随机
这是最简单的一种，使用随机数来决定转发到哪台机器上。
优点：简单使用，不需要额外的配置和算法。
缺点：随机数的特点是在数据量大到一定量时才能保证均衡，所以如果请求量有限的话，可能会达不到均衡负载的要求。
NO.2—— Round Robin 轮询
这个也很简单，请求到达后，依次转发，不偏不向。每个服务器的请求数量很平均。
缺点：当集群中服务器硬件配置不同、性能差别大时，无法区别对待。引出下面的算法。
NO.3—— Weighted Round Robin 加权轮询
这种算法的出现就是为了解决简单轮询策略中的不足。在实际项目中，经常会遇到这样的情况。
比如有5台机器，两台新买入的性能等各方面都特别好，剩下三台老古董。这时候我们设置一个权重，让新机器接收更多的请求。物尽其用、能者多劳嘛！
这种情况下，“均衡“就比较相对了，也没必要做到百分百的平均。
NO.4—— Least Connections 最少连接
这是最符合负载均衡算法的一个。需要记录每个应用服务器正在处理的连接数，然后将新来的请求转发到最少的那台上。
NO.5—— Source Hashing 源地址散列
根据请求的来源ip进行hash计算，然后对应到一个服务器上。之后所有来自这个ip的请求都由同一台服务器处理。
https://www.cnblogs.com/saixing/p/6730201.html
https://blog.51cto.com/13732225/2175804
欢迎分享，转载请注明来源：夏雨云
微信扫一扫
支付宝扫一扫
评论列表（0条）