對於服務端的開發者而言，“負載均衡”這個詞聽起來可能並不陌生，那麼負載均衡是爲了做什麼的呢？這個負載均衡服務器最基本的功能就是要保證所有提供服務的機器要大概一樣忙，不能讓一臺機器太忙，也不能讓一臺機器太閒，這樣就能保證集羣中的機器都物盡其用。
說起負載均衡，如果從戲裏說來，我們可能要了解太多的網絡原理裏，咱們就簡單的先把裏面可能設計的知識點說下吧，負載均衡相關的，需要了解DNS協議（其中又會引申出來HTTPDNS等等只是內容），CDN，如果用的負載均衡啥的是“阿里雲”啥的，那咱還需要了解下數據中心，雲主機方面，NAT，openSwitch，VXLAN，GRE，容器相關知識Docker，Flannel，Calico等等，想想就可怕。好了，言歸正傳，今天咱們先簡單瞭解下這其中的基本內容。
1.DNS做全局負載均衡
說起DNS，那DNS是做什麼的呢？之前咱們知道每個服務器實際上對應着一個訪問它的IP地址，但是對於用戶直接去訪問的時候，記IP實在是太困難了，於是就有了DNS，通過名稱，來查看起具體的地址。注意的是，日常使用的時候訪問網站都要經過它，那麼它故障的話整個網絡都要GG，所以它一定是高可用，高併發和分佈式的，於是有樹狀層次結構如下。
知道了它的層次結構，那麼DNS是如何解析的呢？
1.用戶去訪問 www.google.com這個網站，向本地DNS詢問，這個域名對應的IP是什麼？
2.本地DNS收到了用戶的請求，就去找它自己的緩存，看看有沒有www.google.com對應的ip地址，如果有的話就直接返回，沒有的話，本地DNS會向根DNS發送一個請求，進行詢問。
3.根DNS收到來自本地DNS的請求，看最後一層後綴是什麼，然後給本地DNS返回對應頂級DNS的地址，供下一步詢問。
4.本地DNS向頂級DNS進行詢問，www.google.com的IP地址是什麼？
5.頂級DNS收到請求後，返回權威DNS服務器的地址，供進一步的詢問。
6.本地DNS向權威DNS服務器進行詢問，www.google.com的IP是什麼？
7.權威DNS將www.google.com的IP地址返回給本地DNS。
8.本地DNS將IP地址返回給用戶，並在自己這裏建立對應緩存，用戶就可以和目標服務器建立連接了。
咱們瞭解了DNS了，那麼如何做負載均衡呢？
1.DNS做內部負載均衡
我們知道的，一般服務端做的肯定是要連接數據庫的，那麼當配置數據庫的時候要配置IP還是域名呢？如果配置域名的話就可以實現負載均衡了，每次連接，我都去按照一定的規則去返回數據庫的ip。不過這樣不太建議哈，只是舉個例子，這個例子不太合適，暫時沒想到更貼切的，哈哈。
2.全局負載均衡
現在應用爲了保證高可用性，都是不實在多個機房的，每個地方對應的ip是不同的，爲什麼要這麼做呢？道理很簡單，就是某一處的機房掛了，從DNS服務器裏面刪除那個掛了的數據中心對應的ip，就能保證應用正常使用。另外，對於用戶訪問來說，我們肯定是想要讓他訪問更近的數據中心，訪問速度會最快，經歷路程最短。
但是有個問題需要注意的是，這其實存在問題，緩存問題，域名轉發問題，出口NAT問題，域名更新。
1.從咱們解析過程看，如果有緩存的話，會直接吧緩存的ip直接返回給用戶，那如果這個ip發生了變更了呢？
2.還有的運營商將某些靜態頁面直接緩存了，那麼就不會去訪問真實ip地址對應的實時內容，那麼頁面發生了改變呢？
3.本地DNS會緩存就近的ip，那麼，上次是最近的，過了一陣後，這個ip還是最近的嗎？可能不一定。
4.咱們知道，咱們最初的流量肯定會到運營商，但是某些運營商可能會將流量轉發給另一個運營商在進行請求，那麼這就產生了問題，當分配就近的IP的時候，返回的可能是針對與被轉發的那個運營商的，而不是當前用戶第一個運營上的，那麼這就不是最近的了吧。
5.NAT在進行轉換IP的時候，IP就變了，那麼我實際到權威DNS的IP就沒法去判斷是否是原始的，沒有轉過的，那麼可能就判斷錯了。
6.域名更新的時候，我們很多時候會等權威DNS進行變更，但是吧，刷新速度往往是不同的，那麼有的時候可能反問的就是錯的。
這麼多問題，看起來就可怕，不過隨着技術的更新迭代，又有牛人創造了HTTPDNS，其實解釋起來也簡單，就是不走傳統的DNS解析，而是走自己搭建的基於HTTP的DNS服務器集羣，就相當於走了自己的配置，自己控制主動權。不過這一般依賴於客戶端SDK。
2.進一步的優化 CDN
CDN與DNS有相同點，都是分佈在一個多區域，多運營商的分佈式系統，去找邊緣節點的思路也很是相同，都是通過層層解析。
1.在沒有CDN的時候，用戶輸入www.google.com訪問本地DNS，然後去找真實服務器的IP，訪問這個網站。有了CDN之後呢，我們會在google.com這個權威服務器上設置一個CNAME的別名，指向另外一個域名，例如www.google.cdn.com，返回給本地的DNS。
2.本地DNS拿到這個新域名，在訪問的時候就是去訪問google.cdn.com的權威服務器了，在這個服務器上還是會設置一個CNAME別名，指向CDN網絡的全局負載均衡器。
3.接下來，本地DNS服務器去請求CDN的全局負載均衡去解析域名，選擇合適的服務器。
4.返回被選中的機器的IP返回給客戶端，客戶端就去這個地址去下載所需要的資源就行。一般緩存靜態圖片，網頁啥資源，當然也是支持流媒體的
3.負載均衡
其實實現負載均衡的方式有很多，例如通過Linux內核的Netfilter框架，虛擬服務器LVS，Haproxy等均可以實現，接下來咱們還是講講Netfilter吧，因爲我覺得這個的還可以順便用iptable舉例講講安全。
Netfilter是一個Linux內核框架，它可以在網絡包進入本級以後解析的幾個節點內插入Hook函數，也就是我們常說的鉤子。這些函數可以截取數據包，並對數據包進行一定的干預。
這個可能比較難理解，根據這個特性咱們可以把它用在咱們內部的負載均衡上，根據咱們自己的一些邏輯，然後把請求分配給不同的機器處理。先說以下咱們網絡包進來的幾個節點吧。
在網絡包進來以後，先拿下來MAC頭，看看是不是自己的，是的話走進去咱們的幾個節點。
1.PREROUTING：取下網絡包的IP頭，開始準備進行路有判斷，路由判斷前的那個節點就是這個。
2.INPUT: 取下IP頭後，發現是我的，發給上面的傳輸層
3.FORWARD：取下IP頭後，發現這個不是我的，轉發出去
4.OUTPUT：上層處理完畢後，返回處理結果發送出去
5.POSTROUTING：最後節點
這個應用有個特別著名的程序，就是iptables，這個咱們很多時候用在防火牆。具體實現就是在那5個節點埋函數，功能主要分爲連接跟蹤，數據包過濾，網絡地址轉換，數據包修改幾類。
其實這個負載均衡思路也很好想了，簡單的而言，就是請求進來後，咱們轉發的時候，去按照每臺機器的情況，轉發給比較閒的機器而已。