DNS负载均衡实战：我把电商大促的宕机时间从47分钟干到0的配置全记录

“DNS轮询就是垃圾”——这是我三年前的错误认知

2019年双十一，我在某跨境电商平台负责运维，当时天真地以为DNS轮询就能搞定流量高峰。结果大促开始47分钟后，主服务器直接宕机，连带整个CDN雪崩。事后分析才发现，简单的DNS轮询根本不知道后端服务器死活，所有请求还在往已经挂掉的节点上怼。

那次事故后我彻底重新认识了DNS负载均衡。现在给物流公司WMS系统做架构升级时，我用了完全不同的方案。以下是真实配置代码（基于AWS Route 53）：

# 健康检查配置 - 每30秒检测一次HTTP 200状态
resource "aws_route53_health_check" "api_healthcheck" {
  fqdn              = "api.example.com"
  port              = 443
  type              = "HTTPS"
  resource_path     = "/health"
  failure_threshold = 3  # 连续3次失败才标记为不健康
  request_interval  = 30 # 30秒间隔
  
  # 必须设置SNI否则TLS握手会失败
  enable_sni        = true
  regions           = ["us-west-1", "eu-west-1"]
}

这个配置的关键在于failure_threshold和request_interval的平衡。太敏感会导致误判（比如网络抖动），太迟钝又失去意义。经过压测，3次失败+30秒间隔的组合在假阳性和响应速度之间取得了最佳平衡。

地理路由让日本用户请求不再绕道新加坡

物流公司的日本分部一直抱怨系统延迟高，原来DNS默认把请求都解析到新加坡机房。用GeoDNS改造后，延迟直接从380ms降到92ms。Route 53的配置比想象中简单：

# 地理路由策略 - 日本用户定向到东京机房
resource "aws_route53_record" "jp_record" {
  zone_id = aws_route53_zone.main.zone_id
  name    = "api.example.com"
  type    = "A"
  
  # 日本地区专属设置
  geolocation_routing_policy {
    country = "JP"
  }
  set_identifier = "tokyo"
  alias {
    name                   = "alb-jp-tokyo-123456789.ap-northeast-1.elb.amazonaws.com"
    zone_id                = "Z14GRHDCWA56QT"
    evaluate_target_health = true
  }
}

踩坑警告：千万别用CIDR块做地理匹配！我最初尝试用IP段匹配，结果AWS的IP库更新不及时，导致部分用户被错误路由。直接使用国家代码反而更可靠。

权重分流让我优雅应对服务器升级

上周三凌晨做服务器迁移时，我用权重分配实现了无缝过渡。旧集群权重从100逐步降到0，新集群从0升到100，整个过程零停机。监控显示请求成功率始终保持在99.99%以上：

对应的Terraform配置片段：

# 权重分流配置 - 新旧集群过渡
resource "aws_route53_record" "weighted_record" {
  zone_id = aws_route53_zone.main.zone_id
  name    = "api.example.com"
  type    = "A"
  ttl     = 60  # 故意设短TTL方便快速切换
  
  weighted_routing_policy {
    weight = var.cluster_weight # 通过变量动态控制
  }
  set_identifier = "legacy-cluster"
  records        = ["10.0.1.1"]
}

TTL设置是个技术活——30秒与300秒的天壤之别

DNS缓存是把双刃剑。给视频直播平台做优化时，我把TTL从默认的300秒改成30秒，故障转移时间缩短了87%。但代价是DNS查询量暴涨5倍，差点被Cloudflare收费升级。

最终方案是按业务类型区分TTL：

• 支付API：30秒（快速故障转移）
• 商品图片CDN：3600秒（减少查询开销）
• 用户会话服务：300秒（平衡点）

实测发现Python的DNS缓存会无视TTL，必须强制刷新：

import dns.resolver

def resolve_with_ttl(domain):
    """强制遵守TTL的DNS查询"""
    resolver = dns.resolver.Resolver()
    resolver.cache = dns.resolver.LRUCache()  # 使用LRU缓存而非默认缓存
    answer = resolver.resolve(domain)
    return answer.rrset[0].address

当DNS遇上Anycast：给全球游戏服务器加速的邪道玩法

给某FPS游戏做全球部署时，传统DNS方案在玩家匹配场景下表现糟糕。最终我用Anycast+DNS的混合方案，将亚洲玩家的平均延迟从142ms压到64ms。核心配置如下：

