从底层技术来看，GSLB 究竟难在哪儿

原文转载自：高效运维社区 作者：吕宏利

作者简介

吕宏利，来自硅谷的SRE，多年的国内外大型互联网公司运维开发经验，专注于分布式系统设计、监控、容量规划，数据中心技术以及生产环境的最佳实践。

GSLB是什么

GSLB 一种常见的解释是 Global Server Load Balancing 的缩写，也有说法是 Global Software Load Balancing 或者 Global Site Load Balancing，翻译过来就是：全局服务/软件/站点负载均衡。

根据维基百科：负载均衡可以促进工作负载在多个计算资源之间的分配，比如：计算机之间、计算集群直接、网络链路、CPUs 或者磁盘。目的是优化资源使用率，最大化吞吐量，最小化响应时间，并且避免任何单一资源的过载。维基百科的定义偏重于负载分配以优化资源使用率，大型互联网公司应用 GSLB 还有另外2个很重要的目标：

Why it’s hard

首先定义一下“hard”:这里并不是指很难实现/搭建一套 GSLB 系统，而是指实现/搭建一套可以达到开篇提到的三个目标的 GSLB 系统很难。为什么说很难呢，我尝试从三个大的方面去解释：

由于篇幅较长，整篇文章会分为三个部分，本文是第一部分，从使用的底层技术入手解释为什么很难。

从底层技术上

这里我们主要讨论基于 DNS 的 GSLB，因为 DNS 是最古老也是应用最广泛的全局负载均衡方式，支持所有上层协议的全局负载。几乎所有的 GSLB 实现都离不开 DNS，不夸张的说很多简单的 GSLB 就是通过 DNS 实现的。复杂一些的 GSLB 还会增加其他组件，但是 DNS 会作为第一层的负载均衡。如果只谈论 HTTP 协议的全局负载均衡，还有基于 HTTP 重定向的 GSLB 系统，但是该方案的局限性也很大，这里不做过多讨论。下面这张图是一个最简单的 GSLB 架构图

我们以用户访问 www.example.com 为例来解释上图，图中有两个很重要的信息流:

基于DNS负载均衡的问题

图一是张很简单的 GSLB 架构图，图中 NYC 和 LON 用户各自访问距离最近的服务，这是理想状态，在现实中要维持这种状态是有很多问题需要解决的。

1. 如何返回最优IP

一般情况下，example.com 的 DNS 权威服务器可以根据源请求 IP 返回最近的example.com 集群 IP，对应到上图中就是 NYC 的用户得到的 example.com 集群 IP 实际是根据本地ISP DNS的IP返回的。这就涉及了一个问题，如果本地ISP没有 DNS 服务器而是使用其他上级 ISP 的 DNS 服务器，NYC 的客户端就有可能得到距离很远的集群IP（假如本地ISP使用了多伦多的ISP进行DNS递归查询）；或者用户自己设置了其他公共 DNS 服务器，都会导致返回的IP地址不是最优的。

当然了，现在我们有 edns-client-subnet，如果本地 ISP DNS 或其他公共 DNS支持，那么客户端就可以得到距离最近的集群 IP 来提供服务。可以通过以下链接查看支持 edns-client-subnet 的大型 DNS 服务提供者：http://www.afasterinternet.com/participants.htm。上面这个列表肯定是不全的，不是所有公司都会更新这个名单，不管这也传达了一个信息，edns-client-subnet 的普及速度很慢。

2. 如何准确分流

简单基于 DNS 的负载均衡方案，另外一个很大的弊端是流量分配不均。原因主要有下面2点：

由于服务提供者，比如 Google，很难控制用户自己的 DNS 设置以及广大 DNS 服务提供者对 edns-client-subnet 的支持，如何调整流量就必须从服务端进行了。

如图二所示，服务端balancer信息流新增了一个环节。global balancer根据每个集群的容量和已有请求进行集群间的流量迁移。这对 GSLB 系统提出2个新的要求：

这其实是在服务器端构建了一个反馈回路，local/global balancer 可以根据集群容量、负载进行流量调配，消除了由于 DNS 调度导致的热点集群问题。还可以通过集群健康数据的收集，在流量调度时过滤问题集群。另外一种可行的方案是，服务器端在收到用户请求时判断用户是否在访问最优的集群，如不是最优集群就重定向用户 到距离最近/最优的集群。

判断方法也比较简单，比如服务器端进行 RTT 的对比，如果 RTT 大于一定阈值就向自己的权威服务器提交客户 IP 查询更优结果，然后创建一个基于 FQDN 的重定向。就像当年 Akamai 做的那样：https://blogs.akamai.com/2013/03/intelligent-user-mapping-in-the-cloud.html。这种方法对某些业务形态比较有效，比如长时间的视频流或下载业务，初始的那个额外重定向和 DNS 查询时间占比很小，但是性能改进很大；如果是短暂的HTTP请求，效果就不明显了。

