从一个真实痛点说起
故障定位思路
折腾GSLB时，我发现最麻烦的往往不是安装，而是配置。假设你在美西、德国和新加坡各有一组云服务器，用户从上海访问你的网站——有人秒开，有人要转三圈。你可能会想：能不能让用户自动连到最快的那个机房？
这其实就是GSLB（全局负载均衡）要做的事。而GSLB的核心能力之一，是延迟健康检查——它不仅要知道哪个机房“活着”，还要知道哪个机房“最快”。
相关阅读：此处可内链到“GSLB常见问题”专题。
什么是GSLB？一个聪明的DNS交警
容易忽略的细节
传统DNS只做一件事：把域名翻译成IP。比如你访问 example.com，DNS服务器会根据记录返回一个固定IP。但GSLB不一样，它会在DNS层面加入“智能调度”：
- 地理就近：上海用户 -> 新加坡机房（物理最近）
- 负载均衡：机房A负载过高 -> 分一部分流量到机房B
- 健康检查：机房宕机 -> 自动移除
但问题来了：地理最近不等于网络最快。新加坡到上海的延迟可能比美西到上海还高（因为国际路由绕路）。所以单纯靠“最近距离”调度并不靠谱。这时候就需要延迟健康检查来实时测量每个节点到用户的实际网络质量。
传统健康检查的局限
验证与回滚
最基本的健康检查只是验证服务是否存活：
- ICMP Ping：能ping通就算活着
- TCP Connect：端口能连上就算正常
- HTTP 200：访问某个URL返回200 OK
这种检查只能回答“死没死”，回答不了“快不快”。举个例子：
- 新加坡机房网络延迟300ms，但服务正常返回200
- 美西机房延迟150ms，同样返回200
传统健康检查会把两个节点都标记为“健康”，然后随机或按权重分发流量。用户可能被分到新加坡，体验就差了。延迟健康检查就是为了解决这个信息差：它把“响应时间”也纳入健康指标，让GSLB只把流量导向“活得好且跑得快”的节点。
延迟健康检查的工作原理
延迟健康检查通常通过以下两种方式测量延迟（RTT，往返时间）：
1. 主动探测
GSLB调度器会部署一组探测点（Probe Points），这些探测点分布在不同的地理区域（比如每个运营商、每个国家）。它们定期向被检查的目标IP发送探测请求，并记录响应时间。常见的探测方式：
- HTTP HEAD/GET：模拟真实用户请求，测量从发起请求到收到响应头的时间。
- ICMP Echo：类似ping，但更轻量（很多云厂商禁用ICMP，所以HTTP更可靠）。
- TCP SYN：只做三次握手的第一步，测量握手延迟。
假设你在北京、上海、广州各有一个探测点，它们会同时探测美西、德国、新加坡三个机房。最终每个机房会得到三个延迟值，GSLB取平均或最小值，然后根据用户来源匹配最近的探测点的数据。
2. 被动测量
除了主动探测，有些GSLB方案还会利用用户真实访问数据来修正延迟表。比如用户A从上海访问，实际TCP握手时长是120ms，这个数据会被上报，然后GSLB综合历史数据调整调度策略。被动测量能反映真实网络状况，但需要一定的流量样本，适合大型在线业务。
3. 组合策略
生产环境中通常主动探测为主 + 被动测量辅助。主动探测能快速发现故障，被动测量能平滑应对网络波动。比如：
- 每30秒主动探测一次，延迟超过500ms或丢包超过10%则标记为“亚健康”
- 从用户端收集到的实际延迟如果连续5分钟高于主动探测值30%，则触发调度切换
想继续深入：此处可内链到“GSLB优化清单”文章。
延迟健康检查面临的挑战——GSLB
看起来很简单，但实际落地时坑不少：
· 网络抖动 vs 真实故障
互联网延迟本身就有波动，一次突发丢包可能只是路由临时变化，如果立即把节点摘掉，会导致频繁切换，影响稳定性。解决方案：滑动窗口 + 阈值容忍。比如最近5次探测中3次超时才算故障，而不是一次就判死刑。
· 探测点数量与位置
如果只部署一个探测点（比如在AWS弗吉尼亚），那它测到的延迟只代表它自己到目标机房的延迟，不代表上海用户。因此需要尽可能多地部署探测点，覆盖用户主要来源地。很多云厂商会提供遍布全球的探测节点网络。
· 协议差异
ICMP延迟和HTTP延迟可能差很多。因为HTTP需要经过七层处理，而ICMP在IP层就返回了。建议使用与应用层协议一致的探测方式，比如你的服务是HTTPS，就用HTTPS探测，这样测得的数据更符合真实体验。
· 健康检查与DNS TTL的配合
GSLB的调度结果通过DNS返回，但DNS有TTL缓存。假设TTL设置为600秒，GSLB发现故障后立即切换，但用户本地DNS缓存还没过期，仍然会访问故障节点。所以延迟健康检查需要配合较低的TTL（比如30~60秒）才能快速生效。但TTL太低会增加DNS查询频率，需要权衡。
延伸阅读：此处可内链到“GSLB配置案例”相关文章。
配置延迟健康检查的最佳实践
验证与回滚
如果你正在使用云厂商的GSLB服务（比如AWS Route 53、Azure Traffic Manager、阿里云全局流量管理），或者自己搭建基于BIND + 健康检查脚本的方案，可以参考以下几点：
- 至少部署3个全球分布的探测点，覆盖主要用户区域。
- 设置合理的健康阈值：例如失败次数达到3次（连续3次超时）才标记为异常，恢复也需要连续3次成功。
- 区分“停止服务”和“性能劣化”：完全宕机直接摘除，延迟升高可以降权（比如把流量权重从100降到20）。
- 使用TCP SYN+HTTP组合：TCP SYN快速检测端口是否存活，HTTP检测应用层响应时间。
- 关闭ICMP探测（如果不受信任）：很多机房会限流或屏蔽ICMP，导致误判。
- 配合DNSSEC和CNAME flattening：减少DNS解析延迟本身。
- 监控探测点自身的健康：如果探测点挂了，所有数据都失效，需要冗余探测节点。
补充参考：此处可内链到“GSLB故障排查实例”。
常见误区
先看关键判断
- 误区一：延迟越低越好。不一定，如果某个节点延迟很低但CPU已经满载，服务响应反而变慢。延迟健康检查最好结合服务端负载指标（比如CPU、连接数）一起决策。
- 误区二：所有用户都用同一份延迟数据。不同运营商、不同地区的用户到同一机房的延迟差异巨大。GSLB需要根据用户来源IP（EDNS-Client-Subnet）匹配最近的探测点数据。
- 误区三：健康检查频率越高越好。频率过高会消耗探测节点带宽，且可能被目标机房的防护系统视为攻击。一般30~60秒一次足够。
总结
实际操作要点
GSLB延迟健康检查是构建高性能、高可用跨区域架构的关键技术。它解决了“知道机房没死但不知道慢不慢”的痛点，让流量自动流向用户感知最快的节点。理解它的原理后，你会发现它并不是一个黑盒——核心就是测量、比较、决策三段论。在实际部署时，合理配置探测参数、容忍抖动、配合低TTL，就能让全球用户都获得接近“本地访问”的体验。
如果你正在规划多云或全球业务，不妨先从延迟健康检查入手优化你的GSLB策略，这往往是投入产出比最高的环节。
延伸阅读