負載均衡的原理（垂直擴充套件 Scale Up、橫向擴充套件 Scale Out）

轉自：碼農翻身（微訊號：coderising）

這是1998年一個普通的上午。

一上班，老闆就把張大胖叫進了辦公室，一邊舒服地喝茶一邊發難：“大胖啊，我們公司開發的這個網站，現在怎麼越來越慢了？ ”

還好張大胖也注意到了這個問題，他早有準備，一臉無奈地說： “唉，我昨天檢查了一下系統，現在的訪問量已經越來越大了，無論是CPU，還是硬碟、記憶體都不堪重負了，高峰期的響應速度越來越慢。”

頓了一下，他試探地問道：“老闆，能不能買個好機器？ 把現在的‘老破小’伺服器給替換掉。我聽說IBM的伺服器挺好的，效能強勁，要不來一臺？”

（碼農翻身注：這叫垂直擴充套件 Scale Up）

“好你個頭，你知道那機器得多貴嗎？! 我們小公司，用不起啊！” 摳門的老闆立刻否決。

“這…” 大胖表示黔驢技窮了。

“你去和CTO Bill 商量下， 明天給我弄個方案出來。”

老闆不管過程，只要結果。

1、隱藏真實伺服器

大胖悻悻地去找Bill。

他將老闆的指示聲情並茂地做了傳達。

Bill笑了：“我最近也在思考這件事，想和你商量一下，看看能不能買幾臺便宜的伺服器，把 多部署幾份，橫向擴充套件(Scale Out)一下。 ”

橫向擴充套件？ 張大胖心中尋思著，如果把系統部署到幾個伺服器上，使用者的訪問請求就可以分散到各個伺服器，那單臺伺服器的壓力就小得多了。

“可是，” 張大胖問道 ，“機器多了，每個機器一個IP， 使用者可能就迷糊了，到底訪問哪一個？”

“肯定不能把這些伺服器暴露出去，從客戶角度看來， 最好是隻有一個伺服器。” Bill 說道。

張大胖眼前一亮， 突然有了主意：“有了！我們有個中間層啊，對，就是DNS，我們可以設定一下，讓我們網站的域名對映到多個伺服器的IP，使用者面對的是我們系統的域名，然後我們可以採用一種輪詢的方式， 使用者1的機器做域名解析的時候，DNS返回IP1, 使用者2的機器做域名解析的時候，DNS返回IP2… 這樣不就可以實現各個機器的負載相對均衡了嗎？”

Bill 思考片刻，發現了漏洞：“這樣做有個很要命的問題，由於 DNS這個分層的系統中有快取，使用者端的機器也有快取，如果某個機器出故障，域名解析仍然會返回那個出問題機器的IP，那所有訪問該機器的使用者都會出問題， 即使我們把這個機器的IP從DNS中刪除也不行， 這就麻煩了。”

張大胖確實是沒想到這個快取帶來的問題， 他撓撓頭：“那就不好辦了。”

2、偷天換日

“要不我們自己開發一個軟體實現負載均衡怎麼樣？” Bill另闢蹊徑。

為了展示自己的想法， 他在白板上畫了一張圖， “看到中間那個藍色伺服器沒有，我們可以把它稱為Load Balancer （簡稱LB）， 使用者的請求都發給他，然後它再發給各個伺服器。”

張大胖仔細審視這個圖。

Load Balancer 簡稱 LB， 有兩個IP，一個對外（115.39.19.22），一個對內(192.168.0.100)。使用者看到的是那個對外的IP。後面的真正提供服務的伺服器有三個，稱為 RS1, RS2,RS3，他們的閘道器都指向LB。

“但是怎麼轉發請求呢？嗯，使用者的請求到底是什麼東西？”  張大胖迷糊了。

“你把計算機網路都忘了吧？ 就是使用者發過來的資料包嘛！ 你看這個層層封裝的資料包，使用者發了一個HTTP的請求，想要訪問我們網站的首頁，這個HTTP請求被放到一個TCP報文中，再被放到一個IP資料包中， 最終的目的地就是我們的Load Balancer（115.39.19.22）。”

