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

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

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

一上班，老闆就把張大胖叫進了辦公室，一邊舒服地喝茶一邊發難：「大胖啊，咱們公司開發的這個網站，如今怎麼愈來愈慢了？ 」

還好張大胖也注意到了這個問題，他早有準備，一臉無奈地說： 「唉，我昨天檢查了一下系統，如今的訪問量已經愈來愈大了，不管是CPU，仍是硬盤、內存都不堪重負了，高峯期的響應速度愈來愈慢。」

頓了一下，他試探地問道：「老闆，能不能買個好機器？ 把如今的‘老破小’服務器給替換掉。我據說IBM的服務器挺好的，性能強勁，要不來一臺？」

（碼農翻身注：這叫垂直擴展 Scale Up）

「好你個頭，你知道那機器得多貴嗎？! 咱們小公司，用不起啊！」 摳門的老闆馬上否決。

「這…」 大胖表示黔驢技窮了。

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

老闆無論過程，只要結果。

一、隱藏真實服務器

大胖悻悻地去找Bill。

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

Bill笑了：「我最近也在思考這件事，想和你商量一下，看看能不能買幾臺便宜的服務器，把管理系統多部署幾份，橫向擴展(Scale Out)一下。 」

橫向擴展？ 張大胖心中尋思着，若是把系統部署到幾個服務器上，用戶的訪問請求就能夠分散到各個服務器，那單臺服務器的壓力就小得多了。

「但是，」 張大胖問道 ，「機器多了，每一個機器一個IP， 用戶可能就迷糊了，到底訪問哪個？」

「確定不能把這些服務器暴露出去，從客戶角度看來，最好是隻有一個服務器。」 Bill 說道。

張大胖眼前一亮， 忽然有了主意：「有了！咱們有個中間層啊，對，就是DNS，咱們能夠設置一下，讓咱們網站的域名映射到多個服務器的IP，用戶面對的是咱們系統的域名，而後咱們能夠採用一種輪詢的方式， 用戶1的機器作域名解析的時候，DNS返回IP1, 用戶2的機器作域名解析的時候，DNS返回IP2… 這樣不就能夠實現各個機器的負載相對均衡了嗎？」

Bill 思考片刻，發現了漏洞：「這樣作有個很要命的問題，因爲DNS這個分層的系統中有緩存，用戶端的機器也有緩存，若是某個機器出故障，域名解析仍然會返回那個出問題機器的IP，那全部訪問該機器的用戶都會出問題， 即便咱們把這個機器的IP從DNS中刪除也不行， 這就麻煩了。」

張大胖確實是沒想到這個緩存帶來的問題， 他撓撓頭：「那就很差辦了。」

二、偷天換日

「要不咱們本身開發一個軟件實現負載均衡怎麼樣？」 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 怎麼樣才能選取後面的各個真實的服務器， 能夠有不少種策略，他在白板上寫到：

輪詢： 這個最簡單，就是一個挨一個輪換。
加權輪詢： 爲了應對某些服務器性能好，可讓他們的權重高一點，被選中的概率大一點。
最少鏈接： 哪一個服務器處理的鏈接少，就發給誰。
加權最少鏈接：在最少鏈接的基礎上，也加上權重
…
還有些其餘的算法和策略，之後慢慢想。

三、四層仍是七層？

張大胖卻想到了另一個問題： 對於用戶的一個請求來講，可能會被分紅多個數據包來發送，若是這些數據包被咱們的Load Balancer發到了不一樣的機器上，那就徹底亂套了啊！ 他把本身的想法告訴了Bill。
Bill說：「這個問題很好啊，咱們的Load Balancer必須得維護一個表，這個表須要記錄下客戶端的數據包被咱們轉發到了哪一個真實的服務器上， 這樣當下一個數據包到來時，咱們就能夠把它轉發到同一個服務器上去。」

「看來這個負載均衡軟件須要是面向鏈接的，也就是OSI網絡體系的第4層， 能夠稱爲四層負載均衡」Bill作了一個總結。

「既然有四層負載均衡，那是否是也能夠搞個七層的負載均衡啊？」 張大胖突發奇想。

「那是確定的，若是咱們的Load Balancer把HTTP層的報文數據取出來，根據其中的URL，瀏覽器，語言等信息，把請求分發到後面真實的服務器去，那就是七層的負載均衡了。不過咱們現階段先實現一個四層的吧，七層的之後再說。」

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

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

四、責任分離

三個月後，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這種負載均衡的概念壓根就沒有據說過。

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