公司架構師常常提起的DNS負載均衡是個什么鬼？
不點藍字關注，我們哪來故事？
傳統(tǒng)思路的局限性 CDN是怎么做的 你知道DNS是怎么工作的嗎？ 神奇的解釋權機制（SOA） DNS負載均衡的基本原理 有哪些DNS服務商支持負載均衡呢？ 總結
當網(wǎng)站的訪問量大了就會考慮負載均衡，這也是每一個架構師的基本功了，其基本地位就相當于相聲里的說學逗唱，活好不好就看這個了 :)
傳統(tǒng)的負載均衡思路是單點的，不管你是硬件的還是軟件的基本都是這樣的原理，如下圖所示：
對于一般的需求來說，這樣的架構基本就可以解決問題了，而且維護起來也相對簡單，大多數(shù)公司也都是這么干的。
傳統(tǒng)思路的局限性
就如同上圖所示，傳統(tǒng)思路也存在非常明顯的局限性。
也就是說，網(wǎng)站的響應速度很大程度上局限于負載均衡節(jié)點的能力，而且一旦負載均衡節(jié)點本身掛掉的話，整個網(wǎng)站就完全癱瘓了。
后端的服務可以水平擴展，但是對于單個節(jié)點來說就算你再增大機器的配置也是有極限的，而且這也不符合互聯(lián)網(wǎng)技術的發(fā)展規(guī)律。
基于 Spring Boot + MyBatis Plus + Vue & Element 實現(xiàn)的后臺管理系統(tǒng) + 用戶小程序，支持 RBAC 動態(tài)權限、多租戶、數(shù)據(jù)權限、工作流、三方登錄、支付、短信、商城等功能。
項目地址：https://github.com/YunaiV/ruoyi-vue-pro
CDN是怎么做的
作為互聯(lián)網(wǎng)上承載大部分流量的一大基礎設施，CDN對負載分流的解決思路很具有啟發(fā)性，如下圖：
從上圖可以看到，用戶的訪問被分流了，所有的請求不再是聚集到一個節(jié)點上，而是被分擔在了各個合適的節(jié)點上。
這樣即使存在單點故障，也僅僅只會影響到一部分用戶，況且我們還可以使用其他手段做故障轉移。
同樣的做法也可以借鑒到傳統(tǒng)的 BS 架構中，我們也可以把用戶的請求直接分流到不同的服務器上，而不必經(jīng)過一個統(tǒng)一的節(jié)點中轉。
這個分流是通過什么做到的呢？
答案就是：DNS
基于微服務的思想，構建在 B2C 電商場景下的項目實戰(zhàn)。核心技術棧，是 Spring Boot + Dubbo 。未來，會重構成 Spring Cloud Alibaba 。
項目地址：https://github.com/YunaiV/onemall
你知道DNS是怎么工作的嗎？
大部分人可能天天都用著DNS卻不知道它的基本原理，你可能知道我們訪問互聯(lián)網(wǎng)需要查詢dns服務器，就是下面的這個玩意
我們只需要問它域名所對應的ip地址就行了。
但事情真的這么簡單嗎？它是怎么知道這個域名所對應的ip地址呢？
其實dns系統(tǒng)是一個典型的樹狀架構 ，上圖所示的dns服務器其實應該叫dns緩存查詢服務器，它是為了減輕互聯(lián)網(wǎng)上dns查詢的負載所設計的。
如果你的請求沒有命中緩存，那么這個緩存服務器就會自己進行一次標準查詢，然后再把結果緩存起來，簡單來說就是從根服務器開始一級一級的問。
我們以前經(jīng)常談到根服務器的重要性其實就體現(xiàn)在這里了，它保留了對所有域名的起始解釋權
神奇的解釋權機制（SOA）
上面講到根服務器擁有一切域名的起始解釋權，但是如果你去問根服務器它是不會直接告訴你最終答案的。
因為如果它要存儲所有的記錄，那它也太累了，這個負載和開銷是驚人的。
那它會告訴你什么呢？它會告訴你應該去問誰，也就是它授權下一級服務器來解答你的問題。
我們來看下面的擬人化過程：
我: root, root 告訴我， segmentfault.com 怎么走？
root: 呵呵，你可以去問.com的dns服務器，地址是xxxxxx
我: .com, .com 告訴我，segmentfault.com 怎么走？
.com: 呵呵，你可以去問segmentfault.com的dns服務器(dnspod之類的)，地址是xxxxxx
我: dnspod, dnspod 告訴我，segmentfault.com 怎么走？
dnspod: 拿著 xxxxxx，走你
DNS負載均衡的基本原理
了解了上述過程，我們得到兩個基本結論
dns系統(tǒng)本身是一個分布式的網(wǎng)絡，它是相對可靠的，起碼比你網(wǎng)站本身可靠的多
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實現(xiàn)了負載均衡，你的最終訪問會到達不同的ip地址。
有哪些DNS服務商支持負載均衡呢？
這是一種比較高級的服務，一般域名注冊商的dns服務器不會支持，目前我已知支持它的服務商有：
AWS Route 53 NSONE Dyn dnspod
其中1和4是我們已經(jīng)在使用的，效果比較理想。
總結
其實DNS可以玩的花樣遠不止這些，還可以做故障轉移，也可以按地區(qū)解析等等。
域名從互聯(lián)網(wǎng)誕生之初就開始存在了，但是對它的研究以及衍生出來的使用方法才剛剛開始發(fā)掘，隨著大家對互聯(lián)網(wǎng)利用的提升，這類技術肯定會越來越多。
