DNS全局负载均衡（GSLB）基本原理[通俗易懂]

大家好，又见面了，我是你们的朋友全栈君。

原理

采用全局负载均衡（GSLB）的前提是在不同地区设立了多个数据中心，并不是所有的互联网服务都能做GSLB，前提是业务已经做了分布式部署的规划，无论用户从哪个IDC访问都能得到相同的结果，或者用户基本不会出现跨区域流动访问的情况，只会访问就近IDC，或者有一套入口调度机制，能将用户调度到所属的节点。

现在很多CDN也都提供动态内容的加速，只不过这个加速只是数据传输上的优化，可以看做给你做了很多个转发节点，最终业务处理压力还是源站承担。如果不具备分布式部署改造的条件，只是要解决远距离客户访问慢问题，可以考虑CDN。

目前很多DNS服务商都提供了智能DNS服务，智能DNS可以通过多种负载均衡策略来将客户端需要访问的域名解析到不同的数据中心不同的线路上，比如通过各运营商分省IP地理信息数据来判断用户的就进性，并结合健康检查策略（通常是发一个固定的http请求）来分配访问量。

第三方智能DNS的不足在于通过公网健康检查可能会受到运营商网络拥塞的影响，目前国内域名服务商提供的服务目前还无法感知线路繁忙程度和后端服务器真实负载情况。除了使用智能DNS解析软件或者云服务，多数对可靠性和性能要求高的用户都会使用硬件的全局负载均衡解决方案。全局负载均衡设备以通过更丰富的维度来判断用户就进性，形成就进性表，除了分地域IP数据库外，还可以通过TTL、用户访问延时、服务器负载情况等来判断。

下例的全局负载均衡解决方案中，域名服务商处将域名的NS记录指向有智能DNS解析功能的GSLB设备，然后由GSLB设备来进行A记录解析。如果在多地部署了GSLB设备，它们都应该添加到NS记录中以保证高可用性，域名服务商处轮询地返回GSLB地址或者一次性返回全部地址。GSLB设备会对自己所在的IDC后端服务器以及其他IDC公网IP进行健康检查，健康检查结果会通过自有协议在不同IDC的GSLB设备之间同步，最终根据全局负载均衡策略来选择最优的地址解析给用户。

解析的步骤示意如下图：

DNS全局负载均衡（GSLB）基本原理[通俗易懂]

用户向本级配置的本地DNS服务器发出查询请求，如果本地DNS服务器有该域名的缓存记录，则返回给用户，否则进行第2步；
本地DNS服务器进行递归查询，最终会查询到域名注册商处的授权DNS服务器，这里可能有多个步骤，图中只反映最后一步；
授权DNS服务器返回一条NS记录给本地DNS服务器。根据授权DNS服务器上的不同设置，这条NS记录可能是指向随机一个GSLB设备的接口地址或者是所有GSLB设备的接口地址；
本地DNS服务器向其中一个GSLB地址发出域名查询请求，如果请求超时会向其它地址发出查询；
GSLB设备选出最优解析结果，返回一条A记录给本地DNS服务器。根据全局负载均衡策略设定的不同可能返回一个或多个VIP地址；
本地服务器将查询结果通过一条A记录返回给用户，并将缓存这条记录。

通过DNS解析报文中的TTL（Time To Live）字段可以控制客户端缓存这条记录的时间，在缓存时间内客户端会使用旧的查询结果，当缓存时间超时后才可能重新发出查询，TTL值过大会导致故障发生时切换时间过长，TTL值太小会造成查询频繁，对设备和网络的压力增大。

局限性

请注意GSLB设备收到的DNS请求的源地址不是用户的地址而是用户所配置的本地DNS服务器地址，而GSLB的就进性探测是根据这个地址来判断的，在我国大多数ADSL拨号上网用户都能就近分配正确的数据中心，但是当用户用户通过4G移动网络上网的情况下，客户会一直使用归属地的DNS服务器，或这手动设定本地DNS而设置的DNS距离用户较远的情况，GSLB不能分配最佳的地址。这种情况很常见，国内有很多人使用google的公有dns或者opendns。

这种情况可以使用重定向来解决，SLB设备正式收到用户发来的请求时，会再次查找就进性表，当发现用户的最佳访问节点非自己时，通过http 302重定向来再次引导用户流量。

原文地址：http://www.cnblogs.com/foxgab/p/6900101.html

发布者：全栈程序员-站长，转载请注明出处：https://javaforall.net/137414.html原文链接：https://javaforall.net