智能DNS解析：地域与运营商权重策略

智能DNS解析，说白了就是让DNS学会“看人下菜碟”。

你的用户在北京，就给他解析到北京机房的IP。用户在上海，就指到上海节点。用户用的是电信，就给他电信线路的地址。这就是多活部署最基础、也最关键的流量入口策略。

我在早期做多活项目时，犯过一个低级错误。当时只做了地域策略，完全没考虑运营商。结果北方联通用户全部涌入电信机房，延迟直接飙到200ms以上……嗯，那次被运维同事念叨了整整一周。

地域权重策略

地域策略，依据的是用户IP的地理位置。DNS服务商会维护一份IP地理信息库，查询到你的用户来自哪个城市、哪个省份，然后返回对应的后端IP。

基本配置模型

常见的做法是按区域划分：

• 华北区域：北京机房（权重70%）、天津机房（权重30%）
• 华东区域：上海机房（权重50%）、杭州机房（权重50%）
• 华南区域：广州机房（权重60%）、深圳机房（权重40%）

权重的作用是什么？

举个例子。华北区域北京机房配置更强大，我们可以给它70%的流量，天津机房只承担30%。这样既能利用好硬件资源，又不会让某个机房过载。

运营商权重策略

在国内，网络环境比较特殊。电信、联通、移动三家运营商之间的互联带宽有限，跨运营商的延迟通常是同运营商的3-5倍。

所以，你必须针对每个运营商做独立的权重分配。

运营商流量分配逻辑

运营商	主节点	主权重	备用节点	备用权重
电信	电信机房A	80%	BGP机房B	20%
联通	联通机房C	70%	BGP机房D	30%
移动	移动机房E	90%	BGP机房F	10%

为什么移动只给BGP机房10%？因为移动用户量庞大，但QoS限制严格，最好尽量压在移动自有机房中。我遇到过一家游戏公司，移动用户被解析到BGP机房后，经常出现丢包率超过5%的情况，后来不得不重新调整权重。

地域+运营商的组合策略

只做地域或只做运营商，都不够完善。实际生产环境必须组合使用。

组合策略的处理流程是这样的：

1. 接收用户的DNS查询请求
2. 解析用户源IP，获取地域属性（例如：广东省）
3. 解析用户源IP，获取运营商属性（例如：电信）
4. 查询策略表：广东省-电信 → 广州电信机房（权重80%）、深圳电信机房（权重20%）
5. 根据权重，随机选择一个IP返回

# 伪代码：组合策略匹配逻辑
def resolve_dns(user_ip):
    region = get_region(user_ip)        # 广东
    isp = get_isp(user_ip)              # 电信
    
    # 查表：region + isp 精准匹配
    target = policy_table.get(f"{region}_{isp}")
    if target:
        return weight_select(target)
    
    # 降级：只匹配地域
    fallback = policy_table.get(f"{region}_default")
    if fallback:
        return weight_select(fallback)
    
    # 兜底：默认节点
    return default_nodes[0]

你想想看，如果没有组合策略，一个广东电信用户可能被解析到北京电信节点。虽然同运营商，但物理距离太远，延迟照样很高。组合策略就是为了同时锁定“最近的”和“最快的”。

权重调整的实践经验

权重不是一成不变的。你需要根据实时容量和故障情况动态调整。

• 扩容时：新机房权重从小调大，比如从5%逐步提升到30%，观察稳不稳定
• 故障时：立即将故障机房权重降为0%，让DNS TTL过期后自动切换
• 日常巡检：每季度重新评估各节点容量，调整权重比例

避坑指南

几个必须注意的点：

1. IP库的准确性：地域和运营商标识经常不准。我习惯每季度校验一次，拿真实用户IP抽样测试。
2. 权重的精度：不要设100%和0%。即使你认为某个节点永远不会故障，也要留一个备用节点，哪怕权重只有1%。
3. 多级降级：精准匹配失败后，必须有地域级降级、全国级兜底。否则用户可能直接“DNS解析失败”。
4. TTL与权重的配合：权重变更后，老用户的DNS缓存不会立刻更新。如果要紧急切换，除了改权重，还要手动调低TTL。