負載均衡是怎么工作的？

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

一上班，老板就把張大胖叫進了辦公室，一邊舒服地喝茶一邊發(fā)難：“大胖啊，我們公司開發(fā)的這個網(wǎng)站，現(xiàn)在怎么越來越慢了？ ”

還好張大胖也注意到了這個問題，他早有準(zhǔn)備，一臉無奈地說： “唉，我昨天檢查了一下系統(tǒng)，現(xiàn)在的訪問量已經(jīng)越來越大了，無論是CPU，還是硬盤、內(nèi)存都不堪重負了，高峰期的響應(yīng)速度越來越慢?！?/p>

頓了一下，他試探地問道：“老板，能不能買個好機器？ 把現(xiàn)在的‘老破小’服務(wù)器給替換掉。我聽說IBM的服務(wù)器挺好的，性能強勁，要不來一臺？”

（碼農(nóng)翻身注：這叫垂直擴展 Scale Up）

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

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

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

老板不管過程，只要結(jié)果。

1隱藏真實服務(wù)器

大胖悻悻地去找Bill。

他將老板的指示聲情并茂地做了傳達。

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

橫向擴展？ 張大胖心中尋思著，如果把系統(tǒng)部署到幾個服務(wù)器上，用戶的訪問請求就可以分散到各個服務(wù)器，那單臺服務(wù)器的壓力就小得多了。

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

“肯定不能把這些服務(wù)器暴露出去，從客戶角度看來，最好是只有一個服務(wù)器?！?Bill 說道。

張大胖眼前一亮， 突然有了主意：“有了！我們有個中間層啊，對，就是DNS，我們可以設(shè)置一下，讓我們網(wǎng)站的域名映射到多個服務(wù)器的IP，用戶面對的是我們系統(tǒng)的域名，然后我們可以采用一種輪詢的方式， 用戶1的機器做域名解析的時候，DNS返回IP1, 用戶2的機器做域名解析的時候，DNS返回IP2...... 這樣不就可以實現(xiàn)各個機器的負載相對均衡了嗎？”

Bill 思考片刻，發(fā)現(xiàn)了漏洞：“這樣做有個很要命的問題，由于DNS這個分層的系統(tǒng)中有緩存，用戶端的機器也有緩存，如果某個機器出故障，域名解析仍然會返回那個出問題機器的IP，那所有訪問該機器的用戶都會出問題， 即使我們把這個機器的IP從DNS中刪除也不行， 這就麻煩了?！?/p>

張大胖確實是沒想到這個緩存帶來的問題， 他撓撓頭：“那就不好辦了?！?/p>

2偷天換日

“要不我們自己開發(fā)一個軟件實現(xiàn)負載均衡怎么樣？” Bill另辟蹊徑。

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

張大胖仔細審視這個圖。

Load Balancer 簡稱LB， 有兩個IP，一個對外（115.39.19.22），一個對內(nèi)(192.168.0.100)。用戶看到的是那個對外的IP。 后面的真正提供服務(wù)的服務(wù)器有三個，稱為RS1, RS2,RS3， 他們的網(wǎng)關(guān)都指向LB。

“但是怎么轉(zhuǎn)發(fā)請求呢？嗯， 用戶的請求到底是什么東西？” 張大胖迷糊了。

“你把計算機網(wǎng)絡(luò)都忘了吧？ 就是用戶發(fā)過來的數(shù)據(jù)包嘛！ 你看這個層層封裝的數(shù)據(jù)包，用戶發(fā)了一個HTTP的請求，想要訪問我們網(wǎng)站的首頁，這個HTTP請求被放到一個TCP報文中，再被放到一個IP數(shù)據(jù)報中， 最終的目的地就是我們的Load Balancer（115.39.19.22）?！?/p>

（注： 客戶發(fā)給LB的數(shù)據(jù)包， 沒有畫出數(shù)據(jù)鏈路層的幀）

“但是這個數(shù)據(jù)包一看就是發(fā)給Load Balancer的， 怎么發(fā)給后面的服務(wù)器？”

