利用dns解析来实现网站的负载均衡
當網站的訪問量大了就會考慮負載均衡，這也是每一個架構師的基本功了，其基本地位就相當于相聲里的說學逗唱，活好不好就看這個了 :)
傳統的負載均衡思路是單點的，不管你是硬件的還是軟件的基本都是這樣的原理
對于一般的需求來說，這樣的架構基本就可以解決問題了。而且維護起來也相對簡單。嗯，大多數公司也都是這么干的。
傳統思路的局限性
就如同上圖所示，傳統思路也存在非常明顯的局限性。也就是網站的響應速度很大程度上局限于負載均衡節點的能力，而且一旦負載均衡節點本身掛掉的話，整個網站就完全癱瘓了。后端的服務可以水平擴展，但是對于單個節點來說就算你再增大機器的配置也是有極限的，而且這也不符合互聯網技術的發展規律。
CDN是怎么做的
作為互聯網上承載大部分流量的一大基礎設施，CDN對負載分流的解決思路很具有啟發性
從上圖可以看到，用戶的訪問被分流了，所有的請求不再是聚集到一個節點上，而是被分擔在了各個合適的節點上，這樣即使存在單點故障，也僅僅只會影響到一部分用戶，況且我們還可以使用其他手段做故障轉移。
同樣的做法也可以借鑒到傳統的BS架構中，我們也可以把用戶的請求直接分流到不同的服務器上，而不必經過一個統一的節點中轉。這個分流是通過什么做到的呢？答案就是?DNS!
你知道DNS是怎么工作的嗎？
大部分人可能天天都用著DNS卻不知道它的基本原理，你可能知道我們訪問互聯網需要查詢dns服務器，就是下面的這個玩意
我們只需要問它域名所對應的ip地址就行了。但事情真的這么簡單嗎？它是怎么知道這個域名所對應的ip地址呢？
其實dns系統是一個典型的樹狀架構，上圖所示的dns服務器其實應該叫dns緩存查詢服務器，它是為了減輕互聯網上dns查詢的負載所設計的。如果你的請求沒有命中緩存，那么這個緩存服務器就會自己進行一次標準查詢，然后再把結果緩存起來，簡單來說就是從根服務器開始一級一級的問。我們以前經常談到根服務器的重要性其實就體現在這里了，它保留了對所有域名的起始解釋權
神奇的解釋權機制(SOA)
上面講到根服務器擁有一切域名的起始解釋權，但是如果你去問根服務器它是不會直接告訴你最終答案的。因為如果它要存儲所有的記錄，那它也太累了，這個負載和開銷是驚人的。那它會告訴你什么呢？它會告訴你應該去問誰，也就是它授權下一級服務器來解答你的問題。擬人化這個過程
DNS負載均衡的基本原理
了解了上述過程，我們得到兩個基本結論
有了這兩條結論，剩下的事情就簡單了，我們只需要在最終解釋的查詢結果上做文章就可以了。簡單來說，就是將你的所有服務器地址，按照自己需求制定的頻次，返回給用戶。
以github.com為例，我們首先獲取它的SOA服務器（因為dns緩存查詢服務器會緩存結果，如果你直接去查詢域名，會每次返回一樣的結果），.com的dns域名服務器也是13臺，它們是[a-m].gtld-servers.net，我們隨便選一臺來找找github.com的SOA
OK，我們獲取了四個SOA服務器ns[1-4].p16.dynect.net，再隨便選一個來問問github.com對應的記錄吧，順便試幾次看看最終的ip地址會不會變化
我們這里查詢了兩次，注意ANSWER SECTION部分返回了兩個結果，一次是192.30.252.129，一次是192.30.252.128。
這就是利用dns實現了負載均衡，你的最終訪問會到達不同的ip地址。
有哪些DNS服務商支持負載均衡呢？
這是一種比較高級的服務，一般域名注冊商的dns服務器不會支持，目前我已知支持它的服務商有
其中1和4是我們已經在使用的，效果比較理想。
總結
其實DNS可以玩的花樣遠不止這些，還可以做故障轉移，也可以按地區解析等等。域名從互聯網誕生之初就開始存在了，但是對它的研究以及衍生出來的使用方法才剛剛開始發掘，隨著大家對互聯網利用的提升，這類技術肯定會越來越多。
總結
以上是生活随笔為你收集整理的利用dns解析来实现网站的负载均衡的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 微信扫一扫背后的秘密：基于运动估计的智能
- 下一篇： jQuery实现下拉列表移动 效果