云上DNS与流量调度实战：域名解析、智能路由与故障转移
去年一个客户，做了跨可用区容灾，负载均衡配了跨AZ，数据库跨AZ同步，自认为万无一失。结果一次区域性网络故障，业务还是挂了。
排查发现，用户访问的域名解析到的是固定IP，而那个IP正好在故障可用区。负载均衡能跨AZ，但DNS已经把用户引到了故障区，连LB都到不了。
这是DNS最容易被忽视的角色：它是流量入口的第一道开关。LB和容灾都在它后面。
今天聊聊云上DNS与流量调度。不是那种“域名解析原理”的入门课，而是帮你理清楚：怎么用DNS做智能路由？怎么做故障转移？TTL设多少合适？怎么用DNS配合蓝绿发布？
01 DNS不只是域名转IP
很多人对DNS的理解停留在“把www.example.com转成IP”。这是DNS最基础的功能。现代DNS服务已经远远超出这个范围。
基础能力：A记录、AAAA记录、CNAME、MX、TXT
进阶能力：
加权轮询：按权重分配流量，适合蓝绿、金丝雀
地理位置解析：不同地域用户解析到不同IP，实现就近接入
运营商线路：电信、联通、移动分别解析
故障转移：健康检查 + 自动切备用IP
客户只配了A记录，没有健康检查，没有故障转移。区域故障时，DNS还在返回故障区的IP。
反常识观点：DNS是容灾的第一道防线，在LB和AZ之前。
02 智能解析：让用户就近访问
如果你的用户分布在全国或全球，单一IP无法保证所有用户的访问质量。智能解析可以根据用户来源，返回最优IP。
按地域解析
华北用户 → 北京机房IP
华东用户 → 上海机房IP
海外用户 → 海外CDN或云节点
按运营商解析
电信用户 → 电信线路IP
联通用户 → 联通线路IP
移动用户 → 移动线路IP
应用场景：
多地域部署的应用就近接入
合规要求数据必须在特定地域
降低成本，避免跨地域流量费
某跨境电商，用户遍布欧美。用智能解析把欧洲用户引到法兰克福区域，美国用户引到弗吉尼亚区域，延迟从200ms降到30ms。
03 TTL：缓存时长不是越长越好
TTL（Time To Live）告诉解析器结果能缓存多久。
TTL误区：
设太大（如24小时）：故障时DNS切不动，用户还在用旧IP
设太小（如30秒）：DNS查询量暴增，可能触发限速，解析延迟增加
最佳实践：
核心域名（www、api）：TTL 60-300秒。故障时能快速切换，查询量可接受。
非核心域名（static、img）：TTL 600-3600秒。IP变更不频繁，大TTL提升性能。
故障转移备IP：TTL建议低于60秒。越短越能在故障时快速切过去。
变更前降TTL：计划做IP变更，提前一天把TTL降到60秒，变更完成再调高。
04 故障转移：DNS自动切备IP
DNS故障转移是容灾的第一层。
工作原理：
配置主IP和备用IP
DNS服务定期健康检查（HTTP、TCP、Ping）
主IP健康检查失败，自动返回备用IP
注意事项：
健康检查频率：建议30-60秒一次。太频繁可能误判，太慢故障转移不及时。
检测超时：3-5秒。根据业务特性调整。
故障转移不是瞬时的：DNS缓存、客户端缓存、浏览器缓存，都可能延迟生效。这也是TTL要设小的原因。
那家客户后来增加了DNS故障转移，主IP失效后自动切到备用IP，业务恢复从小时级降到分钟级。
05 配合蓝绿、金丝雀发布
DNS加权轮询是做流量切分的简单工具。
蓝绿发布场景：
蓝环境（当前版本）：权重90%
绿环境（新版本）：权重10%
逐步调高绿环境权重，直到100%
金丝雀场景：
1%用户切到新版本，观察没问题再逐步放大
对比LB的优势：
DNS层面切分，对应用透明，不需要LB额外配置
适合HTTP、TCP、UDP等所有协议
劣势：
切分粒度粗，按请求比例，不能按用户ID或Header
变更生效依赖DNS缓存，不如LB实时
06 一个真实案例
某公司做全局负载均衡，用DNS做跨地域容灾，配置了主备IP和健康检查。但主IP故障时，业务还是没切过去。
原因是健康检查用的是ICMP（Ping）。主IP的那台机器，网络通但服务挂了。Ping通了，健康检查认为正常，不切备IP。
改成HTTP健康检查，检测特定URL返回200。再次故障时，DNS很快切到备IP，业务恢复。
运维负责人说：“以前觉得健康检查只要配了就行，现在知道，配什么协议、检查什么内容，都影响结果。”
写在最后
DNS是流量入口的第一道开关。LB和容灾能力都在它后面。DNS配错了，后面的容灾再完善，用户也进不来。
那家客户的运维负责人后来总结：“以前觉得DNS就是域名商送的解析服务，现在知道，它是我们流量治理体系的第一层。”
TTL、智能解析、故障转移、健康检查，每配对一个，用户的访问就稳一分。
你的DNS，只是做了解析，还是参与了容灾？