Bill 說： “可以偷天換日，比如Load Balancer想把這個數(shù)據(jù)包發(fā)給RS1（192.168.0.10）, 就可以做點手腳，把這個數(shù)據(jù)包改成這樣， 然后這個IP數(shù)據(jù)包就可以轉(zhuǎn)發(fā)給RS1去處理了。”

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

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

（RS1處理完了，要發(fā)送結(jié)果給客戶端）

“由于LB是網(wǎng)關(guān)，它還會收到這個數(shù)據(jù)包，它就可以再次施展手段，把源地址和源端口都替換為自己的，然后發(fā)給客戶就可以了?！?/p>

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

張大胖總結(jié)了一下數(shù)據(jù)的流向：

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

他興奮地說：“這招瞞天過海真是妙啊，客戶端根本就感受不到后面有好幾臺服務(wù)器在工作，它一直以為只有Load Balancer在干活?！?/p>

Bill此刻在思考Load Balancer 怎么樣才能選取后面的各個真實的服務(wù)器， 可以有很多種策略，他在白板上寫到：

輪詢： 這個最簡單，就是一個挨一個輪換。

加權(quán)輪詢： 為了應(yīng)對某些服務(wù)器性能好，可以讓他們的權(quán)重高一點，被選中的幾率大一點。

最少連接： 哪個服務(wù)器處理的連接少，就發(fā)給誰。

加權(quán)最少連接：在最少連接的基礎(chǔ)上，也加上權(quán)重

......

還有些其他的算法和策略，以后慢慢想。

3四層還是七層？

張大胖卻想到了另外一個問題： 對于用戶的一個請求來說，可能會被分成多個數(shù)據(jù)包來發(fā)送，如果這些數(shù)據(jù)包被我們的Load Balancer發(fā)到了不同的機器上，那就完全亂套了?。?他把自己的想法告訴了Bill。

Bill說：“這個問題很好啊，我們的Load Balancer必須得維護一個表，這個表需要記錄下客戶端的數(shù)據(jù)包被我們轉(zhuǎn)發(fā)到了哪個真實的服務(wù)器上， 這樣當(dāng)下一個數(shù)據(jù)包到來時，我們就可以把它轉(zhuǎn)發(fā)到同一個服務(wù)器上去?！?/p>

“看來這個負載均衡軟件需要是面向連接的，也就是OSI網(wǎng)絡(luò)體系的第4層， 可以稱為四層負載均衡”Bill做了一個總結(jié)。

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

“那是肯定的，如果我們的Load Balancer把HTTP層的報文數(shù)據(jù)取出來，根據(jù)其中的URL，瀏覽器，語言等信息，把請求分發(fā)到后面真實的服務(wù)器去，那就是七層的負載均衡了。不過我們現(xiàn)階段先實現(xiàn)一個四層的吧，七層的以后再說?！?/p>

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

張大胖不敢怠慢，由于涉及到協(xié)議的細節(jié)問題，張大胖還買了幾本書：《TCP/IP詳解》 卷一,卷二,卷三， 帶著人快速復(fù)習(xí)了C語言， 然后開始瘋狂開發(fā)。

4責(zé)任分離

三個月后，Load Balancer的第一版開發(fā)出來了，這是運行在Linux上的一個軟件， 公司試用了一下，感覺還真是不錯，僅僅用幾臺便宜的服務(wù)器就可以實現(xiàn)負載均衡了。

老板看到?jīng)]花多少錢就解決了問題，非常滿意，給張大胖所在的開發(fā)組發(fā)了1000塊錢獎金，組織大家出去搓了一頓。

張大胖他們看到老板很摳門，雖略有不滿，但是想到通過這個軟件的開發(fā)，學(xué)到了很多底層的知識，尤其是TCP協(xié)議，也就忍了。

