从监控屏上看到华东某省流量异常的那一刻我就知道问题又出在调度上。用户明明在上海GSLB却把他导到了北京节点跨省流量哗啦啦地流成本损耗肉眼可见。这不是偶发而是CDN调度失准的典型症状调度系统的“就近接入”依据是Local DNS的位置而不是用户真实出口IP的位置。要解决这个问题不能只依赖DNS递归链路必须在GSLB这层引入IP归属地查询把“用户到底在哪”搞清楚再做精准选点。这篇文章记录的就是我在自建CDN调度系统中的一次完整改造从定位调度失准的原因到在GSLB层落地IP归属地查询再到上线后的效果评估和踩坑复盘。内容面向自建CDN或边缘计算平台的架构师、对调度系统实现细节感兴趣的开发以及正在为跨省流量和首字节时延头疼的运维同学。不扯虚的全是实际操作。1. 调度失准的根源GSLB一直在猜“用户在哪”先说结论绝大多数自建CDN的调度失准不是节点不够而是GSLB在回答一个它根本回答不准的问题——用户到底在哪。1.1 GSLB的传统决策链路GSLB全局负载均衡是CDN的调度大脑。用户的浏览器或APP请求一个域名时Local DNS最终会把解析请求交到CDN的权威DNS上权威DNS再把这个请求转发给GSLB系统由GSLB根据一组规则返回一个最优边缘节点的IP。传统GSLB做决策时会看几个维度的信息优先级大致如下请求来源IP实际上拿到的是Local DNS的出口IPEDNS Client SubnetECS扩展字段RFC 7871里定义的、能携带用户子网信息的机制节点健康检查状态节点实时负载节点带宽成本问题就出在第一和第二项上。GSLB拿到的“来源IP”绝大多数情况下并不是用户终端的IP而是用户所在运营商的Local DNS递归节点的出口IP。ECS虽然能携带用户侧子网信息但这个字段是否生效完全取决于用户的Local DNS有没有实现ECS协议。1.2 三个真实场景里的调度偏差场景一Local DNS跨省递归。很多中小运营商的Local DNS并没有做就近递归优化比如一个江西用户他的Local DNS可能递归到了上海的一个公共DNS节点。GSLB一看来源IP是上海的就把用户调度到了上海节点用户和节点之间隔着江西到上海几百公里。场景二移动网络漫游。用户在江苏出差用的是上海归属地的SIM卡。运营商核心网的Local DNS归属地是上海用户实际位置在南京。GSLB按来源IP判断把人导到了上海节点结果数据在江苏和上海之间绕了一圈。场景三大企业专线出口。很多公司有总部专线企业内网的用户访问域名时DNS请求统一从总部出口走。总部在上海、用户在广州分公司的场景很常见GSLB会把广州的用户全部调度到上海节点。这三个场景有一个共同特征GSLB拿到的是一个“代理后的位置”不是用户真实位置。在没引入IP归属地查询之前调度系统等于是靠猜的猜对了皆大欢喜猜错了就是跨省流量的真金白银流失。1.3 为什么ECS协议没能解决所有问题ECS的设计初衷就是为了解决Local DNS位置失真的问题它允许Local DNS把用户的子网前缀附加到查询中。但实际落地效果远没有协议设计那么美好原因有三个一是客户端递归链路上的中间DNS服务器没有传递ECS字段运营商自建的DNS或企业内网DNS经常不支持这个扩展。二是ECS携带的只是子网前缀通常是/24很多情况下运营商只给了/16甚至更粗的粒度地理位置精度依然不足。三是ECS的覆盖范围有限移动网络和部分地区DNS对ECS的支持率一直不高实测下来支持率能到百分之六七十已经算很优秀的了。所以ECS并不能替代IP归属地查询两者解决的是不同层面的问题。ECS解决的是“用户子网信息是否传递”的问题IP归属地查询解决的是“给定一个IP它到底在哪个省哪个市”的问题。GSLB要做的是把这两个信息都拿到才能给出更贴近用户真实位置的调度结果。2. GSLB层引入IP归属地查询的正确姿势既然要引入就要先想清楚改造的位置和边界。我在改造时反复确认了一件事IP归属地应该嵌入在GSLB的调度链路中而不是做成一个独立的旁路服务。2.1 改造后的调度链路长什么样改造前的链路是用户请求域名到Local DNSLocal DNS向上递归并最终到CDN权威DNS权威DNS将请求转发给GSLB。GSLB根据来源IP、ECS、节点健康状态返回最优节点。改造后的链路则多了一个关键步骤GSLB收到解析请求后先把请求来源IP或ECS携带的用户子网信息送到本地IP归属地查询模块。查询模块返回这个IP对应的省份、城市、ISP运营商、经纬度然后GSLB再基于这四个维度的信息从节点列表中筛选出真正的“就近节点”。这里有一个设计细节要特别注意IP归属地查询模块必须能在GSLB进程内完成不能每次都走远程RPC或HTTP调用。GSLB是一个高并发接口每秒钟要处理的DNS解析请求数量非常大。如果在调度决策中插入一个网络RPC最直接的影响是解析时延会大幅增加这在DNS场景里是不可接受的。2.2 归属地数据在调度决策中扮演的角色我一直把IP归属地数据理解为一个“过滤器”而不是“决策器”。它的核心职责是把候选节点集缩小到“用户所在省份及周边省份”之后的具体节点选优再由负载、健康状态、成本等因素决定。这一步非常关键。如果直接把IP归属地当作唯一决策依据就会出现一种很尴尬的情况用户在某省某市结果该城市的节点已经过载了但GSLB硬是按照地理位置把它导过去用户体感反而更差。正确的做法是把地理位置信息作为第一层过滤条件把用户能接受的节点范围圈定出来再在圈内做加权选优。2.3 模块之间的数据流向以我改造后的系统为例核心流程拆解如下每一步都值得你在自己的系统里对号入座步骤1GSLB收到DNS解析请求从请求中提取来源IP同时解析ECS字段。步骤2如果ECS存在且精度足够比如/24优先用ECS中的用户子网作为查询IP否则用来源IP。步骤3查询本地内置的IP归属地库得到省份、城市、ISP、经纬度。步骤4若本地库未命中调用兜底在线API并将结果写入本地缓存。步骤5GSLB根据归属地信息把节点列表过滤到候选集同省优先周边省份兜底。步骤6在候选集内综合节点健康状态、实时负载、成本权重选出最终返回的节点。步骤7把本次调度的完整快照写入日志来源IP、ECS子网、归属地结果、候选集、最终节点、命中省份。把第7步单独拿出来说是因为很多团队的日志只记录“解析请求来源IP”和“返回节点”没有记录归属地查询结果和候选集。一旦出问题排查链路断了一半根本不知道GSLB决策时看到了什么。改造的时候一定把这一步加进去后面排障会感激自己。2.4 “查询时机”和“缓存策略”是两个被忽视的大坑查询时机的问题在于GSLB收到请求时用户IP和ECS已经拿到了但IP归属地库的查询结果在短时间内是稳定的。同一个用户在一小时之内反复发起解析每次都在线查一次属于纯浪费。但如果完全依赖缓存又会出现IP段重新分配后缓存数据过期的问题。我的方案是一个双层缓存查询模块内部维护一份“IP段到归属地”的进程内哈希表以/24网段作为KeyTTL设置为12小时。每次查询先查进程内缓存命中就返回。未命中的IP段才走离线库查询并回填缓存。这样做的效果是在线API的调用量被压到极低实测大概只有万分之几的请求会穿透到在线查询。3. 数据源怎么选别迷信大厂API也别迷信免费库IP归属地查询的数据源选择直接决定了调度精度上限。数据的不准确后面算法再精巧也是空中楼阁。3.1 三种主流数据源的横向对比市面上的IP归属地数据源可以粗分为三类各有各的优劣势我直接列个表数据源精度更新机制成本适用场景商业离线库MaxMind GeoIP2 City、IP2Location城市级带经纬度运营商级每周或每月更新按授权年费生产环境主库免费离线库纯真IP库等省级为主部分城市级社区不定期更新免费测试环境、兜底在线API各类IP归属地查询服务通常比离线库精准支持ISP细分服务商实时维护按次计费低频补查、兜底修正从实际开发的角度说我的选型经验是商业离线库作为主库在线API作为兜底修正免费库只用来做测试环境。纯免费库的省钱方案并不是不能跑但数据更新的不确定性会在某一天突然给你一个大惊喜——某个省份的IP段换运营商了调度系统一无所知。3.2 离线库的“冷加载”和“温更新”离线库不是部署上去就完事的。第一坑是冷加载慢GB级别的IP库文件程序启动时全量加载到内存时间可能到几十秒甚至分钟级。GSLB重启一次如果加载期间调度请求就进来那调度体验会很糟糕。我的解决办法是GSLB进程启动时先加载一个精简的预构建索引文件只包含省份、城市、经度、纬度、ISP五个维度去掉完整库里的联合索引字段把冷加载时间压到3秒以内。完整数据则采用异步加载完成后热替换内存中的索引。这保证了调度服务在重启后能快速对外可用。另一个经验是“温更新”。IP数据库不是每天都会有大变动但也不是一成不变。我这边是每天凌晨拉取增量更新包合并进本地库每周做一次全量同步。更新时用双buffer机制——先写新数据到备用buffer切换生效前校验数据完整性确认无误再原子替换。避免出现更新到一半、调度读到脏数据的情况。3.3 在线API的正确用法不是“每次都查”在线API的精度一般比离线库要高但每次查询都要消耗一次网络开销和费用。最忌讳的做法是把在线API加在GSLB主路径上每次DNS解析都去请求一次这会让解析时延从几十毫秒暴涨到几百毫秒甚至导致API服务方限流封禁。正确姿势是在GSLB的调度模块里把在线API当作二级兜底离线库查不到的IP段才发起在线查询。查询结果写回到本地缓存之后同类请求直接命中缓存。同时给在线API设置熔断机制连续失败超过阈值就自动熔断回归纯离线库调度模式。我遇到过一种更隐蔽的问题某在线API服务商在高峰期会返回兜底数据——不管什么IP都返回一个默认省份如果不校验返回结果的IP段字段调度系统会把这个“假归属地”当作真实归属地去算节点造成批量误调度。所以接入在线API时必须校验返回结果中的IP段范围和查询IP是否匹配不匹配直接丢弃当作查询失败处理。4. 从“查到归属地”到“选对节点”调度打分逻辑怎么改数据源解决了“用户在哪”的问题接下来的核心是拿到省市和经纬度之后怎么把这些信息转化为合理的节点选择。这块是改造的重头戏。4.1 先用归属地做候选集过滤拿到用户归属地后第一层过滤逻辑按照“同省同运营商 同省异运营商 邻省同运营商 邻省异运营商 区域中心节点”的顺序来设计。同一省份内有可用节点时优先选同省同运营商节点。同省没有目标运营商节点时才考虑同省其他运营商的节点。省内节点全挂或过载时再扩大到相邻省份。最后兜底是区域中心节点比如华北、华东、华南各有一个大区节点。这样做的好处是绝大多数请求在第一步和第二步就完成了调度候选集被迅速缩小后续的打分计算量也小很多。4.2 距离计算别只靠“城市名匹配”要上经纬度很多初级实现是拿到用户城市然后拿城市字符串去匹配节点城市匹配不中就随便返回一个节点这种做法太粗糙了。同城是匹配了可有些城市地域跨度极大比如重庆、武汉城市内节点分布在不同方向距离差了几十倍公里。正确做法是使用IP归属地库返回的经纬度计算与各候选节点经纬度之间的球面距离。经典算法是Haversine公式我直接把它贴在这里这个公式在所有语言里都是同一套import math def haversine(lat1, lng1, lat2, lng2): 返回两点间球面距离单位公里 R 6371.0 phi1 math.radians(lat1) phi2 math.radians(lat2) dphi math.radians(lat2 - lat1) dlmb math.radians(lng2 - lng1) a math.sin(dphi / 2) ** 2 math.cos(phi1) * math.cos(phi2) * math.sin(dlmb / 2) ** 2 c 2 * math.atan2(math.sqrt(a), math.sqrt(1 - a)) return R * c但经纬度距离只是理论距离不能完全等价为网络时延。实际经验是在网络链路正常情况下距离和时延有较强相关性但在跨运营商场景下理论距离很近的两点比如联通用户访问电信节点实际时延可能非常高。所以距离只能作为打分项之一不能作为唯一指标。4.3 综合打分逻辑距离、负载、成本的三角博弈最终节点的选择我用的是一个简化版的加权打分模型分享出来供参考距离分权重0.5基于Haversine距离做倒数归一化距离越近得分越高。负载分权重0.3节点当前CPU/带宽负载越低得分越高。成本分权重0.2各节点带宽成本不同成本低的节点得分略高防止总是把流量导到最贵的区域节点。三个分数加权求和后选择总分最高的节点。在负载分里加入了一个硬性门槛超过80%负载的节点直接排除不参与打分。这样做是为了防止一个节点明明已过载却因为距离近而在分数上胜出。下面是一段极简的伪代码示例展示了这个逻辑在主循环里的处理方式def choose_edge_node(client_ip, node_status, load_map, cost_map, ip_geo_db): geo ip_geo_db.lookup(client_ip) if not geo: # 查询失败时回退到传统调度逻辑 return legacy_schedule(client_ip, node_status, load_map) # 第1层按省份运营商过滤候选节点 candidates filter_by_province_isp(geo.province, geo.isp) if not candidates: candidates filter_by_region(geo.region) if not candidates: candidates list(node_status.keys()) # 第2层排除不健康或过载节点 alive [ n for n in candidates if node_status[n].healthy and load_map[n] 0.8 ] if not alive: return fallback_node(geo, candidates) # 第3层距离、负载、成本加权打分 scores [] for node in alive: dist haversine( geo.lat, geo.lng, node.lat, node.lng ) dist_score 1.0 / (1.0 dist / 100.0) load_score 1.0 - load_map[node] cost_score 1.0 - cost_map[node] / max_cost scores.append(( node.id, 0.5 * dist_score 0.3 * load_score 0.2 * cost_score )) scores.sort(keylambda x: x[1], reverseTrue) return scores[0][0]这里有一个值得展开的原则打分模型不能只有地理位置一个维度。我见过一些团队把调度系统写成了“IP归属地匹配器”判断用户是广东的就无脑返回广东节点完全不看节点负载。后来某个节点被打满全网时延抖动才意识到地理位置只是众多维度之一。4.4 缓存设计别让GSLB把时间花在查库上GSLB的典型QPS很高绝不能让每次都查IP库成为瓶颈。我在实现中用了两级缓存第一级是进程内LRU缓存key为/24网段value为归属地信息TTL 12小时。命中率实测可以达到99%以上。第二级是Redis分布式缓存key为/16网段TTL 24小时用于多实例GSLB之间共享查询结果减少离线库被重复加载的压力。要注意的是进程内缓存和Redis缓存都可能因为IP段重新分配而产生脏数据。所以缓存必须有过期时间且过期后必须重新从离线库或在线API获取新数据。我的经验是TTL设置不宜超过24小时否则IP段变动带来的误调度会被放大。4.5 在线API超时与异常兜底在线API接入时一定要设置超时和异常兜底策略。我在网关层设置的超时是800ms超过就直接返回离线库结果不让GSLB主链路等待。连续失败超过10次会触发熔断熔断窗口10分钟在窗口内直接跳过在线查询。有一段时间我在排障时发现在线API偶发返回超时在GSLB日志里看到大量“online_geo_api_timeout”的告警但调度链路并没有因此变慢原因是兜底逻辑生效了直接降级到离线库结果。这个兜底设计无形中挡掉了大量潜在事故。5. 上线后的实际效果跨省流量下降了多少改造上线后的效果直接看数据和案例比任何理论分析都有说服力。5.1 核心指标跨省调度比例、首字节时延、回源率我这边重点盯三个指标一周内就看到了明显变化指标改造前改造后一周变化跨省调度比例用户省份与节点省份不一致约11%约2.8%下降74%首字节时间TTFB P50128ms72ms下降44%节点回源率5.6%4.1%下降27%跨省调度比例的统计方法是从GSLB日志中取每条解析请求的IP归属地省份和实际返回节点省份两条不一致且距离超过阈值就算一次跨省调度。这个口径比较直观也方便口径对齐。5.2 上线后的一个典型调度决策拆开看全过程拿一条真实日志举例。来源IP归属地查到是浙江省杭州市电信GSLB候选集先生成了杭州电信节点最优、杭州联通节点跨ISP候选、上海电信节点邻省候选、上海联通节点次级。排除健康检查异常的节点后杭州电信节点负载42%上海电信节点负载65%。分数算下来杭州电信节点最高最终返回杭州电信节点IP。用户上线后的测试显示首字节时间从改造前的150ms降到了40ms用户反馈页面打开速度明显变快。这个过程完美展示了归属地查询和负载均衡的综合作用——城市和运营商匹配把命中范围锁死负载分避免全量导到同一个节点。5.3 三个正在困扰你的典型排障案例任何系统上线后都会有坑这里是我在上线最关键的三个月内踩过的三个“真坑”把你的排查路径写出来供你少走弯路。第一个坑是某大企业专线出口导致调度偏差。广州分公司的用户走上海总部专线出口GSLB查到的用户IP归属地是上海导致调度节点全部落在上海。这个问题的根源是IP归属地只能反映出口节点的位置无法反映终端用户的位置。这种场景下唯一能补救的是基于用户拨测数据做二次修正——拨测显示上海节点到该客户端的网络时延异常高就把该IP段加入一个手动覆盖名单强制指定到广州节点。第二个坑是某省份IP段被清退重新分配。一个原本属于湖南的/16段被运营商回收重新分配给了湖北某市离线库还在按旧数据把这个段标记为湖南。结果就是湖北的用户被导到湖南节点用户感知到明显卡顿。发现这个问题的方式是监控跨省调度比例的环比异常波动某天的跨省调度比例突然上升了0.8个百分点。解决的办法是把该IP段加到临时修正名单同时触发离线库增量更新。从发现到修复用了不到40分钟但如果没有日志和监控这类问题很容易被掩盖成“用户网络差”而白白背锅。第三个坑是离线库对某个城市的标记长期错误。一个近似IP段在离线库里被标记为广西南宁实际归属为广东茂名。因为南宁在CDN节点部署上通常属于华南大区广州和南宁的节点体系完全不同调度结果相差几百公里。我们是在一次对比拨测时发现的同一IP段的用户在广东茂名拨测时时延异常高追溯日志才定位到是归属地库数据错误。这种数据源错误是常态所以建议定期我这里是每月随机抽取一批IP段用拨测时延做交叉校验发现偏差就反馈给数据源服务商。这三次排障都有一个共同点如果GSLB没有把归属地查询结果和候选集日志完整记录下来排查周期会成倍拉长。日志字段里必须包含“做决定时看到了什么”而不是只记录“最后做了什么决定”。6. 边界条件与下一步演进思路这次改造解决了不少问题但远不是终点。有些边界情况在最初设计时容易忽略这里摊开来聊。6.1 IPv6地址的归属地查询要提前准备好IPv6的地址空间巨大离线库对IPv6的覆盖和精度普遍不如IPv4很多库对IPv6只输出国家或大区级别。要想在IPv6场景下获得省级和城市级的归属地精度需要单独采购支持IPv6的商业库或者在IPv6请求时额外依赖在线API。现在新接入的用户中IPv6的占比在逐步提高尤其是在移动网络端。如果GSLB对IPv6只能查到国家级别那么调度精度会大打折扣。建议现在的改造就把IPv6的查询路径设计好而不是等IPv6流量占比已经很高了再回头补。6.2 私有地址、保留地址和黑洞IP的兜底DNS解析请求理论上不会携带私有IP地址但实际运行中总有一些异常流量包括来自内网段、保留段、以及运营商NAT网关地址。这些IP在归属地库中要么查不到要么返回的是一个错误的默认值。我的兜底策略是给GSLB维护一张黑名单包含RFC 1918私有地址段、保留地址段、测试地址段一旦命中就直接跳到传统调度逻辑不参与归属地相关查询和打分。这样可以防止异常IP让调度决策产生“幻觉”。6.3 从静态归属地走向动态网络质量感知IP归属地查询在GSLB层的定位是“用更精准的位置信息替代猜”但位置信息不等于网络质量信息。同一个省份、同一个运营商的用户在不同时间段访问同一个节点网络质量可能截然不同。下一步的演进方向是在归属地调度之上叠加实时网络探测数据GSLB定期对核心节点做全网质量探测把探测结果写入调度决策的权重中让位置信息和质量信息共同决定最终节点。我的经验是位置信息解决的是“应该选谁”实时质量信息解决的是“现在谁比谁更值得选”两者是互补关系缺一不可。6.4 调度效果的可视化与持续运营最后分享一个运营层面的建议调度效果不是上线就一劳永逸的需要持续监控和调整。我在改造完成后搭建了一个简单的调度看板包含跨省调度比例、归属地库更新状态、在线API调用量、熔断次数四个核心面板。看板没有做得很复杂但每次发版后都能快速看到调度逻辑是否有异常。有一次凌晨发版后跨省调度比例突然从3%涨到15%看面板定位到是候选集过滤逻辑里多写了一个不等于条件把同省同运营商的节点全部过滤掉了。如果当时没有这个监控面板这个问题可能要等用户投诉才暴露出来那就晚了。CDN调度优化这件事永远是在“精确”和“成本”之间做平衡。IP归属地查询不是银弹但它能把GSLB从“盲猜用户位置”推进到“大概知道用户在哪再结合节点质量做判断”。这次改造结束后跨省流量占比明显下降用户访问速度提升背后是调度系统从粗放走向精细化的一个缩影。如果你们也在被DNS调度失准困扰不妨从在GSLB层加一个归属地查询模块开始。