公司架構(gòu)師常常提起的DNS負(fù)載均衡是個什么鬼？
點擊關(guān)注公眾號，Java干貨及時送達(dá)??
傳統(tǒng)思路的局限性
CDN是怎么做的？
神奇的解釋權(quán)機制（SOA）
DNS負(fù)載均衡的基本原理
總結(jié)
當(dāng)網(wǎng)站的訪問量大了就會考慮負(fù)載均衡，這也是每一個架構(gòu)師的基本功了，其基本地位就相當(dāng)于相聲里的說學(xué)逗唱，活好不好就看這個了 :)
傳統(tǒng)的負(fù)載均衡思路是單點的，不管你是硬件的還是軟件的基本都是這樣的原理，如下圖所示：
對于一般的需求來說，這樣的架構(gòu)基本就可以解決問題了，而且維護(hù)起來也相對簡單，大多數(shù)公司也都是這么干的。
傳統(tǒng)思路的局限性
就如同上圖所示，傳統(tǒng)思路也存在非常明顯的局限性。
也就是說，網(wǎng)站的響應(yīng)速度很大程度上局限于負(fù)載均衡節(jié)點的能力，而且一旦負(fù)載均衡節(jié)點本身掛掉的話，整個網(wǎng)站就完全癱瘓了。
后端的服務(wù)可以水平擴展，但是對于單個節(jié)點來說就算你再增大機器的配置也是有極限的，而且這也不符合互聯(lián)網(wǎng)技術(shù)的發(fā)展規(guī)律。
CDN是怎么做的
作為互聯(lián)網(wǎng)上承載大部分流量的一大基礎(chǔ)設(shè)施，CDN對負(fù)載分流的解決思路很具有啟發(fā)性，如下圖：
從上圖可以看到，用戶的訪問被分流了，所有的請求不再是聚集到一個節(jié)點上，而是被分擔(dān)在了各個合適的節(jié)點上。
這樣即使存在單點故障，也僅僅只會影響到一部分用戶，況且我們還可以使用其他手段做故障轉(zhuǎn)移。
同樣的做法也可以借鑒到傳統(tǒng)的 BS 架構(gòu)中，我們也可以把用戶的請求直接分流到不同的服務(wù)器上，而不必經(jīng)過一個統(tǒng)一的節(jié)點中轉(zhuǎn)。
這個分流是通過什么做到的呢？
答案就是：DNS
你知道DNS是怎么工作的嗎？
大部分人可能天天都用著DNS卻不知道它的基本原理，你可能知道我們訪問互聯(lián)網(wǎng)需要查詢dns服務(wù)器，就是下面的這個玩意
我們只需要問它域名所對應(yīng)的ip地址就行了。
但事情真的這么簡單嗎？它是怎么知道這個域名所對應(yīng)的ip地址呢？
其實dns系統(tǒng)是一個典型的樹狀架構(gòu)，上圖所示的dns服務(wù)器其實應(yīng)該叫dns緩存查詢服務(wù)器，它是為了減輕互聯(lián)網(wǎng)上dns查詢的負(fù)載所設(shè)計的。
如果你的請求沒有命中緩存，那么這個緩存服務(wù)器就會自己進(jìn)行一次標(biāo)準(zhǔn)查詢，然后再把結(jié)果緩存起來，簡單來說就是從根服務(wù)器開始一級一級的問。
我們以前經(jīng)常談到根服務(wù)器的重要性其實就體現(xiàn)在這里了，它保留了對所有域名的起始解釋權(quán)
神奇的解釋權(quán)機制(SOA)
上面講到根服務(wù)器擁有一切域名的起始解釋權(quán)，但是如果你去問根服務(wù)器它是不會直接告訴你最終答案的。
因為如果它要存儲所有的記錄，那它也太累了，這個負(fù)載和開銷是驚人的。
那它會告訴你什么呢？它會告訴你應(yīng)該去問誰，也就是它授權(quán)下一級服務(wù)器來解答你的問題。
我們來看下面的擬人化過程：
我: root, root 告訴我， segmentfault.com 怎么走？
root: 呵呵，你可以去問.com的dns服務(wù)器，地址是xxxxxx
我: .com, .com 告訴我，segmentfault.com 怎么走？
.com: 呵呵，你可以去問segmentfault.com的dns服務(wù)器(dnspod之類的)，地址是xxxxxx
我: dnspod, dnspod 告訴我，segmentfault.com 怎么走？
dnspod: 拿著 xxxxxx，走你
DNS負(fù)載均衡的基本原理
了解了上述過程，我們得到兩個基本結(jié)論
dns系統(tǒng)本身是一個分布式的網(wǎng)絡(luò)，它是相對可靠的，起碼比你網(wǎng)站本身可靠的多
dns的最終解釋是可以受我們自己控制的
有了這兩條結(jié)論，剩下的事情就簡單了，我們只需要在最終解釋的查詢結(jié)果上做文章就可以了。
簡單來說，就是將你的所有服務(wù)器地址，按照自己需求制定的頻次，返回給用戶。
以github.com為例，我們首先獲取它的SOA服務(wù)器（因為dns緩存查詢服務(wù)器會緩存結(jié)果，如果你直接去查詢域名，會每次返回一樣的結(jié)果），.com的dns域名服務(wù)器也是13臺，它們是[a-m].gtld-servers.net，我們隨便選一臺來找找github.com的SOA.如下圖：
OK，我們獲取了四個SOA服務(wù)器 ns[1-4].p16.dynect.net，再隨便選一個來問問github.com對應(yīng)的記錄吧，順便試幾次看看最終的ip地址會不會變化
我們這里查詢了兩次，注意 ANSWER SECTION 部分返回了兩個結(jié)果，一次是192.30.252.129，一次是192.30.252.128。
這就是利用dns實現(xiàn)了負(fù)載均衡，你的最終訪問會到達(dá)不同的ip地址。
有哪些DNS服務(wù)商支持負(fù)載均衡呢？
這是一種比較高級的服務(wù)，一般域名注冊商的dns服務(wù)器不會支持，目前我已知支持它的服務(wù)商有：
AWS Route 53
NSONE
Dyn
dnspod
其中1和4是我們已經(jīng)在使用的，效果比較理想。
總結(jié)
其實DNS可以玩的花樣遠(yuǎn)不止這些，還可以做故障轉(zhuǎn)移，也可以按地區(qū)解析等等。
域名從互聯(lián)網(wǎng)誕生之初就開始存在了，但是對它的研究以及衍生出來的使用方法才剛剛開始發(fā)掘，隨著大家對互聯(lián)網(wǎng)利用的提升，這類技術(shù)肯定會越來越多。
END
作者：默默淡然
來源：https://www.cnblogs.com/liangxiaofeng/p/5169404.html
1.?一個適用于SpringBoot項目的輕量級HTTP客戶端框架
最近面試BAT，整理一份面試資料《Java面試BATJ通關(guān)手冊》，覆蓋了Java核心技術(shù)、JVM、Java并發(fā)、SSM、微服務(wù)、數(shù)據(jù)庫、數(shù)據(jù)結(jié)構(gòu)等等。
獲取方式：點“在看”，關(guān)注公眾號并回復(fù)?Java?領(lǐng)取，更多內(nèi)容陸續(xù)奉上。
文章有幫助的話，在看，轉(zhuǎn)發(fā)吧。
謝謝支持喲 (*^__^*)
