利用dns解析來實現網站的負載均衡

當網站的訪問量大了就會考慮負載均衡，這也是每個架構師的基本功了，其基本地位就至關於相聲裏的說學逗唱，活好很差就看這個了 :)

傳統的負載均衡思路是單點的，無論你是硬件的仍是軟件的基本都是這樣的原理

對於通常的需求來講，這樣的架構基本就能夠解決問題了。並且維護起來也相對簡單。嗯，大多數公司也都是這麼幹的。

傳統思路的侷限性

就如同上圖所示，傳統思路也存在很是明顯的侷限性。也就是網站的響應速度很大程度上侷限於負載均衡節點的能力，並且一旦負載均衡節點自己掛掉的話，整個網站就徹底癱瘓了。後端的服務能夠水平擴展，可是對於單個節點來講就算你再增大機器的配置也是有極限的，並且這也不符合互聯網技術的發展規律。

CDN是怎麼作的

做爲互聯網上承載大部分流量的一大基礎設施，CDN對負載分流的解決思路很具備啓發性

從上圖能夠看到，用戶的訪問被分流了，全部的請求再也不是彙集到一個節點上，而是被分擔在了各個合適的節點上，這樣即便存在單點故障，也僅僅只會影響到一部分用戶，何況咱們還可使用其餘手段作故障轉移。

一樣的作法也能夠借鑑到傳統的BS架構中，咱們也能夠把用戶的請求直接分流到不一樣的服務器上，而沒必要通過一個統一的節點中轉。這個分流是經過什麼作到的呢？答案就是 DNS!

你知道DNS是怎麼工做的嗎？

大部分人可能每天都用着DNS殊不知道它的基本原理，你可能知道咱們訪問互聯網須要查詢dns服務器，就是下面的這個玩意

咱們只須要問它域名所對應的ip地址就好了。但事情真的這麼簡單嗎？它是怎麼知道這個域名所對應的ip地址呢？

其實dns系統是一個典型的樹狀架構，上圖所示的dns服務器其實應該叫dns緩存查詢服務器，它是爲了減輕互聯網上dns查詢的負載所設計的。若是你的請求沒有命中緩存，那麼這個緩存服務器就會本身進行一次標準查詢，而後再把結果緩存起來，簡單來講就是從根服務器開始一級一級的問。咱們之前常常談到根服務器的重要性其實就體如今這裏了，它保留了對全部域名的起始解釋權

神奇的解釋權機制(SOA)

上面講到根服務器擁有一切域名的起始解釋權，可是若是你去問根服務器它是不會直接告訴你最終答案的。由於若是它要存儲全部的記錄，那它也太累了，這個負載和開銷是驚人的。那它會告訴你什麼呢？它會告訴你應該去問誰，也就是它受權下一級服務器來解答你的問題。擬人化這個過程

1. 我: root, root 告訴我， segmentfault.com 怎麼走？
2. root: 呵呵，你能夠去問.com的dns服務器，地址是xxxxxx
3. 我: .com, .com 告訴我，segmentfault.com 怎麼走？
4. .com: 呵呵，你能夠去問segmentfault.com的dns服務器(dnspod之類的)，地址是xxxxxx
5. 我: dnspod, dnspod 告訴我，segmentfault.com 怎麼走？
6. dnspod: 拿着 xxxxxx，走你

DNS負載均衡的基本原理

瞭解了上述過程，咱們獲得兩個基本結論

1. dns系統自己是一個分佈式的網絡，它是相對可靠的，起碼比你網站自己可靠的多
2. 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. AWS Route 53
2. NSONE
3. Dyn
4. dnspod

其中1和4是咱們已經在使用的，效果比較理想。

總結

其實DNS能夠玩的花樣遠不止這些，還能夠作故障轉移，也能夠按地區解析等等。域名從互聯網誕生之初就開始存在了，可是對它的研究以及衍生出來的使用方法纔剛剛開始發掘，隨着你們對互聯網利用的提高，這類技術確定會愈來愈多。