大家好，又见面了，我是你们的朋友全栈君。
摘要
GSLB 是 Global Server Load Balance 的缩写，即全局负载均衡。本文首先介绍了什么是负载均衡 SLB ，以及为什么要使用 SLB 。接着引出全局负载均衡 GSLB 的概念和作用。为此介绍了其基于 DNS进行解析和分配负载的实现，包括 DNS 的原理简介、应用部署中的基本概念、分配负载的决策条件等内容。以外，本文还简单介绍了通过 HTTP 和 IP 实现 GSLB 的方式，并对三者的优缺点进行了简单对比。最后是本文的参考文献。
关键词: GSLB , DNS, CDN
1. 负载均衡 SLB
1.1 负载均衡及其作用
负载均衡(Server Load Balance, SLB)，其含义是将负载(工作任务)平衡分散到多个服务器上。CDN是典型的负载均衡集群系统。
图1.1是负载均衡的示意图。从图中可以看出，负载均衡设备可以在用户请求到达服务器之前将其截获，然后将其分发到合适的后端服务器。
图1.1 SLB示意图
也就是说，客户端发出的请求，首先会到负载均衡设备的IP地址上。因为该IP地址并不负责处理实际的业务，所以通常将该地址称为【虚拟IP】(Virtual IP, VIP)。
后端真正的业务服务器被称为【真实服务器】(Real Server, RS)，其IP地址被称为【真实IP】(Real IP, RIP)，负责处理业务。
举个例子，VIP 就像是前台招待，会告诉你办什么事该去哪个房间。而RIP是内部实际办业务的房间号。
利用负载均衡，很大程度上可以避免单个服务器过载或者闲置，前者会引起服务能力下降，后者则没有充分利用资源。因此，为了达到更好的系统处理能力，需要进行以下两个步骤：
- 在集群前端部署负载均衡设备
- 根据预先配置的均衡策略，在集群中智能分发用户请求
1.2 负载均衡关键技术
要做到负载均衡，需要的问题包括但不限于以下几个方面
- 请求的分发
- 会话保持
- 服务健康监测
- 故障隔离
- 自动恢复
1.2.1 请求分发算法
请求分发算法，可以分为【静态算法】和【动态算法】两大类。
- 静态算法 静态算法是指按照预先设置好的策略进行分发，而不考虑服务器当前的实际负载状况。 这类算法包括轮询、加权轮询、基于源IP或目的IP的hash算法等等，优点是简单快捷。
- 动态算法 动态算法指的是能够根据当前服务器状况进行分发，包括最小连接，加权最小连接等。
1.2.2 会话保持
出于一些业务的特殊要求，有时候需要进行会话保持，以保证一段时间内，某一个用户与系统的交互（会话），只交给同一台服务器处理。
例如，大多数电商应用需要用户认证，而一次交易需要与服务器多次交互才能完成。这几次交互必须由同一台服务器处理，而不能被分散到不同服务器上。
会话保持有以下几种方法：
- 源IP地址的持续性保持
- cookie 持续性保持
- 基于HTTP报文头的持续性保持
1.2.3 服务器健康检测
为了保证服务质量，需要定时进行健康检测。我们可以利用ICMP、TCP、HTTP、FTP等协议进行检测，即主要是在传输层和应用层进行检测。
应用层的检测颗粒更细，但对系统的要求也比较高，因为需要针对应用层的不同的协议做不同的识别分发机制。应用层检测用的比较多的就是HTTP协议，比如先和集群中的设备建立连接，然后发出请求，如果收到正确应答，则说明HTTP处理正常。
传输层的检测，主要在于能否建立TCP连接，回响是否正常，等等。
2. 全局负载均衡GSLB
2.1 GSLB的简介与作用
GSLB, Global Server Load Balance, 即全局负载均衡。
由于现实中存在各种不稳定因素，比如某个服务器集群所在的数据中心断电，洪水或者地震造成数据中心瘫痪等等。在一个数据中心内，无论采用怎样的技术，总可能存在一些不可抗因素，导致其瘫痪。所以通常会把服务器分散部署到多个数据中心，以最大程度减小灾害对服务质量产生影响的概率和程度。
另外，CDN系统总是希望用距离用户最近的设备为其提供服务，这也需要在不同地域部署多个节点。
GSLB系统就是针对这个问题的。它负责多个CDN节点之间相互协作，将各节点和设备的负载保持在一个有利于提供优质服务的水平。GSLB的负载均衡结果可能直接将用户分配到RS，也可能将用户交付到下一层次的负载均衡系统。
经过多年发展，已有多种调度机制可实现CDN的全局负载均衡。其中最常用的是基于DNS的GSLB。
2.2 DNS简介
2.2.1 DNS工作流程
DNS是一个应用层协议，但它通常被其他的应用层协议使用，以便将主机名(host)解析为IP地址。DNS的工作流程如图2.1
图2.1 DNS的基本工作流程
在第4步中,本地DNS服务器(Local DNS, LDNS)在得到浏览器解析的域名请求后，会采用迭代或递归查询的方式，向DNS 系统中其他远程域名服务器提出查询请求，如图 2.2 所示。
图2.2 域名解析
如果LDNS中没有关于这个域名的缓存，则首先会去根域名服务器请求解析.root，收到其返回的.com域的域名服务器列表。LDNS在该列表中选出一个域名服务器，对其发出域名解析请求。
被请求的.com域的域名会查找CDNbook.com的权威域名服务器的IP，并将其返回给LDNS。
由于这个权威域名服务器是CDNbook.com这个域名授权的，所以LDNS对权威域名服务器请求后就能得到www.CDNbook.com的IP地址，并将其返回给客户端。
另一方面，如果在LDNS上有<www.CDNbook.com—IP>的缓存记录，就可以直接把这个结果返回给客户 端，节省了中间的递归查找步骤时间和资源开销。
2.2.2 DNS记录的类型
DNS服务器是根据资源记录来对DNS请求进行应答的。其中，最常见的是Internet类的记录(Class IN)。Internet类的记录主要有以下几种类型(Type):
-
A记录A记录即地址Address记录，对应的value是域名的IP地址。 -
NS记录 域名服务器Name Server记录，保存了下一级域名信息的服务器地址。该记录只能设置为域名,不能设置为IP地址。 -
CNAME记录 规范名称记录Canonical Name for an alias，也称为别名记录，其value是另一个域名。也就是说，将原域名key映射到了另一个域名value。 举个栗子。百度的域名是www.baidu.com，它的cname是www.a.shifen.com。 那么，我们已经有了一个域名了，为什么还要设置cname呢？假设有www.domain.com和mail.domain.com，其cname都指向host.domain.cdnxxx.com。 然后某一天，我们的服务器地址(A记录对应的IP地址)可能要变了。由于www和mail都会被引导到www.domain.wscdn.com，所以这时我们只需修改host.domain.wscdn.com的A记录，而不必把www和mail的A记录都改一遍。 因此cname增加了灵活性，在子域多的时候更为明显，相当于进行了批量管理。 -
RR记录 资源记录Resource Record。一个主机名可以对应多个IP地址，在一个DNS应答报文中可能含有多条RR信息。
下面我们使用nslookup来对上述的几个定义进行具体说明。
$ nslookup www.baidu.com
# 返回如下响应
Non-authoritative answer:
www.baidu.com canonical name = www.a.shifen.com.
Name: www.a.shifen.com
Address: 112.80.248.74
Name: www.a.shifen.com
Address: 112.80.248.73首先，www.baidu.com没有A记录，但是通过cname被引导到了www.a.shifen.com.。
其次，www.a.shifen.com有2条A记录，也就是一个主机对应了2个IP。实际上，如过在不同地区进行DNS请求，则最后得到的这2条A记录也不同。采用某国外VPS进行请求的结果是14.215.177.38和14.215.177.37。这么做是为了将不同地区的用户分配其最近的服务节点，以便快速访问。后面的内容将会解释这一点。
发布者：全栈程序员栈长，转载请注明出处：https://javaforall.cn/130967.html原文链接：https://javaforall.cn