# Anycast BGP通告配置
router bgp 65530
 no synchronization
 bgp log-neighbor-changes
 network 203.0.113.0/24
 neighbor 192.0.2.1 remote-as 64512
 neighbor 192.0.2.1 route-map ANYCAST_OUT out
!
route-map ANYCAST_OUT permit 10
 set community 64512:666
 set local-preference 200

配合DNS的延迟路由策略：

# 延迟路由配置
resource "aws_route53_record" "latency_record" {
  zone_id = aws_route53_zone.main.zone_id
  name    = "game.example.com"
  type    = "A"
  
  latency_routing_policy {
    region = "ap-southeast-1"
  }
  set_identifier = "singapore"
  alias {
    name    = "anycast-sgp-123.elb.amazonaws.com"
    zone_id = "Z35SXDOTRQ7X7K"
  }
}

这个方案最骚的地方在于：当Anycast节点过载时，DNS会自动把流量切到其他区域，形成双重负载均衡。不过调试BGP的时候我差点把东京机房搞下线三次，不建议网络小白尝试。

监控DNS？99%的人只做了半吊子检测

别以为ping个域名就叫监控了！我在Kubernetes集群里部署的完整监控方案包括：

# Prometheus黑盒监控配置
- module: dns
  prober: dns
  dns:
    preferred_ip_protocol: "ip4"
    query_name: "api.example.com"
    query_type: "A"
    valid_rcodes:
      - NOERROR
    validate_answer_rrs:
      fail_if_none_matches_regexp:
        - "10.0..*"  # 必须返回内网IP段
    validate_authority_rrs:
      fail_if_not_matches_regexp:
        - "ns-d+.awsdns-d+.org"  # 必须使用AWS权威DNS

配合Grafana看板监控这些关键指标：

• DNS解析延迟百分位（P99>200ms就报警）
• TTL违反率（客户端缓存时间超过设定TTL的比例）
• 地理路由错误率（日本用户被解析到美国节点的比例）

去年圣诞节大促时，这个监控系统提前15分钟发现了DNS查询量异常增长，及时扩容DNS服务器避免了一场灾难。

# 这是当时灾难性的DNS配置示例
www.example.com.  300 IN  A   192.0.2.1
www.example.com.  300 IN  A   192.0.2.2
www.example.com.  300 IN  A   192.0.2.3

health_check {
    type = "https"
    port = 443
    path = "/api/health"
    interval = 30s
    timeout = 5s
    unhealthy_threshold = 2
    healthy_threshold = 3
    expected_codes = [200, 302]
}

# 优化前
Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency    85.12ms   26.33ms 342.56ms   85.32%
    Req/Sec     1.20k   181.23     1.45k    86.33%

# 优化后
Thread Stats   Avg      Stdev     Max   +/- Stdev
    Latency    53.67ms   18.92ms 298.43ms   89.01%
    Req/Sec     1.81k   202.15     2.12k    91.07%

clusters:
- name: hybrid_cluster
  connect_timeout: 1s
  type: LOGICAL_DNS
  dns_lookup_family: V4_ONLY
  load_assignment:
    cluster_name: hybrid_cluster
    endpoints:
    - lb_endpoints:
      - endpoint:
          address:
            socket_address:
              address: api.aws.example.com
              port_value: 443
      - endpoint:
          address:
            socket_address:
              address: api.aliyun.example.com
              port_value: 443

// 错误配置示例（千万别学）：
{
  "HealthCheckConfig": {
    "Type": "TCP",
    "Port": 8080,
    "RequestInterval": 30,
    "FailureThreshold": 3
  },
  "SecurityGroupRules": [
    {
      "PortRange": "80",
      "TimePolicy": "AlwaysOn"
    },
    {
      "PortRange": "8080", 
      "TimePolicy": "WorkingHours" // 就是这个坑货！
    }
  ]
}

def check_dns_mixed_environment(domain):
    import dns.resolver
    answers = dns.resolver.resolve(domain, 'ANY')
    has_ipv4 = any(r.rdtype == 1 for r in answers)
    has_ipv6 = any(r.rdtype == 28 for r in answers)
    
    if has_ipv4 and has_ipv6:
        print("⚠️ 双栈环境需检查客户端IPv6可达性")
        if "aws" in domain:
            print("建议启用Route53的'Evaluate Target Health'功能")
    elif has_ipv4:
        print("✅ 纯IPv4环境")
    else:
        print(" 纯IPv6环境需特殊处理")