GSLB调度服务原理

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

1. 名词解释

• 权威 DNS 服务器 组织机构的 DNS 服务器对本组织机构内的一些服务器（如web服务器和邮件服务器）提供了”权威“的主机名到 ip 地址的映射。
• 边缘服务 集群内需要暴露给外网访问的服务

2. 概述

GSLB，全局负载均衡（Global Server Load Balancing ），主要的目的是在整个网络范围内将用户的请求定向到最近的节点（或者区域）。是对物理集群的负载均衡，不止是简单的流量均匀分配，还会根据应用场景的不同来制定不同的策略。本文将讨论 GSLB 的几种实现，并介绍调度服务实现的大体情况。

3. DNS 调度原理

3.1. DNS 简介

DNS 是一个分布式数据库，提供了主机名和 ip 地址之间相互转换的服务。这里的分布式数据库是指，每个站点只保留它自己的那部分数据。

域名具有层次结构，从上到下依次为：根域名、顶级域名、二级域名。

一个完整的DNS解析过程如下:

• 用户发出 www.sina.com.cn 的域名解析请求，首先查询本地缓存中是否有该域名对应的 ip，如果有直接返回，否则，进行第二步；
• 本地缓存服务器向根域名服务器发起 DNS 查询请求，根域名服务器会发送一个回复说，.cn 的域名我已经委派给 .cn 这台域名服务器了，给你这台服务器的地址，你去那里查吧。
• 本地缓存服务器收到这个答复后又向.cn 域名服务器查询，如此迭代，最后.sina.com.cn 的 DNS 服务器会收到这个请求，返回域名的实际ip给本地缓存服务器。
• 本地缓存服务器收到这个答复后，会将这条记录返回给客户端，同时将该记录写入自己的缓存中，以便备查。

4. DNS 调度

通过 DNS 调度的方式，对不同地域的请求返回不同的解析结果，将请求调度到离用户最近的服务器节点，从而减少延迟访问。

这种调度方式对原有的业务侵入性不大，实现起来简单方便，那么为什么没有使用这种方案？接下来说下这种方式的弊端。

4.1. 地理位置调度不准确

DNS 调度是根据本地 DNS 服务器来进行 ip 定位的。因此 DNS 调度有一个前提：假定用户使用的缓存 DNS 与用户本身在同个网络内，在该前提下，DNS 的解析才是准确的。通常情况下，用户使用 ISP 提供的本地缓存(简称 local DNS)，local DNS 一般与用户在同个网络内，这时候 DNS 调度是有效的。

但近些年，不少互联网厂商推广基于 BGP Anycast 的公共 DNS (Public DNS)，而这些 Anycaset ip 的节点一般是远少于各个 ISP 的节点，例如可能广州电信用户使用了某公共 DNS，但该公共 DNS 里用户最近的是上海电信节点，甚至更极端的如 Google DNS 8.8.8.8，在中国大陆没有节点(最近的是台湾)。而不幸的是国内有不少用户使用了 Google DNS，这其实降低了他们的网络访问体验。总的来说，使用公共 DNS，实际上破坏了上文的前提，导致 DNS 区域调度失效，用户以为得到了更快更安全的 DNS 解析，但实际得到了错误的解析，增加了网络访问延迟。 传统 DNS 协议的区域调度过程示例如下图，假定某业务以 foo.163.com 对外提供服务，在北京和东京各有一个节点，业务期望国内大陆的用户访问北京节点，而非大陆用户则访问东京节点。因为权威是根据 DNS 缓存来决定返回的结果，所以当用户使用不同的 DNS 缓存时，可能会解析到不同的结果。

如果 ip 定位不根据 local DNS 的 ip 来定位，取而代之用原始请求的 ip 来定位不就能解决这个问题了吗？