可是好景不長，張大胖發(fā)現(xiàn)這個Load Balancer存在這瓶頸：所有的流量都要通過它，它要修改客戶發(fā)來的數(shù)據(jù)包， 還要修改發(fā)給客戶的數(shù)據(jù)包。

網(wǎng)絡(luò)訪問還有個極大的特點，那就是請求報文較短而響應(yīng)報文往往包含大量的數(shù)據(jù)。這是很容易理解的，一個HTTP GET請求短得可憐，可是返回的HTML卻是極長 -- 這就進一步加劇了Load Balancer修改數(shù)據(jù)包的工作。

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

“怎么分開處理？”

“首先讓所有的服務(wù)器都有同一個IP， 我們把他稱為VIP吧（如圖中115.39.19.22）?！?/p>

張大胖通過第一版Load Balancer的開發(fā)，積累了豐富的經(jīng)驗。

他問道：“你這是把每個實際服務(wù)器的loopback都綁定了那個VIP， 不過有問題啊，這么多服務(wù)器都有同樣的IP , 當(dāng)IP數(shù)據(jù)包來的時候，到底應(yīng)該由哪個服務(wù)器來處理？”

“注意，IP數(shù)據(jù)包其實是通過數(shù)據(jù)鏈路層發(fā)過來的，你看看這個圖。”

張大胖看到了客戶端的HTTP報文再次被封裝儲層TCP報文，端口號是80， 然后IP數(shù)據(jù)報中的目的地是115.39.19.22(VIP)。

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

對， 是使用ARP協(xié)議，把一個IP地址（115.39.19.22）給廣播出去，然后具有此IP機器就會回復(fù)自己的MAC地址。 但是現(xiàn)在有好幾臺機器都有同一個IP（115.39.19.22）， 怎么辦？

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

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

既然Load Balancer得到了這個IP數(shù)據(jù)包， 它就可以用某個策略從RS1, RS2,RS3中選取一個服務(wù)器，例如RS1（192.168.0.10），把IP數(shù)據(jù)報原封不動， 封裝成數(shù)據(jù)鏈路層的包（目的地是RS1的MAC地址），直接轉(zhuǎn)發(fā)就可以了。

RS1（192.168.0.10）這個服務(wù)器收到了數(shù)據(jù)包，拆開一看，目的地IP是115.39.19.22，是自己的IP， 那就可以處理了。

處理完了以后，RS1可以直接響應(yīng)發(fā)回給客戶端，完全不用再通過Load Balancer。因為自己的地址就是115.39.19.22。

對于客戶端來說，它看到的還是那個唯一的地址115.39.19.22， 并不知道后臺發(fā)生了什么事情。

Bill補充到：“由于Load Balancer 根本不會修改IP數(shù)據(jù)報，其中的TCP的端口號自然也不會修改，這就要求RS1, RS2,RS3上的端口號必須得和Load Balancer一致才行?！?/p>

像之前一樣，張大胖總結(jié)了一下數(shù)據(jù)的流向：

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

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

張大胖又想了想，這種方式似乎沒有漏洞，并且效率很高，Load Balancer只負責(zé)把用戶請求發(fā)給特定的服務(wù)器就萬事大吉了， 剩下的事由具體的服務(wù)器來處理，和它沒有關(guān)系了。

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

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

LVS是章文嵩博士在1998年5月成立的自由軟件項目，現(xiàn)在已經(jīng)是Linux內(nèi)核的一部分。想想那時候我還在不亦樂乎地折騰個人網(wǎng)頁，學(xué)會安裝和使用Linux 沒多久 , 服務(wù)器端開發(fā)也僅限于ASP，像LVS這種負載均衡的概念壓根就沒有聽說過。

編程語言可以學(xué)，差距也能彌補，但是這種境界和眼光的差距，簡直就是巨大的鴻溝，難以跨越?。?/p>

（完）

"Linux閱碼場"是專業(yè)的Linux及系統(tǒng)軟件技術(shù)交流社區(qū)，Linux系統(tǒng)人才培養(yǎng)基地，企業(yè)和Linux人才的連接樞紐。