多业务线下，路由优化负责七层流量在服务实例间的精细分配、重试与限流，DNS调度负责用户到机房、地域、运营商入口的第一跳选择，二者以“就近接入 + 精细分流”分工，缺一不可。
为什么多业务线必须把路由优化和DNS调度拆开看
单一业务线时，一个域名、一组后端，DNS解析到固定IP，剩下的交给网关，多业务线部署后，不同业务可能分布在不同机房、不同集群、不同公有云账号，甚至同一域名下多个业务共用一个入口，此时再把DNS和路由混在一起，就会出现“入口选错，后面怎么调都浪费”的情况。
- 交易业务对延迟敏感，推荐走同城同运营商的入口，业务对带宽敏感，需要按地域缓存,DNS调度更粗。
- 大数据离线业务不需要实时切换,路由层做队列和重试即可。
分工本质很直白：DNS解决“用户先去哪个入口”，路由解决“进入入口后怎么走到实例”，前者适合分钟级调整,后者适合秒级甚至毫秒级调整。
多业务线DNS调度怎么分工：先解决“用户去哪台机房”
这是多业务线接入层优化的第一道开关，DNS调度的粒度通常按地域、运营商、可用区、业务线来划分,而不是按接口或服务。
- 地域分流：华南用户解析到广州节点,华北用户解析到北京节点。
- 运营商分流：移动、联通、电信分别返回对应线路入口,避免跨网访问。
- 业务线分流：订单业务解析到主链路CNAME，推荐业务解析到边缘CNAME,互不拖累。
- 权重与健康检查：某机房故障时,DNS按健康检查结果把解析权重调走。
具体操作路径：
- 在云解析控制台为每个业务线配置独立CNAME。
- 设置TTL，日常可维持60秒到300秒,大促前临时调低。
- 对移动、联通、电信分别配置A记录或CNAME线路。
- 使用
dig +trace确认解析路径是否按预期走了分线路记录。
行业共识认为，DNS调度适合粗粒度、低频率的流量分配，不适合感知连接状态或按接口路径分流，如果业务需要按购物车、下单、支付做不同路由,那就进入了路由优化的职责范围。
电商大促场景下路由优化与DNS调度如何配合
大促期间，流量脉冲和写读比例变化明显，单靠DNS调度只是把用户送到入口,入口后面的分流必须靠路由优化。
- 大促前：DNS把图片、商品详情等静态资源调度到离用户更近的边缘节点,减少核心机房压力。
- 大促中：路由层把下单、支付等写请求指向主集群，把库存查询、推荐等读请求按权重分流到缓存集群。
- 大促后期：DNS逐步切回默认线路,路由层恢复常规权重。
一个典型配合流程：
- 在Nginx的
upstream中为订单业务配置主备两组实例。 - 设置
max_fails=2 fail_timeout=10s,连续两次失败后暂时摘除。 - DNS侧将TTL降到60秒以内,入口故障时能较快切换。
- 路由层使用
least_conn算法,让连接数少的实例承接更多流量。
这套配合的核心是：DNS管入口切换，路由管实例摘除，不要用DNS去处理实例级故障，否则等TTL生效时,交易可能已经超时。
路由优化在多业务线中的落地位置
路由优化不是只停留在Nginx，多业务线下，它分散在入口网关、服务网格、注册中心、消息队列等多个位置。
- 入口网关：按
Host和Path把请求转发到不同业务线。 - Sidecar/服务网格：按版本、标签、权重做灰度,适合多业务线共用一个集群。
- 注册中心：通过健康检查、权重、元数据影响实例被调用的概率。
- 配置中心：动态调整路由规则,避免频繁重启。
以Nginx为例,多业务线常用配置结构：
map $http_host $biz {
default default_upstream;
order.example.com order_upstream;
rec.example.com rec_upstream;
}
upstream order_upstream {
least_conn;
server 10.0.1.10:8080 weight=5 max_fails=2 fail_timeout=10s;
server 10.0.1.11:8080 weight=3 max_fails=2 fail_timeout=10s;
keepalive 32;
}
这个配置验证了三个事实：业务线按域名拆分、实例按权重接收流量、故障实例能被自动摘除，业内专家指出，多业务线网关层的路由优化，优先解决连接复用和故障摘除,而不是堆叠算法。
北京多业务线路由优化方案为什么先看运营商冷热数据
北京地域的运营商线路质量差异，在多业务线场景下会被放大，如果默认走BGP多线，成本高，而且不一定比按运营商静态分流更稳定，北京多业务线路由优化方案的第一步，是收集运营商到机房的冷热数据,而不是直接调路由权重。
- 使用
mtr --report 目标IP按联通、移动、电信分别测试。 - 使用
traceroute -A查看ASN路径,确认是否绕行。 - 把RTT和丢包数据按业务线记录,生成线路优先级表。
北京机房与天津、河北链路较近，常见做法是：DNS按城市解析到北京主节点，路由层对超时请求做异地兜底，把请求转发到天津备节点，这个兜底由路由层完成,不依赖DNS二次解析。
DNS调度成本高吗：按QPS和线路数拆账
很多团队在评估多业务线改造时，会先问“DNS调度成本高吗”,答案要拆成两部分看。
- 按解析QPS计费的云解析，中小规模多业务线的月开销通常在可控范围内。
- 成本上升主要来自多线路记录数、健康检查频率、Anycast IP数量。
- 如果自建BIND,服务器和运维人力成本会随业务线数量线性增加。
| 方案 | 主要成本项 | 适合场景 |
|---|---|---|
| 云解析按线路 | 解析QPS、线路记录数 | 多业务线快速上线 |
| 自建BIND | 服务器、带宽、专人维护 | 有专线互联且要求数据私有 |
| 混合方案 | 云解析入口+自建内部解析 | 入口分流+内网自定义调度 |
降本的常规路径：合并低流量业务线的解析，使用CNAME复用主域名，减少分省记录，不要为每个小业务单独开一套独立解析套餐,那样线路数和健康检查任务会迅速膨胀。
路由优化和DNS调度哪个先执行：一个请求的完整顺序
理解执行顺序，能避免把两个层级的配置写错,一个标准请求从用户到后端实例的顺序：
- 用户输入域名。
- 递归DNS向权威DNS查询。
- 权威DNS按用户来源线路，返回入口IP。
- 用户与入口网关建立TCP或TLS连接。
- 网关根据
Host、Path、Header把请求转发到对应业务线的upstream。 - 路由层根据权重、连接数、实例健康状态选择具体实例。
所以先DNS后路由，但两者不是替代关系，如果用户本地缓存了DNS结果，DNS调度不参与,路由优化仍然要保证请求被正确转发。
实操清单：多业务线下如何验证分工是否合理
验证环节比配置环节更容易发现问题,以下命令可以直接套用：
dig @223.5.5.5 your-domain.com +short：看实际入口IP是否按线路返回。curl -sv --resolve your-domain.com:443:入口IP https://your-domain.com/：绕过DNS直接验证路由。curl -sv -H "Host: order.example.com" 入口IP/health：检查业务线Host分流。- 在
upstream配置里观察status和check interval,确认实例健康状态。 - 记录DNS解析耗时、TCP建连耗时、网关转发耗时、后端响应耗时,定位慢在哪个环节。
多业务线接入层优化的关键，是把DNS调度和路由优化当成两个独立但配合的层级，DNS负责把用户送到正确入口，路由负责把请求送到正确实例，任何一方越权都会让故障半径扩大。
多业务线路由优化与DNS调度分工常见问题
路由优化和DNS调度哪个先执行？
先执行DNS调度，再执行路由优化，用户先通过DNS拿到入口IP，连接建立后路由层才按业务线、权重、健康状态选择后端实例，若DNS结果被缓存，入口固定,路由层仍会执行自己的策略。
多业务线DNS调度怎么分工才合理？
按业务实时性拆分，交易类业务线使用更频繁的健康检查和更低的TTL，内容类业务线使用更粗的地域分流和较长TTL，每个业务线使用独立CNAME,避免一个业务线的解析故障影响其他业务。
DNS调度成本高吗？
多数情况下DNS调度成本不高，按解析QPS计费时，中小规模多业务线开销有限，成本主要来自多线路记录数、健康检查频率和Anycast IP数量,合并低流量业务线的解析记录可以降低费用。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/641189.html