有吃瓜群众会问了：HttpDNS 可以解决这个问题吧？如果你的服务是通过可控客户端提供的，那么 HttpDNS 可以帮助你解决这个问题，因为你也修改客户端使用 HttpDNS。但是如果你的服务是通过浏览器提供的，那么 HttpDNS 是帮不上忙的，不过基于 HTTP 重定向的 GSLB 可以，但是该方案本身的实现难度和问题也不小，而且支持的业务形态比较单一，目前我没有见过哪个公司大规模部署这个方案，如果有谁知道可以探讨一下。

3. 如何快速切流

事故是一定会发生的，如何在事故发生时快速切走流量，将用户的影响降到最低是至关重要的。

然而，基于DNS的切流机制是不靠谱的。

即便是能在第一时间更新权威服务器，不再返回故障集群的 IP，由于以上原因，还是会有一段时间（从几分钟到几小时不等）请求仍然发送到故障集群，导致请求失败。如果故障集群的 local balancer 还可用，那么集群间的流量调度可以很快切走流量，这里主要讨论 local balancer 也不可用的情况。

要解决这个问题，最好的方案是通过 anycast，每个集群通过 BGP 对外通告同样的 VIP，互联网上的路由器会最终根据通告的 VIP 距离判断路由的优先级。所有用户对 www.example.com 的 DNS 请求都会返回同样的 VIP 地址，但是不同区域用户对VIP的请求会被路由到各自最近的集群。当某个集群出现故障时，该集群对外通告的 VIP 会被撤回，路由更新之后，之前该集群服务的用户请求会被自动路由到次优集群，这对用户来说都是透明的，但是如果提供的服务是有状态的，会导致状态丢失，比如 youtube 视频播放会中断。

如果不能部署 anycast 呢？来看看 Dyn 的 DNS 服务提供的 anycast 接入点你就明白了

Dyn Anycast

还有另外一种方法是通过 BGP 的 community 为集群的IP地址段设置主备路由，备份路由的目的地是另外一个集群。DNS 权威服务器根据用户所在区域和集群容量信息返回集群的 VIP，正常请下对该 VIP 的数据包会被路由到本集群，当该集群故障时，备份路由生效，从而流量会被路由到其他健康的集群,同样会对有状态服务造成影响。

上面两种方法都属于从网络层弥补应用层负载均衡的缺陷，可以规避DNS切流慢的问题。

延迟控制系统

当你的 GSLB 系统具备了内部集群间的流量调度功能时，形成了一个反馈闭环，整个 GSLB 系统就具备了控制系统的特征，而且还是具有延迟的控制系统。

上图去掉了互联网部分，只关注 GSLB 本身的主要构成，以4个集群为例。信息流动过程为：

然而整个过程不是瞬间完成的，如图中所示：本地服务每10秒钟上报一次负载，本地 balancer 每5秒钟上报一次，本地 balancer 可以在上报的 RPC 请求结果中拿到流量分配指示。由于 global balancer 不可能实时计算所有集群所有服务的流量分配情况，所以本地 balancer 拿到的分配指示和本次上报是没有任何关系的，流量分配指示是根据历史数据计算出来的，WTF？！

一个全球系统

你虽然可以通过调整上报时间间隔和 global balancer 的计算频率来缩小差距，但是考虑到这是一个全球性的系统，为了正确调度 global balancer 需要所有集群的数据，有几个问题是无法避免的：

基本上就是一个权衡各种因素，最终选择一个合适的这种配置，就将就着用旧点的数据做流量调整吧！

不能处理短暂的峰值

不能避免延迟，一个最大的问题就是：GSLB在面对短暂的流量峰值时是无能为力的。所以，一般的 GSLB 系统有一个假设：服务的流量在很短时间内不会出现剧烈变化。

以上图为例，如果 NYC 集群突然受到超过集群容量的请求（比如短暂的 DDoS），但是只持续了5秒钟的时间，这个峰值很可能都不会被 local balancer观测到。但是，如果你的服务由于过载导致进程重启，但是需要较长时间恢复，从而 NYC 集群容量减少，十几秒钟之后流量被分配到其他集群，如果期间还有多次的短暂峰值会将你的服务推向雪崩或者进入全球超负荷运行状态。上面的结论是基于一个前提条件：local balancer 并不在请求路径上。如果local balancer在请求路径上呢，那么先挂掉的可能是 local balancer，随之而来的是服务的全球超负荷运行。

你可能会说，难道没有 DDoS 防护措施吧，当然有了，但是 DDoS 的介入也是需要满足一定条件的，这种瞬时的流量峰值很难触发。我对 DDoS 防护手段研究不深，但是根据经验觉得可能不会触发，因为触发 DDoS 保护也需要历史和当前的流量信息，而这些信息很可能就是 GSLB 系统提供的，如果 GSLB 系统本身检测不到又怎么传递给 DDoS 系统呢。

小结

本节从 GSLB 最普遍的 DNS 负载均衡开始，介绍了基于 DNS 的 GSLB 系统面临和可以解决/改进的问题：

以及 GSLB 系统固有的难以解决的问题：