原理
采用全局負載均衡（GSLB）的前提是在不同地區設立了多個數據中心，並不是所有的互聯網服務都能做GSLB，前提是業務已經做了分布式部署的規划，無論用戶從哪個IDC訪問都能得到相同的結果，或者用戶基本不會出現跨區域流動訪問的情況，只會訪問就近IDC，或者有一套入口調度機制，能將用戶調度到所屬的節點。
現在很多CDN也都提供動態內容的加速，只不過這個加速只是數據傳輸上的優化，可以看做給你做了很多個轉發節點，最終業務處理壓力還是源站承擔。如果不具備分布式部署改造的條件，只是要解決遠距離客戶訪問慢問題，可以考慮CDN。
目前很多DNS服務商都提供了智能DNS服務，智能DNS可以通過多種負載均衡策略來將客戶端需要訪問的域名解析到不同的數據中心不同的線路上，比如通過各運營商分省IP地理信息數據來判斷用戶的就近性，並結合健康檢查策略（通常是發一個固定的http請求）來分配訪問量。
第三方智能DNS的不足在於通過公網健康檢查可能會受到運營商網絡擁塞的影響，目前國內域名服務商提供的服務目前還無法感知線路繁忙程度和后端服務器真實負載情況。除了使用智能DNS解析軟件或者雲服務，多數對可靠性和性能要求高的用戶都會使用硬件的全局負載均衡解決方案。全局負載均衡設備以通過更豐富的維度來判斷用戶就近性，形成就近性表，除了分地域IP數據庫外，還可以通過TTL、用戶訪問延時、服務器負載情況等來判斷。
下例的全局負載均衡解決方案中，域名服務商處將域名的NS記錄指向有智能DNS解析功能的GSLB設備，然后由GSLB設備來進行A記錄解析。如果在多地部署了GSLB設備，它們都應該添加到NS記錄中以保證高可用性，域名服務商處輪詢地返回GSLB地址或者一次性返回全部地址。GSLB設備會對自己所在的IDC后端服務器以及其他IDC公網IP進行健康檢查，健康檢查結果會通過自有協議在不同IDC的GSLB設備之間同步，最終根據全局負載均衡策略來選擇最優的地址解析給用戶。
解析的步驟示意如下圖：
- 用戶向本級配置的本地DNS服務器發出查詢請求，如果本地DNS服務器有該域名的緩存記錄，則返回給用戶，否則進行第2步；
- 本地DNS服務器進行遞歸查詢，最終會查詢到域名注冊商處的授權DNS服務器，這里可能有多個步驟，圖中只反映最后一步；
- 授權DNS服務器返回一條NS記錄給本地DNS服務器。根據授權DNS服務器上的不同設置，這條NS記錄可能是指向隨機一個GSLB設備的接口地址或者是所有GSLB設備的接口地址；
- 本地DNS服務器向其中一個GSLB地址發出域名查詢請求，如果請求超時會向其它地址發出查詢；
- GSLB設備選出最優解析結果，返回一條A記錄給本地DNS服務器。根據全局負載均衡策略設定的不同可能返回一個或多個VIP地址；
- 本地服務器將查詢結果通過一條A記錄返回給用戶，並將緩存這條記錄。
通過DNS解析報文中的TTL（Time To Live）字段可以控制客戶端緩存這條記錄的時間，在緩存時間內客戶端會使用舊的查詢結果，當緩存時間超時后才可能重新發出查詢，TTL值過大會導致故障發生時切換時間過長，TTL值太小會造成查詢頻繁，對設備和網絡的壓力增大。
局限性
請注意GSLB設備收到的DNS請求的源地址不是用戶的地址而是用戶所配置的本地DNS服務器地址，而GSLB的就近性探測是根據這個地址來判斷的，在我國大多數ADSL撥號上網用戶都能就近分配正確的數據中心，但是當用戶用戶通過4G移動網絡上網的情況下，客戶會一直使用歸屬地的DNS服務器，或這手動設定本地DNS而設置的DNS距離用戶較遠的情況，GSLB不能分配最佳的地址。這種情況很常見，國內有很多人使用google的公有dns或者opendns。
這種情況可以使用重定向來解決，SLB設備正式收到用戶發來的請求時，會再次查找就近性表，當發現用戶的最佳訪問節點非自己時，通過http 302重定向來再次引導用戶流量。