全局负载均衡GSLB

全局负载均衡GSLB

业务走向全球，一个核心问题浮现：如何让所有用户，无论身在何处，都能秒速访问？

传统负载均衡（SLB）显然力不从心，你需要的是GSLB（全局负载均衡）。

GSLB的机制

GSLB的使命是在全球多个数据中心间，为用户找到最佳访问路径。

它手里有一张世界地图，上面标着系统所有的数据中心。无论用户来自哪里，它都能规划出最优路线，它看到的，是整个服务网络的全局拓扑。

流量调度策略

GSLB的作用是进行全局流量调度，决策依据包括以下几个方面：

• 地理位置：就近原则，最简单粗暴的。你在北京，就给你连北京的机房，这是最直接的降延迟手段。
• 响应时间：GSLB会实时ping一下所有数据中心，看哪个应答最快，就让你走哪条路。
• 节点负载：避免将流量导向已经高负荷的数据中心，把请求导向相对空闲的节点，保证服务质量。

主要实现方式

GSLB的实现路径不止一条，主流方案各有千秋。

基于DNS

这是最经典、也是最广泛的玩法。把GSLB设备伪装成一个权威DNS服务器。当用户浏览器来问xx.com的IP地址时，GSLB就接管了。它偷瞄一眼用户的来源IP，心想，哦，一个上海来的朋友，然后就从它管理的IP池里，挑一个上海机房的IP地址返回给用户，后续用户直连该IP。

基于HTTP重定向

搞个中转站。所有用户第一次请求，都先打到一个统一的接入点。这个接入点像个前台，看了你的访客证（来源IP），然后通过HTTP 302重定向，告诉你请去3号楼B座（最合适的数据中心）。缺点是多绕了一步，第一次访问慢了那么一丢丢，但好处是调度可以更灵活。

基于IP路由

让全球多个数据中心都对外宣告我就是1.2.3.4这个IP。当用户访问这个IP时，互联网上的路由器会通过BGP协议，自动把数据包送到离用户最近的那个1.2.3.4。响应速度快到极致，但普通玩家烧不起这个钱，实现和运维都极其复杂。

基于应用层

直接在你的客户端SDK或者网关里写死调度逻辑。应用自己就能判断连哪个后端节点最快。这种方式控制粒度最细，想怎么玩就怎么玩，在微服务架构里很常见。

健康检查与故障转移

如果GSLB把用户的流量引向一个已经宕机的数据中心，那将是一场灾难。因此，持续的健康检查是GSLB的生命线。

GSLB会像哨兵一样，不知疲倦地对所有数据中心的服务端口进行探测。一旦发现异常，会立刻将其从可用地址池中移除，将流量自动切换到健康节点，整个过程对用户透明。

GSLB的实践与展望

现实挑战

GSLB 最典型的问题是 Local DNS缓存。如果GSLB因故障切换了IP，但中间DNS节点仍在提供旧的缓存IP，用户访问就会失败。为此，GSLB通常会设置一个较短的TTL（Time-To-Live）值来缓解。

GSLB vs CDN

很多人会混淆GSLB和CDN。简单区分：

• CDN：核心是内容缓存，将静态资源（图片、视频）放在离用户最近的地方。
• GSLB：核心是流量导向，处理动态业务请求的路由。

两者协同工作，GSLB导向最佳数据中心，CDN加速该中心返回的静态内容。