這是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這種負載均衡的概念壓根就沒有聽說過。

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

（完）

"Linux閱碼場"是專業的Linux及系統軟件技術交流社區，Linux系統人才培養基地，企業和Linux人才的連接樞紐。