（注： 客戶發給LB的資料包， 沒有畫出資料鏈路層的幀）

“但是這個資料包一看就是發給Load Balancer的， 怎麼發給後面的伺服器？”

Bill 說： “可以偷天換日，比如Load Balancer想把這個資料包發給RS1（192.168.0.10）, 就可以做點手腳，把這個資料包改成這樣， 然後這個IP資料包就可以轉發給RS1去處理了。”

（LB動了手腳，把目的地IP和埠改為RS1的）

“RS1處理完了，要返回首頁的HTML，還要把HTTP報文層層封裝：” 張大胖明白怎麼回事了：

（RS1處理完了，要傳送結果給客戶端）

“由於LB是閘道器，它還會收到這個資料包，它就可以再次施展手段，把源地址和源埠都替換為自己的，然後發給客戶就可以了。”

(LB再次動手腳，把源地址和埠改成自己的， 讓客戶端毫無察覺)

張大胖總結了一下資料的流向：
客戶端 --> Load Balancer --> RS --> Load Balancer --> 客戶端

他興奮地說：“這招瞞天過海真是妙啊，客戶端根本就感受不到後面有好幾臺伺服器在工作，它一直以為只有Load Balancer在幹活。”

Bill此刻在思考Load Balancer 怎麼樣才能選取後面的各個真實的伺服器， 可以有很多種策略，他在白板上寫到：

輪詢： 這個最簡單，就是一個挨一個輪換。
加權輪詢： 為了應對某些伺服器效能好，可以讓他們的權重高一點，被選中的機率大一點。
最少連線： 哪個伺服器處理的連線少，就發給誰。
加權最少連線：在最少連線的基礎上，也加上權重
…
還有些其他的演算法和策略，以後慢慢想。

3、四層還是七層？

張大胖卻想到了另外一個問題： 對於使用者的一個請求來說，可能會被分成多個資料包來傳送， 如果這些資料包被我們的Load Balancer發到了不同的機器上，那就完全亂套了啊！  他把自己的想法告訴了Bill。

Bill說：“這個問題很好啊，我們的Load Balancer必須得維護一個表，這個表需要記錄下客戶端的資料包被我們轉發到了哪個真實的伺服器上， 這樣當下一個資料包到來時，我們就可以把它轉發到同一個伺服器上去。”

“看來這個負載均衡軟體需要是面向連線的，也就是OSI網路體系的第4層， 可以稱為 四層負載均衡”Bill做了一個總結。

“既然有四層負載均衡，那是不是也可以搞個七層的負載均衡啊？” 張大胖突發奇想。

“那是肯定的，如果我們的Load Balancer把HTTP層的報文資料取出來，根據其中的URL，瀏覽器，語言等資訊，把請求分發到後面真實的伺服器去，那就是七層的負載均衡了。不過我們現階段先實現一個四層的吧，七層的以後再說。”

Bill 吩咐張大胖組織人力把這個負載均衡軟體給開發出來。

張大胖不敢怠慢，由於涉及到協議的細節問題，張大胖還買了幾本書：《TCP/IP詳解》 卷一,卷二,卷三， 帶著人快速複習了C語言， 然後開始瘋狂開發。

4、責任分離

三個月後，Load Balancer的第一版開發出來了，這是執行在Linux上的一個軟體， 公司試用了一下， 執行流暢，感覺還真是不錯，僅僅用幾臺便宜的伺服器就可以實現負載均衡了。

老闆看到沒花多少錢就解決了問題，非常滿意，給張大胖所在的開發組發了1000塊錢獎金，組織大家出去搓了一頓。

張大胖他們看到老闆很摳門，雖略有不滿，但是想到透過這個軟體的開發，學到了很多底層的知識，尤其是TCP協議，也就忍了。

