搞过线上故障的兄弟应该都有这种经历用户反馈页面打不开视频卡在加载你登上服务器一看CPU、内存、带宽全都正常数据库也稳如老狗最后排查了半天发现流量被调度到了一个几百公里之外的机房链路延迟硬生生多出几十毫秒。这种情况下十有八九就是全局负载均衡器GSLB的策略出了问题。先说说我为什么想写这篇文章。这几年无论是做CDN、多云容灾还是海外业务加速GSLB都是绕不开的一个环节。但说实话很多人对它的理解还停留在智能DNS解析这个层面觉得它就是把不同区域的用户解析到不同IP。实际上GSLB做的是全局流量调度核心在于实时感知每个节点的健康状况、负载情况、链路质量然后综合决策把用户请求送到最合适的节点。它解决的是流量怎么在全国乃至全球的多个数据中心之间做分配这件事是分布式系统里最容易被忽视却又极其关键的一环。这篇文章适合谁看适合正在搭建多机房架构的运维和研发同学适合做CDN调度、边缘计算的小伙伴也适合那些已经上了GSLB但遇到调度不准、故障切换不及时、回源抖动等问题的人。我会把GSLB的原理、几种主流实现方式、调度策略的选择、生产环境中的应用以及我踩过的一些坑完整地梳理一遍。1. 全局负载均衡器到底在解决什么问题1.1 从一次跨城访问卡顿说起前两年我负责一个在线教育项目用户分布在全国各地机房也做了双活部署一个在华北一个在华东。平时一切正常但每到晚上高峰时段就会有西北地区的用户反馈上课延迟厉害。刚开始大家都以为是带宽不够结果扩了带宽情况依然没有改善。后来抓包一看西北用户的请求全部被调度到了华北机房而实际上华东机房的负载只有40%。问题出在哪就是我们当时的策略太简单只是单纯按用户IP地理位置就近分配没有把实时负载和链路质量算进去。西北到华北的链路在晚高峰拥塞严重反而华东更顺畅。这就是没有理解GSLB本质造成的。GSLB的核心目标不只是就近访问而是在全局视角下让每个用户的请求都能被最合适的节点处理。这里的最合适可能要考虑地理位置、链路质量、节点负载、成本甚至是运营商间互访的优劣。1.2 GSLB和普通负载均衡的区别很多人容易把GSLB和nginx、LVS这些本地负载均衡搞混。其实它们分工完全不同本地负载均衡通常说的SLB工作在单个数据中心内部把进来的流量按轮询、最少连接等算法分发给同一机房的多台后端服务器。它解决的是一台机器扛不住多台机器一起扛的问题。GSLB工作在数据中心之上它的调度对象不是某台具体的服务器而是分布在不同地理位置的数据中心或机房集群。它解决的是多个机房都能提供服务时选择哪个机房给这个用户的问题。用大白话说本地负载均衡是小区里的物业分配停车位——车进了小区物业安排你停到哪个车位GSLB是城市交通调度——你刚上高速导航就告诉你从哪个出口下去哪栋楼避开拥堵路段。层级不同决策时间尺度也不同。本地负载均衡被请求触发毫秒级决策GSLB通常在DNS解析或HTTP跳转阶段就完成决策提前把用户引到正确的入口。2. GSLB的几种核心实现方式2.1 DNS解析最常用的GSLB方案这是目前最主流的实现方式也是大多数人理解中的智能DNS。用户在浏览器输入域名时首先会向Local DNS发起解析请求。如果这个域名的授权DNS是GSLB的DNS服务器那么GSLB就会根据一系列策略返回指定机房的入口IP。这种方式最大的优势是对用户透明。用户只看到了正常的域名解析过程不需要装任何客户端也不感知调度发生了什么。主流CDN厂商基本都是用这种方式做全局调度的像阿里云、腾讯云、Cloudflare都有对应的GSLB产品。对外DNS做GSLB有个细节需要注意DNS解析过程本身的延迟。如果GSLB的授权DNS部署位置不合理或者Local DNS到授权DNS的网络路径很长会额外增加域名解析的耗时。所以很多大型GSLB系统都会把权威DNS节点部署在多个地域并且采用Anycast方式对外宣告IP这样各地的Local DNS都能以最短路径找到解析服务器。2.2 HTTP重定向方式这种方案看着笨拙但主动性强。用户的请求先到达一个GSLB调度器比如通过VIP或者一个统一的入口域名调度器根据策略计算出应该去哪个机房直接返回一个302响应Location头指向对应机房的URL。相比DNS解析HTTP重定向的好处是能拿到更完整的请求上下文用户的具体URI、Cookie甚至可以通过JS脚本收集到的客户端网络质量信息。这对精细化调度特别有用。比如可以做到同一个用户访问静态资源时去A机房提交表单时去B机房。缺点是响应会多一次302跳转的往返延迟对性能敏感的业务会有点伤。所以实际生产环境中HTTP重定向更多用在需要按路径、按会话做区分调度的场景比如API网关的第一跳。2.3 Anycast路由方式Anycast是BGP层面的全局调度本质上是让多个机房同时宣告同一个IP地址路由器根据BGP路由协议自动选择最优路径到达其中的一个机房。用户访问这个IP时流量会在运营商网络上就被引导向最近/最畅通的目标。这个方案最典型的应用是CDN的DNS集群和部分云厂商的负载均衡入口。它的调度粒度很粗决策完全交给路由协议但胜在部署简单天然具备高可用性——某个机房挂了BGP路由会自动收敛把流量切到其他节点。但是要注意Anycast只能解决路由层面最近无法结合业务负载和服务质量来做精细化的调度。两个机房都在同一个运营商网络很近的地方可能会因为BGP路由规则把大量用户都切到了其中一个机房造成负载不均衡。2.4 三种实现方式的对比实现方式决策依据粒度优点局限性DNS解析IP地理位置、健康状态、权重域名/子域名级别对用户透明、实现简单、可灵活结合策略依赖Local DNS缓存、TTL生效有延迟HTTP重定向请求上下文、实时负载、路径请求级别精细控制、可读取完整请求信息多一次跳转延迟、需要额外一层入口Anycast路由BGP路由距离、链路可用性IP路由级别免运维、天然HA、故障自动收敛调度粒度太粗、无法感知业务负载3. 调度策略GSLB怎么决定把流量送到哪3.1 就近访问基于地理位置和运营商这是GSLB最基础也是最常用的策略。GSLB拿到用户的IP后通过IP地理位置库查到这个IP属于哪个城市、哪个运营商然后把请求解析到距离最近的机房IP。这里有一个容易忽略的坑在DNS解析模式下GSLB看到的IP不是用户终端的IP而是用户Local DNS的IP。如果用户的Local DNS在北京而用户实际在成都那么GSLB大概率会按照北京的位置来调度。这个问题业界有个标准解法叫ECSEDNS Client Subnet它允许Local DNS在递归请求时带上用户终端的IP前缀段让权威DNS能拿到更接近真实用户的网络信息。但前提是Local DNS要支持ECS目前国内主流运营商和公共DNS都已经支持得不错可如果用户走的是企业内网DNS就要小心了。另一个细节是运营商之间的互联瓶颈。国内网络环境下跨运营商的访问质量通常不如同运营商好。所以GSLB在做就近解析时一定要把运营商作为一个重要维度。即使某个机房物理距离很近如果用户是联通用户而机房放在电信AS里实际体验可能会比距离稍远但同运营商的机房差很多。3.2 基于RTT和链路质量的动态决策静态地理位置策略虽然简单但可靠性有限。链路的质量是会波动的最近和最快很多时候不是一回事。所以生产级的GSLB都会引入实时的链路探测和RTT数据。具体做法是在每个机房部署一个探测节点探针定期对全网各主要网络区域发起探测测量到不同地区用户/运营商网络的往返时延、丢包率。然后把这些数据上报到调度中心形成一张节点-区域质量矩阵。当用户请求到达时GSLB不只看用户IP在哪还会查一下这个区域的用户最近一段时间到各个机房的链路质量选择质量最好的节点。我见过一个比较典型的成功案例某出海业务在德国和新加坡各有一个机房欧洲用户按就近调度应该去德国。但有一段时间中东用户的反馈延迟很高后来把RTT数据拉出来一看中东到德国的路由绕了一圈实际延迟比到新加坡还高。调整策略后把中东地区用户的流量切到新加坡整体体验明显上升。这就是单靠地理位置调度做不到的。3.3 加权轮询与容量水位当多个机房的条件差不多时需要考虑容量分配。每个机房的服务能力不可能是无限的GSLB要把流量按期望比例分发到各个节点。这时候就到了加权轮询出场。权重通常根据机房的带宽、服务器数量、历史承载能力来设定。比如华东机房带宽大、机器多权重设成70%华南机房资源少权重设成30%。GSLB在解析时会按这个比例返回对应机房IP。但这只是一个静态的目标比例。生产中更需要的是动态容量管理。每个机房可以定时上报自己的实时负载、连接数、CPU水位到调度中心当某个机房的容量水位超过阈值比如CPU超过70%、连接数超过最大值的80%GSLB就自动降低这个节点的权重把新流量往其他空闲节点引。这就是容量感知调度。这里需要留意阈值和摆动问题。如果负载采集周期太短、阈值设置太严格节点可能在过载-恢复之间来回切换导致权重抖来抖去解析结果不稳定甚至引发流量抖动。一般建议给负载评估加一个窗口期比如持续30秒超过阈值才降低权重持续5分钟低于阈值才恢复权重用迟钝换稳定。3.4 会话保持与故障转移会话保持是GSLB里一个容易被想简单的东西。很多业务要求用户在一次会话期间始终访问同一个机房否则登录状态、Session信息就对不上了。实现方式一般有三种IP Hash根据用户网段做哈希同一个IP段固定解析到同一个机房。简单但不够精确。Cookie植入GSLB返回解析结果时同时下发一个机房标识的Cookie后续请求带上这个Cookie调度器直接按Cookie决定目标机房。应用层会话同步在多个机房之间做Session同步即使切到其他机房也能找到会话。这种成本最高但调度自由度最大。做故障转移时最重要的原则是快速发现、冷静切换。GSLB要持续对所有节点做健康检查包括但不限于TCP端口探测、HTTP请求探测、心跳协议等。一旦某个节点被判定失败GSLB立即将其从解析结果中摘除同时按策略将流量切换到剩余节点。这个冷静很关键。我之前见过一个事故某个后端服务因为GC停顿健康检查连续失败了两次GSLB立即对它做了下线处理流量全部切到另一个机房结果那个机房容量有限直接雪崩。后来我们加了一个机制确保健康检查正常连续超过5分钟才允许节点重新加入解析并且加入后先把权重调低观察一段时间再逐步恢复到正常比例。3.5 策略组合的优先级实际生产环境很少只用单一策略而是多种策略叠加形成一个决策链条。我个人常用的策略优先级是故障隔离全局 动态容量限制全局 链路质量区域级 就近访问用户级 权重分配兜底。故障隔离的优先级最高节点挂了什么策略都没意义。容量限制防止单个节点过载。链路质量决定了同一区域内用户的选择如果一个区域的用户到A机房链路明显比B机房好优先选A。如果链路质量没有明显差异再回到就近访问逻辑选物理距离最近的。当所有条件都相近时用权重做流量比例分配。这样的组合既能保证稳定性和高可用又兼顾了用户体验和资源利用效率。4. 手把手搭一套GSLB调度系统4.1 方案选型自研还是买云服务在开始搭之前先考虑清楚用自研还是用现成的云产品。如果业务规模不大机房数量不超过两个云厂商自带的全局流量管理产品比如阿里云的GTM、腾讯云的WAF负载均衡联动、AWS的Route 53基本就够了省心省钱。这些产品内置了健康检查、故障转移、按地域解析这些核心功能只需要在控制台配一下策略就能用。如果机房数量多、有私有化部署需求、或者需要很强的与自身业务联动的调度逻辑那才需要考虑自研。自研GSLB的核心组件有三个智能DNS服务、健康检查探针集群、调度决策中心。下面我按一个模拟自研小型GSLB的流程把关键部分怎么搭说清楚。这里以BIND 9.16为例开源DNS软件里支持视图和较新功能比较全的版本配合OpenResty做健康检查数据上报调度逻辑通过脚本动态生成DNS解析来搭一个能在测试环境跑起来的最小系统。生产环境注意把它替换成商业负载均衡器或云厂商GTM即可。4.2 环境准备与拓扑设计假设我们有两个机房北京机房和杭州机房分别有以下入口IP北京机房 A203.0.113.10杭州机房 B198.51.100.10GSLB的授权DNS IP假设为 192.0.2.53。用户访问的业务域名是www.example.com。在GSLB调度系统里这个域名会对应两套A记录分别指向北京和杭州。GSLB的工作就是决定对不同用户返回哪个IP。首先确保所有机器的时间是同步的特指实体机或虚机部署用NTP校准因为健康检查数据和调度日志要按事件排序时间不同步会让排障变得异常痛苦。4.3 核心健康检查脚本的编写逻辑健康检查是整个GSLB系统的眼睛。这里我分享一个实际在用的HTTP健康检查脚本的简化版核心逻辑就是模拟用户请求探测后端健康同时记录响应时间。#!/bin/bash # health_check.sh # 用法: ./health_check.sh http://203.0.113.10/healthz TARGET_URL$1 CHECK_INTERVAL10 # 检查间隔 10秒 FAIL_THRESHOLD3 # 连续失败3次判定节点故障 RECOVER_THRESHOLD5 # 连续成功5次判定节点恢复 STATE_FILE/tmp/gslb_health_$(echo $TARGET_URL | md5sum | cut -d -f1).state # 初始化状态 if [ ! -f $STATE_FILE ]; then echo fail_count0 $STATE_FILE echo success_count0 $STATE_FILE fi source $STATE_FILE # 使用curl请求健康检查URL设置连接超时和最大响应时间 HTTP_CODE$(curl -o /dev/null -s -w %{http_code} --connect-timeout 3 --max-time 5 $TARGET_URL) CURL_EXIT_CODE$? if [ $HTTP_CODE 200 ] [ $CURL_EXIT_CODE 0 ]; then fail_count0 success_count$((success_count 1)) if [ $success_count -ge $RECOVER_THRESHOLD ]; then echo STATUS: UP echo fail_count0 $STATE_FILE echo success_count0 $STATE_FILE else echo STATUS: RECOVERING echo fail_count0 $STATE_FILE echo success_count$success_count $STATE_FILE fi else success_count0 fail_count$((fail_count 1)) if [ $fail_count -ge $FAIL_THRESHOLD ]; then echo STATUS: DOWN echo fail_count0 $STATE_FILE echo success_count0 $STATE_FILE else echo STATUS: UNKNOWN echo fail_count$fail_count $STATE_FILE echo success_count0 $STATE_FILE fi fi这个脚本有几个设计要点第一健康检查的URL一定要选择轻量级的接口比如/healthz它只检查服务进程和最基本依赖不要走复杂业务逻辑更不能查数据库。我见过有人把业务接口当健康检查结果业务突发流量时接口响应慢健康检查频繁失败流量被切走反而放大了故障。第二连续失败次数和连续成功次数的设置很关键。连续失败3次判定故障可以过滤掉偶发的网络抖动连续成功5次才恢复可以避免服务刚启动还没完全就绪就接流量。阈值要根据系统的重要程度和服务启动时间来定不能照抄。第三健康检查脚本的结果要上报到调度中心。一般通过一个HTTP接口往调度中心推送比如调度中心提供一个/api/nodeStatus接口健康检查脚本把节点ID、状态UP/DOWN、响应时间这些数据POST上去。调度中心把这些数据维护在内存或者Redis里。4.4 动态生成DNS解析与调度策略有了健康检查状态下一步就是让DNS解析根据这些状态和调度策略来动态生成。一种简单的实现方式是调度中心每分钟根据当前健康状态、负载数据、策略配置生成一组BIND的view配置和zone文件然后执行rndc reload或named-checkzone。这样GSLB的DNS在收到解析请求时就会按照最新的配置去做响应。BIND 的view功能可以按来源IP区分这是实现按地域/运营商调度的基础。下面是一个简化的named.conf片段说明view的用法// named.conf 相关片段 acl beijing_users { 123.125.0.0/16; 124.126.0.0/16; }; acl hangzhou_users { 115.236.0.0/16; 160.121.0.0/16; }; view beijing_view { match-clients { beijing_users; }; zone example.com { type master; file /etc/bind/zones/example.com.beijing; }; }; view hangzhou_view { match-clients { hangzhou_users; }; zone example.com { type master; file /etc/bind/zones/example.com.hangzhou; }; }; view default_view { match-clients { any; }; zone example.com { type master; file /etc/bind/zones/example.com.default; }; };对应的zone文件也很直观; example.com.beijing $TTL 60 example.com. IN A 203.0.113.10 ; 北京机房 ; example.com.hangzhou $TTL 60 example.com. IN A 198.51.100.10 ; 杭州机房当北京机房的健康状态为DOWN时调度中心只要把example.com.beijing这个zone里的A记录改成杭州的IP再reload一下北京用户的流量就自动切到杭州机房了。之后的流量对这个过程是无感知的。TTL这里我特意设置了60秒这是GSLB场景下的一个常见折中TTL太短Local DNS会频繁向上游请求增加GSLB系统的QPS压力TTL太长调度切换后客户端和Local DNS缓存里的旧IP可能会继续服务一段时间故障转移延迟变大。CDN厂商的TTL一般设置成30~300秒之间具体要看业务对故障容忍度的要求。生产级的GSLB系统不可能用这么简单的方式比如静态ACL配置对IP段变化的适应性很差所以真实系统里一般会引入IP地理库或者调用在线IP定位API每次请求时动态解析来源IP段再拼装对应的ACL。但原理是相通的。4.5 流量观察与灰度发布GSLB系统上线后必须要有数据看板至少应该有这几个维度每个机房的解析次数、每个机房的健康检查状态、每个用户区域的实际调度结果。我自己的习惯是每次调整调度策略后用两条命令先手动验证一下解析结果# 模拟北京地区Local DNS的解析请求 dig 192.0.2.53 www.example.com subnet123.125.0.0/24 # 模拟杭州地区Local DNS的解析请求 dig 192.0.2.53 www.example.com subnet115.236.0.0/24subnet参数可以模拟ECSEDNS Client Subnet让GSLB认为是来自某个地区的用户在发起解析请求。加上它你就能在没有真实用户的情况下验证调度策略是否符合预期。如果策略要切换大量流量建议做灰度发布不要一下子全量切。具体做法先把某个区域的部分IP段比如10%的用户切到目标机房观察半小时日志确认没有异常再逐步扩大比例。在GSLB里实现灰度本质上就是在策略里控制不同ACL视图的精细度和权重。5. GSLB在生产环境中的典型应用场景5.1 CDN中的全局调度CDN是整个互联网里GSLB应用最广泛的领域。一次典型的CDN访问流程是用户请求域名GSLB的权威DNS根据用户IP和请求内容解析出某个边缘节点IP用户从边缘节点拿数据。这里的GSLB面临两个挑战边缘节点数量巨大一个大型CDN有上千个边缘节点调度系统需要实时掌握每个节点的健康、负载、带宽余量。流量有突发性比如某个热点视频突然爆发GSLB需要快速识别到某个节点带宽即将打满把流量调度到其他节点防止这个节点服务质量下降。所以CDN的GSLB通常都有两级一级做区域调度二级做节点调度。区域级判断去哪个省市的节点集群节点级再在集群内部选择具体的边缘节点。每一级都是独立的GSLB决策。5.2 多云多活的双活流量调度越来越多的企业选择多云部署尤其是主备或多活架构。GSLB在其中扮演的是流量指挥家的角色。我以前参与过的一个金融项目就是这样核心系统和数据库在两个云厂商各部署了一套平时两边都在服务读流量按比例分配。但其中一个云厂商偶尔会出现网络波动或机房维护GSLB系统会提前收到告警把流量切到另一个云上。在这个过程中最难的其实是两个云之间的数据一致性但GSLB的工作也不轻松——切换不能一下子全切不然目标云扛不住要逐步调权重从50:50调到20:80再到0:100整个过程持续几分钟但对用户来说没有感知。5.3 跨地域容灾切换容灾场景和双活还不一样容灾一般是主节点负载全部流量灾备节点平时只做数据和状态同步不对外服务。当主节点不可用时GSLB把流量整体切换到灾备节点。这里的GSLB有一个额外的工作容灾切换前的预检。因为灾备节点平时没有流量如果它自身有问题比如代码版本没同步、数据库连不上却一直没有暴露真到切换时就会二次故障。所以容灾场景的GSLB通常要持续对灾备节点发健康检查并且在切换前调度系统要自动对灾备节点做一遍预演练确认能正常接流量才允许切换。5.4 边缘计算与IoT场景边缘计算的兴起让GSLB有了新的挑战。边缘节点的数量可能成百上千并且节点资源可能比CDN的边缘节点还要弱一个节点的宕机影响范围更可控但也要求调度系统发现故障的速度够快。IoT场景更有意思大量设备长连接固定在某个节点GSLB必须保证这些设备在重连时不会被调度到别的节点否则会话管理的成本会暴增。这要求GSLB具备会话亲和的能力可以在解析时使用固定的IP Hash算法让特定设备始终解析到同一个节点。6. 常见问题与排查实录6.1 DNS缓存导致调度不生效现象GSLB已经切流了但部分用户还是访问老机房。原因Local DNS或客户端本地缓存了旧的A记录还没过期。排查方法使用dig直接查授权DNSdig 192.0.2.53 www.example.com确认GSLB侧返回结果已经是新IP。查询运营商的Local DNSdig www.example.com 223.5.5.5看返回结果。对比TTL设置如果TTL太长考虑后续业务上把TTL调低如果已经切流但回流慢可以考虑在切换前提前24小时调低TTL。我自己踩过的一个具体坑是某次容灾切换前没有提前把TTL从10分钟调低到1分钟切换命令发出后部分用户最长在10分钟内还是访问旧节点。后来我们的流程改为故障演练前48小时先统一把域名的TTL降到60秒演练结束后再恢复。6.2 健康检查误报导致流量雪崩现象后端服务正常但GSLB判定节点DOWN把流量全部切到了另一个机房导致另一个机房过载。原因健康检查探针本身出问题。比如健康检查URL依赖的某个内部组件Redis、鉴权服务出现抖动导致健康检查接口返回5xx或超时。排查方法自己手动curl健康检查URL看返回是否真的有问题。看健康检查探针的部署位置如果探针和业务共用网络链路网络抖动会影响探针的判断。检查健康检查超时时间设置是否太短后端服务GC停顿几十秒时超时时间1s就会误报。这是一个特别需要冷静期的地方。我建议状态切换都加上滞后逻辑即连续N次失败才判定DOWN连续M次成功才判定UP并且DOWN到UP的滞后时间一定要远大于UP到DOWN的防止服务刚恢复就被塞满流量。6.3 基于地理位置调度的IP库不准现象某些地区用户没有按预期被调度到就近机房。原因IP地理位置库数据不准确或者用户的Local DNS和实际位置差异太大。排查方法用第三方IP库工具比如ipip.net的离线库、纯真IP库对比当前GSLB使用的IP库看差异。检查是否启用了ECS如果Local DNS不支持ECSGSLB只能按Local DNS的位置调度这个物理位置大概率和你期望的用户位置不一致。针对特定大客户可以在GSLB里配置白名单IP段手动指定调度目标。对IP库不准的问题我通常会在GSLB里加一个兜底视图也就是默认任何未命中的IP段都解析到容量最大的主干机房而不是直接按最近的逻辑猜。宁可用一个质量稳定的主干也不能让用户被瞎切到某个质量未知的小机房。6.4 会话保持失效现象用户在访问过程中突然被切到另一个机房登录态丢失。原因会话保持策略没有和业务真实的会话机制对齐。排查方法确认业务侧的会话是存储在单机内存、Redis还是数据库。如果是单机内存GSLB切机房必然导致会话丢失。确认GSLB的会话保持方式如果是IP Hash需要检查是否是用户整个网段都发生了迁移。建议多机房会话同步或者把会话状态放到独立缓存层比如Redis集群跨机房同步这样即使GSLB切机用户无感。如果要保住会话又要容灾最稳的方案是GSLB转发规则固定按IP Hash同时业务层把Session放到统一的缓存服务中。这样调度不丢会话会话也不绑定节点。6.5 常见问题速查表故障现象可能原因快速排查命令/方法解决方案用户访问延迟高跨运营商/跨地域调度dig GSLB_DNS 域名查看解析到哪个IP优化IP地理位置库增加链路质量探测切流后回流慢DNS TTL过长dig 域名 noall answer看TTL值切换前提前调低TTL节点频繁DOWN/UP抖动健康检查阈值过灵敏查看健康检查日志统计失败次数增加状态判断的滞后时间某个机房过载权重分配不合理查看各机房解析比例与容量使用率动态容量感知调度用户会话丢失会话保持策略失效检查会话状态存储方式配置会话同步或独立缓存层调度策略符合预期但访问没变Local DNS不支持ECS使用EDNS模拟测试解析升级支持ECS或对大客户IP段配置策略6.6 几个排障小技巧最后分享几个排障中的实用小技巧特别是GSLB这种离用户越远越难排的系统技巧一一定要记录下完整解析链路。当用户反馈问题时第一件应该做的事是拿到用户实际使用的Local DNS IP和它递归获取到的解析结果。很多DNS工具比如阿里云的DNS拨测可以模拟从特定运营商和地区发起的DNS解析快速定位调度结果。技巧二GSLB的日志要带请求来源维度。解析日志里除了记录返回哪个IP一定要把来源IP段、命中的策略名、决策原因如failover: beijing-down一起记录。不然事后翻日志你会发现只知道结果是什么但不知道为什么是这个结果排障会非常痛苦。技巧三健康检查的数据最好也做历史趋势。健康检查不只是UP/DOWN两个状态响应时间的变化趋势也能暴露问题。如果某个机房的健康检查响应时间从5ms涨到500ms说明内部有性能隐患提前处理的效果远比等它挂了再切要好。写在最后的一点经验做GSLB这几年我最大的体会是GSLB的难点永远不在于那几个调度算法而在于全局的数据质量、决策速度和控制粒度之间的平衡。数据质量差了再优化的策略也白搭决策速度慢了故障切不过去影响的是所有用户控制粒度太粗想做灰度发布、精细调度就没抓手。比较推荐的做法是每半年对你现有的GSLB系统做一次故障演练预演。模拟一个节点故障观察流量切换的整个链路健康检查多久能发现、调度中心多久能生效、DNS TTL多久能让用户实际跳转、切换后目标节点会不会过载。这四个时间点合起来就是你的业务的真实故障转移总时长这个数字要比任何文档里的承诺都更有说服力。另外一个不算技术但很实用的建议所有跟GSLB相关的配置变更操作前一定要先在测试环境完整跑一遍。尤其要注意的是测试环境要和线上共用一套调度中心的逻辑不然测试环境验证通过的策略到了线上网络环境变了结果可能完全不同。GSLB是那种典型不出问题岁月静好一出问题全网故障的组件投入在测试和预案上的时间永远都不会浪费。