第4章 DNS智能路由与全局负载均衡

第4章：DNS智能路由与全局负载均衡

各位同学，今天我们来聊聊多云架构里最核心的一个环节——DNS智能路由。说实话，很多人觉得DNS不就是个域名解析嘛，有什么好讲的？但我在生产环境里踩过的坑，十有八九都跟DNS策略配置不当有关。

你想想看，当你的业务部署在多个云上，用户访问时到底该去哪个机房？是离他最近的？还是负载最轻的？还是某个特定区域的？这就是我们今天要解决的问题。

4.1 基于延迟的DNS解析策略

延迟策略，说白了就是「谁快找谁」。用户发起DNS查询时，权威DNS服务器会根据用户IP所在位置，返回延迟最低的后端IP。

我记得有一次帮一家游戏公司做全球加速，他们用了AWS和阿里云双云部署。一开始配置的是简单的轮询，结果东南亚用户经常连到美西节点，延迟飙到300ms。后来改成延迟策略，东南亚用户自动解析到阿里云新加坡节点，延迟降到30ms以内。

核心原理：DNS服务器维护一张延迟探测表，定期从全球探测点向各后端发起健康检查和延迟测量。查询时匹配用户来源区域，返回最优IP。

配置示例（以AWS Route 53为例）：

# 延迟路由策略配置
Resource "aws_route53_record" "www" {
  zone_id = "Z123456"
  name    = "www.example.com"
  type    = "A"

  latency_routing_policy {
    region = "ap-southeast-1"  # 新加坡区域
  }
  set_identifier = "aws-singapore"
  ttl            = 60
  records        = ["1.2.3.4"]

  latency_routing_policy {
    region = "us-west-2"       # 美西区域
  }
  set_identifier = "aws-oregon"
  ttl            = 60
  records        = ["5.6.7.8"]
}

我的经验：TTL值别设太大。我习惯设60秒，这样故障切换时能快速生效。但也不要低于30秒，否则DNS查询量暴增，容易被上游DNS服务器限流。

4.2 基于地理位置的DNS解析策略

地理位置策略跟延迟策略有点像，但逻辑不同。它是根据用户IP所属的国家或地区，强制返回指定区域的IP。比如中国用户必须解析到国内节点，欧洲用户必须解析到法兰克福节点。

为什么要用地理位置策略？嗯，这里有两个场景：

合规要求：某些国家要求数据不出境，比如俄罗斯、印度
内容本地化：不同地区展示不同内容，比如电商的本地化价格

我曾经遇到过一个坑：某客户用了地理位置策略，但没配置默认兜底。结果有个来自南极科考站的用户，IP归属地识别失败，直接解析失败，业务挂了半天。后来我加了一条「默认指向美西节点」的兜底规则，问题解决。

注意：地理位置策略依赖IP地理库，但IP库更新不及时是常态。建议定期（每月）更新IP库，并配置兜底策略。

4.3 基于权重的DNS解析策略

权重策略，就是按比例分配流量。比如你有两个集群，A集群性能强，B集群是新上的。你可以设权重为7:3，让70%流量走A，30%走B。

这个策略在灰度发布时特别好用。我习惯的做法是：

新版本先上线到B集群，权重设成1:99
观察半小时，没问题就调到10:90
逐步增加到50:50，最后全量切换

配置示例（以Azure Traffic Manager为例）：

# 权重路由配置
az network traffic-manager endpoint create \
  --name "endpoint-primary" \
  --profile-name "my-profile" \
  --resource-group "my-rg" \
  --type "azureEndpoints" \
  --target-resource-id "/subscriptions/.../primary" \
  --weight 70

az network traffic-manager endpoint create \
  --name "endpoint-secondary" \
  --profile-name "my-profile" \
  --resource-group "my-rg" \
  --type "azureEndpoints" \
  --target-resource-id "/subscriptions/.../secondary" \
  --weight 30

关键点：权重总和不必是100。DNS服务器会按比例计算。比如权重设成2和1，效果就是66.7%和33.3%。

4.4 健康检查机制

讲完路由策略，咱们得聊聊健康检查。没有健康检查的智能路由，就像闭着眼睛开车——迟早出事。

健康检查的核心逻辑：DNS服务器定期向后端IP发送探测请求（HTTP/HTTPS/TCP），如果连续N次失败，就把该IP标记为「不健康」，不再返回给用户。

我见过最典型的翻车案例：某公司健康检查只检查了Web服务的80端口，但数据库挂了。结果DNS认为后端正常，用户请求进来后页面报500错误。嗯，这就是检查维度不够的问题。

我的建议是分层检查：

检查层级	检查内容	频率	超时时间
L4（网络层）	TCP端口连通性	每10秒	5秒
L7（应用层）	HTTP 200状态码	每30秒	10秒
业务层	自定义API返回「ok」	每60秒	15秒

避坑指南：我曾经把健康检查间隔设成5秒，结果后端扛不住探测流量，CPU被打满。后来改成10秒+3次失败阈值，既保证灵敏度，又不会误杀。

4.5 策略组合与实战建议

实际项目中，很少只用单一策略。我常用的组合拳是：

主策略：延迟优先，保证用户体验
兜底策略：地理位置，满足合规要求
灰度策略：权重，用于版本发布
安全网：健康检查，自动剔除故障节点

举个例子，我去年帮一个金融客户做多云架构，他们的配置是这样的：

# 伪代码示例
策略优先级：
1. 如果用户IP在中国 → 解析到阿里云（合规要求）
2. 如果用户IP在欧洲 → 解析到AWS法兰克福（延迟最优）
3. 其他地区 → 按延迟自动选择
4. 所有后端都配置健康检查，失败3次自动摘除
5. 权重策略用于灰度发布，平时不启用

最后提醒：DNS缓存是个大问题。就算你秒级切换，用户本地的DNS缓存可能还保留着旧IP。建议把TTL设小（60秒），同时在客户端做降级处理——比如前端加一层重试逻辑。

好了，这一章的内容就到这里。DNS智能路由看起来简单，但真正用好需要结合业务场景反复调优。下一章我们会讲故障检测与自动切换，到时候会用到今天讲的健康检查机制。

📚 课程目录