以cdn系統為例（其他業務系統大多采用類似的政策），來說明一下多地域部署服務如何實作使用者通路請求排程的。
step 1:用戶端（假設ip位址為ip1）向local dns（假設ip位址為ip2）發出域名解析請求（假設請求的域名為www.taobao.com）
step 2:local dns代理用戶端向權威伺服器發起域名解析請求
step 3：權威伺服器根據域名(www.taobao.com)和ip2（對應的地域和isp）進行排程并傳回對應的解析結果。
step 4: 用戶端根據排程傳回的ip發起業務通路請求。
從上面的排程過程可以看出，業務系統會根據用戶端的local dns ip來判斷客戶所處地域和營運商，并根據該地域和營運商來排程到就近的服務節點。
可以看出，當客戶的local dns與客戶的地域和營運商不比對時，此時按照local dns來排程就會出現排程不精确的問題。
下面看幾個來自客戶的回報（探測結果來自alicdn昆侖探測工具）：
探測的用戶端ip和local dns ip以及對應的地域，營運商如下所示：
用戶端ip
220.249.84.**
用戶端歸屬
武漢聯通
local dns ip
183.61.13.**
222.73.134.**
local dns 歸屬
珠海電信
上海電信
很容易看出，local dns地域和營運商與用戶端都不比對，此時按照local dns ip排程會對使用者體驗造成非常大的影響（國内跨營運商的通路延遲和帶寬都存在非常大的問題，相信大家有深刻體驗）。
根據我們的經驗，影響的用戶端占比在3%-7%之間。
無線場景下主要由于以下兩個方面因素導緻：
（1）國内三大營運商local dns布點不足且不均勻，大量流量集中在2000個以内的local dns上，大的local dns對應的流量超過5gb
（2）很多手機（尤其是山寨機）local dns配置不準确
如果擴充到全網（含有線通路請求），還需要考慮一個因素：
（3）公共dns（如google 8.8.8.8，阿裡的223.5.5.5,223.6.6.6）導緻排程系統無法識别local dns的具體位置。
業界目前常見的解決思路都是通過擷取用戶端的ip來精确定位用戶端地域和營運商，實作上，有三種方式：
（1）httpdns
用戶端通過http請求向httpdns伺服器發出域名解析請求，此時httpdns伺服器可以拿到用戶端的精确ip，并基于用戶端ip進行排程。
（2）edns client subnet
通過dns包中加入用戶端ip資訊，使得dns排程系統可以拿到用戶端ip并進行排程。
（3）http 302跳轉
當排程系統給出的排程結果不準确時，業務伺服器仍然可以根據用戶端ip來判斷排程是否合理，并且在必要時通過302跳轉來實作重定向進而實作精确排程。
三種方式的優缺點對比如下：
用戶端修改
local dns修改
權威dns修改
系統開銷
使用範圍
httpdns
有
無
低
最廣
edns client subnet
需支援edns client subnet
中等
http 302
有(需支援302跳轉)
高
最差