可是好景不長，張大胖發現這個Load Balancer存在這瓶頸： 所有的流量都要透過它，它要修改客戶發來的資料包， 還要修改發給客戶的資料包。

網路訪問還有個極大的特點，那就是請求報文較短而響應報文往往包含大量的資料。這是很容易理解的，一個HTTP GET請求短得可憐，可是返回的HTML卻是極長，這就進一步加劇了Load Balancer修改資料包的工作。

張大胖趕緊去找Bill ，Bill說：“這確實是個問題， 我們把請求和響應分開處理吧，讓Load Balancer只處理請求，讓各個伺服器把響應直接發給客戶端，這樣瓶頸不就消除了嗎？”

“怎麼分開處理？”

“首先讓所有的伺服器都有同一個IP， 我們把他稱為VIP吧（如圖中115.39.19.22）。”

張大胖透過第一版Load Balancer的開發，積累了豐富的經驗。

他問道：“你這是把每個實際伺服器的loopback都繫結了那個VIP， 不過有問題啊，這麼多伺服器都有同樣的IP , 當IP資料包來的時候，到底應該由哪個伺服器來處理？”

“注意，IP資料包其實是透過資料鏈路層發過來的，你看看這個圖。”

張大胖看到了客戶端的HTTP報文再次被封裝儲層TCP報文，埠號是80， 然後IP資料包中的目的地是115.39.19.22(VIP)。

圖中的問號是目的地的MAC地址， 該怎麼得到呢？

對， 是使用ARP協議，把一個IP地址（115.39.19.22）給廣播出去，然後具有此IP機器就會回覆自己的MAC地址。 但是現在有好幾臺機器都有同一個IP（115.39.19.22）， 怎麼辦？

Bill 說道：“我們只讓Load Balancer 響應這個VIP地址（115.39.19.22）的ARP請求，對於RS1,RS2,RS3, 抑制住對這個VIP地址的ARP響應，不就可以唯一地確定Load Balancer了？ ”

原來如此！張大胖恍然大悟。

既然Load Balancer得到了這個IP資料包， 它就可以用某個策略從RS1, RS2,RS3中選取一個伺服器，例如RS1（192.168.0.10），把 IP資料包原封不動， 封裝成資料鏈路層的包（目的地是RS1的MAC地址），直接轉發就可以了。

RS1（192.168.0.10）這個伺服器收到了資料包，拆開一看，目的地IP是115.39.19.22，是自己的IP， 那就可以處理了。

處理完了以後，RS1可以直接響應發回給客戶端，完全不用再透過Load Balancer。因為自己的地址就是115.39.19.22。

對於客戶端來說，它看到的還是那個唯一的地址115.39.19.22， 並不知道後臺發生了什麼事情。

Bill補充到：“由於Load Balancer 根本不會修改IP資料包，其中的TCP的埠號自然也不會修改，這就要求RS1, RS2,RS3上的埠號必須得和Load Balancer一致才行。”

像之前一樣，張大胖總結了一下資料的流向：

客戶端 --> Load Balancer --> RS --> 客戶端

Bill 說道：“怎麼樣？ 這個辦法還可以吧？”

張大胖又想了想，這種方式似乎沒有漏洞，並且效率很高，Load Balancer只負責把使用者請求發給特定的伺服器就萬事大吉了， 剩下的事由具體的伺服器來處理，和它沒有關係了。

他高興地說：“不錯，我著手帶人去實現了。”

後記： 本文所描述的，其實就是著名開源軟體LVS的原理，上面講的兩種負載均衡的方式，就是LVS的NAT和DR。

LVS是章文嵩博士在1998年5月成立的自由軟體專案，現在已經是Linux核心的一部分。想想那時候我還在不亦樂乎地折騰個人網頁，學會安裝和使用Linux 沒多久 , 伺服器端開發也僅限於ASP，像LVS這種負載均衡的概念壓根就沒有聽說過。

程式語言可以學，差距也能彌補，但是這種境界和眼光的差距，簡直就是巨大的鴻溝，難以跨越啊！