2011 年，Google 为首的几家公司在提出了一个 DNS 的扩展方案 edns-client-subnet (以下简称 ECS)，该扩展方案的核心思想是通过在 DNS 请求报文里加入原始请求的 ip(即 client 的 ip)，使得权威 DNS 服务器能根据该信息返回正确的结果。目前，该方案仍处于草案阶段。该方案很好地解决了上述提到的 remote DNS 导致解析不准确的问题。但是这种方案需要权威 DNS 服务器和 local DNS 的支持才能工作，推广难度大。

4.2. 域名变更生效时间不确定

local DNS 会缓存域名解析结果，域名变更到生效存在延迟。

5. http重定向

使用 http 重定向 将内容转发到不同位置。

• 请求的域名均解析为 GSLB 机器的 ip
• GSLB 根据源 ip 解析出目标服务的 ip，并使用 http 重定向技术将用户请求重定向到目标主机

这种方案的局限性如下：

• 这个方案只适用 http 请求，对于sip、dm等请求不适用
• 重定向有性能损失，2 次请求完成 1 次访问
• 获取到的信息有限（只有 ip），无法制定多种调度策略

6. 调度服务

调度服务是一个供外部（客户端、sip）获取边缘服务的一个服务。返回的服务 ip 列表遵循就近接入，负载均衡的原则。通过客户端 sdk 调度服务完成 GSLB 设备的功能。

• 客户端sdk通过域名向就近的调度服务发起请求获取需要的边缘服务
• 调度服务获取请求参数（例如：ip、服务名等），根据策略返回服务的 ip 列表
• 客户端获取到 ip 列表，挑选合适的 ip 发起请求。

这种方式让客户端有了负载均衡知识，服务端也获取到了任何想要知道的信息，从而可以做到更全面的解析策略。但是侵入性是最大的，因为客户端对 GSLB 是有感知的，且需要适配支持。

6.1. 调度服务策略

6.1.1. 区域亲和策略

• 根据客户端 ip 信息进行地理位置解析，解析出来country和area两级信息。这里的country为ISO 3166-1标准2位编码，area为ISO 3166-2标准2-3位编码
• 按照以下优先级规则筛选服务列表：
  • country area信息同边缘服务上报到发现服务中scheduler.support.geo meta信息相匹配的边缘服务列表
  • country信息同边缘服务上报到发现服务中scheduler.support.geo meta信息相匹配的边缘服务列表
  • 和country area对应的region在同一个数据中心（发现服务中的dc信息）的边缘服务列表
  • 和country对应的region在同一个数据中心（发现服务中的dc信息）的边缘服务列表
  • 和当前调度策略服务器在同一个数据中心（发现服务中的dc信息）的边缘服务列表
• 同一优先级筛选出来的服务需要随机打乱顺序，达到负载均衡，防止客户端一直将请求压在第一个服务器上的情况

6.1.2. 强制调度策略

• 客户端请求带 X-REGION 头域，指定获取哪个区域的服务

6.1.3. 考虑权重的调度策略

根据服务上报到发现服务 weight 字段，权重值大的优先级越高，排序越靠前。

6.1.4. 服务剔除策略

6.1.4.1. 服务下线策略

通过调度策略服务将某个边缘服务置为下线状态后返回的边缘服务列表中将踢出该服务，也就是说调度策略服务会停止引流到该服务上。

6.1.4.2. 服务饱和策略

• 边缘服务如果发现自己负载过高，可以向发现服务上报scheduler.overload=true 的 meta 信息来让调度服务返回服务列表过滤掉该服务
• 服务负载正常以后，需要上报scheduler.overload=false 或者移除该 meta 信息来解除过载

6.2. 调度服务安全性

6.2.1. 客户端黑名单

• 提供ip、ua、客户端版本、mac地址、用户帐号等多种黑名单规则来限制非法客户端的请求
• 黑名单由调度策略服务维护

6.2.2. 边缘服务白名单

• 只有在白名单的边缘服务才会返回给客户端，防止恶意客户端一直发现不存在的边缘服务
• 如果有新增边缘，需要添加到白名单中
• 边缘服务白名单由调度策略服务维护

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