1 .名词解释权威DNS服务器
组织的DNS服务器为组织中的几个服务器(如web服务器和邮件服务器)提供“权威”主机名和ip地址的映射。
边缘服务
在群集中暴露于外部网访问的服务
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 (公共DNS )，这些
Anycaset ip的节点一般是远远少于各个ISP的节点。 例如，广州电信用户可能使用某个公共DNS，但这个公共DNS中用户最近的是上海电信节点，更极端的是中国大陆没有节点，比如谷歌DNS8.8.8. 8。 不幸的是，国内很多用户使用谷歌DNS，导致互联网接入体验下降。 总的来说，使用公共 DNS，实际上破坏了上文的前提，导致 DNS 区域调度失效，用户以为得到了更快更安全的 DNS 解析，但实际得到了错误的解析，增加了网络访问延迟。
传统的DNS协议的区域调度过程的例子如下图所示。 假设某业务在foo.163.com上对外提供服务，则北京和东京各有一个节点，业务期望国内大陆用户接入北京节点，大陆用户接入东京节点。 由于权威基于DNS缓存确定返回的结果，因此如果用户使用不同的DNS缓存，则可能会分析为不同的结果。
如果ip的定位不能基于local DNS的ip进行定位，那么不是可以改为用原始请求的ip进行定位来解决这个问题吗？
2011年，以谷歌为首的几家公司提出了DNS的扩展方案edns-client-subnet (以下简称ECS )。 该扩展方案的核心思想是通过在DNS请求消息中包含原始请求的ip (即客户端的ip )，使权威DNS服务器能够根据该信息返回正确的结果。 目前，该方案还处于草案阶段。 该方案较好地解决了上述远程数据库分析的不准确性。 但是，该方案需要权威的DNS服务器和local DNS的支持，推广难度很大。
4.2 .不确定域名更改何时生效local DNS缓存域名解析结果，在域名更改生效之前存在延迟。
5. http重定向使用http重定向将内容传输到其他位置。
所有请求的域名都解析为GSLB计算机上的ipGSLB，根据源ip解析目标服务的ip，然后使用http重定向技术将用户请求重定向到目标主机
该方案的限制如下：
该方案仅适用于http请求，不适用于sip、dm等请求
重定向有性能损失，两次请求即可完成一次访问
获取的信息有限(仅限ip )，不能制定多个时间表策略
6 .调度服务调度服务是外部(客户机、sip )获得边缘服务的服务。 返回的服务ip列表遵循最近的访问、负载平衡原则。 通过客户端s
dk + 调度服务完成 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. 边缘服务白名单 只有在白名单的边缘服务才会返回给客户端，防止恶意客户端一直发现不存在的边缘服务如果有新增边缘，需要添加到白名单中边缘服务白名单由调度策略服务维护