快速理解高效能HTTP服務端的負載均衡技術原理

負載均衡 HTTP 高效能 · 發表 2018-09-11 14:55:28

摘要：在一個典型的高併發、大使用者量的Web網際網路系統的架構設計中，對HTTP叢集的負載均衡設計是作為高效能系統優化環節中必不可少的方案。HTTP負載均衡的本質上是將Web使用者流量進行均衡減壓，因此在網際網路的大流量專案中，其重要性不言而喻。本文將以簡潔通俗的文字，為你講解主流的HTTP服...

在一個典型的高併發、大使用者量的Web網際網路系統的架構設計中，對HTTP叢集的負載均衡設計是作為高效能系統優化環節中必不可少的方案。HTTP負載均衡的本質上是將Web使用者流量進行均衡減壓，因此在網際網路的大流量專案中，其重要性不言而喻。

本文將以簡潔通俗的文字，為你講解主流的HTTP服務端實現負載均衡的常見方案，以及具體到方案中的負載均衡演算法的實現原理。理解和掌握這些方案、演算法原理，有助於您今後的網際網路項的技術選型和架構設計，因為沒有哪一種方案和演算法能解決所有問題，只有針對特定的場景使用合適的方案和演算法才是最明智的選擇。

即時通訊網注： 本文中所提及的HTTP負載均衡方案和演算法，並不完全適用IM即時通訊Socket長連線的負載均衡，因為IM長連線、有狀態的特性，跟HTTP這種短連線、無狀態的特徵是矛盾的，所以請勿盲目套用。但，一個完整的IM系統是由HTTP短連線+IM長連線組成，因而本文內容雖不能套用於IM長連線的負載均衡方案，但可以用於您IM的高併發、大使用者量的HTTP短連線的方案設計。

（本文同步釋出於： ofollow,noindex">http://www.52im.net/thread-1950-1-1.html ）

2、相關文章

深入閱讀以下文章，有助於您更好地理解本篇內容：

《騰訊資深架構師乾貨總結：一文讀懂大型分散式系統設計的方方面面》

《以微博類應用場景為例，總結海量社交系統的架構設計步驟》

《 IM開發基礎知識補課(四)：正確理解HTTP短連線中的Cookie、Session和Token 》

3、什麼是負載均衡？

早期的網際網路應用，由於使用者流量比較小，業務邏輯也比較簡單，往往一個單伺服器就能滿足負載需求。隨著現在網際網路的流量越來越大，稍微好一點的系統，訪問量就非常大了，並且系統功能也越來越複雜，那麼單臺伺服器就算將效能優化得再好，也不能支撐這麼大使用者量的訪問壓力了，這個時候就需要使用多臺機器，設計高效能的叢集來應對。

那麼，多臺伺服器是如何去均衡流量、如何組成高效能的叢集的呢？

此時就需要請出「負載均衡器」入場了。

負載均衡（Load Balancer）是指把使用者訪問的流量，通過「負載均衡器」，根據某種轉發的策略，均勻的分發到後端多臺伺服器上，後端的伺服器可以獨立的響應和處理請求，從而實現分散負載的效果。負載均衡技術提高了系統的服務能力，增強了應用的可用性。

負載均衡的基本原理就像下圖這樣：

4、主流負載均衡方案有幾種？

目前市面上最常見的負載均衡技術方案主要有三種：

1）基於DNS負載均衡；

2）基於硬體負載均衡：比如F5

3）基於軟體負載均衡：比如Nginx、Squid。

三種方案各有優劣，DNS負載均衡可以實現在地域上的流量均衡，硬體負載均衡主要用於大型伺服器叢集中的負載需求，而軟體負載均衡大多是基於機器層面的流量均衡。在實際場景中，這三種是可以組合在一起使用。

下面分別來詳細講講這些方案。

4.1 基於DNS負載均衡

基於DNS來做負載均衡其實是一種最簡單的實現方案，通過在DNS伺服器上做一個簡單配置即可。

其原理就是： 當用戶訪問域名的時候，會先向DNS伺服器去解析域名對應的IP地址，這個時候我們可以讓DNS伺服器根據不同地理位置的使用者返回不同的IP。比如南方的使用者就返回我們在廣州業務伺服器的IP，北方的使用者來訪問的話，我就返回北京業務伺服器所在的IP。

在這個模式下，使用者就相當於實現了按照「就近原則」將請求分流了，既減輕了單個叢集的負載壓力，也提升了使用者的訪問速度。

使用DNS做負載均衡的方案，天然的優勢就是配置簡單，實現成本非常低，無需額外的開發和維護工作。

但是它也有一個明顯的缺點： 當配置修改後，生效不及時。這個是由於DNS的特性導致的，DNS一般會有多級快取，所以當我們修改了DNS配置之後，由於快取的原因，會導致IP變更不及時，從而影響負載均衡的效果。

另外，使用DNS做負載均衡的話，大多是基於地域或者乾脆直接做IP輪詢，沒有更高階的路由策略，所以這也是DNS方案的侷限所在。

4.2 基於硬體負載均衡

硬體的負載均衡那就比較牛逼了，比如大名鼎鼎的 F5 Network Big-IP，也就是我們常說的 F5，它是一個網路裝置，你可以簡單的理解成類似於網路交換機的東西，完全通過硬體來抗壓力，效能是非常的好，每秒能處理的請求數達到百萬級，即幾百萬/秒的負載，當然價格也就非常非常貴了，十幾萬到上百萬人民幣都有。

因為這類裝置一般用在大型網際網路公司的流量入口最前端，以及政府、國企等不缺錢企業會去使用。一般的中小公司是不捨得用的。

採用 F5 這類硬體做負載均衡的話，主要就是省心省事，買一臺就搞定，效能強大，一般的業務不在話下。而且在負載均衡的演算法方面還支援很多靈活的策略，同時還具有一些防火牆等安全功能。但是缺點也很明顯，一個字：貴。

4.3 基於軟體負載均衡

軟體負載均衡是指使用軟體的方式來分發和均衡流量。軟體負載均衡分為7層協議和 4層協議。

網路協議有七層，基於第四層傳輸層來做流量分發的方案稱為4層負載均衡，例如 LVS；而基於第七層應用層來做流量分發的稱為7層負載均衡，例如 Nginx。這兩種在效能和靈活性上是有些區別的。

基於4層的負載均衡效能要高一些，一般能達到幾十萬/秒的處理量，而基於7層的負載均衡處理量一般只在幾萬/秒。

基於軟體的負載均衡的特點也很明顯，便宜。在正常的伺服器上部署即可，無需額外採購，就是投入一點技術去優化優化即可，因此這種方式是網際網路公司中用得最多的一種方式。

5、常用的均衡演算法有哪些？

上面講完了常見的負載均衡技術方案，那麼接下來咱們看一下，在實際方案應用中，一般可以使用哪些均衡演算法？

主要的均衡演算法有：

1）輪詢策略；

2）負載度策略；

3）響應策略；

4）雜湊策略。

下面來分別介紹一下這幾種均衡演算法/策略的特點。

5.1 輪詢策略

輪詢策略其實很好理解，就是當用戶請求來了之後，「負載均衡器」將請求輪流的轉發到後端不同的業務伺服器上。這個策略在DNS方案中用的比較多，無需關注後端服務的狀態，只藥有請求，就往後端輪流轉發，非常的簡單、實用。

在實際應用中，輪詢也會有多種方式，有按順序輪詢的、有隨機輪詢的、還有按照權重來輪詢的。前兩種比較好理解，第三種按照權重來輪詢，是指給每臺後端服務設定一個權重值，比如效能高的伺服器權重高一些，效能低的伺服器給的權重低一些，這樣設定的話，分配流量的時候，給權重高的更多流量，可以充分的發揮出後端機器的效能。

5.2 負載度策略

負載度策略是指當「負載均衡器」往後端轉發流量的時候，會先去評估後端每臺伺服器的負載壓力情況，對於壓力比較大的後端伺服器轉發的請求就少一些，對於壓力比較小的後端伺服器可以多轉發一些請求給它。

這種方式就充分的結合了後端伺服器的執行狀態，來動態的分配流量了，比輪詢的方式更為科學一些。

但是這種方式也帶來了一些弊端，因為需要動態的評估後端伺服器的負載壓力，那這個「負載均衡器」除了轉發請求以外，還要做很多額外的工作，比如採集連線數、請求數、CPU負載指標、IO負載指標等等，通過對這些指標進行計算和對比，判斷出哪一臺後端伺服器的負載壓力較大。

因此這種方式帶來了效果優勢的同時，也增加了「負載均衡器」的實現難度和維護成本。

5.3 響應策略

響應策略是指，當用戶請求過來的時候，「負載均衡器」會優先將請求轉發給當前時刻響應最快的後端伺服器。

也就是說，不管後端伺服器負載高不高，也不管配置如何，只要覺得這個伺服器在當前時刻能最快的響應使用者的請求，那麼就優先把請求轉發給它，這樣的話，對於使用者而言，體驗也最好。

那「負載均衡器」是怎麼知道哪一臺後端服務在當前時刻響應能力最佳呢？

這就需要「負載均衡器」不停的去統計每一臺後端伺服器對請求的處理速度了，比如一分鐘統計一次，生成一個後端伺服器處理速度的排行榜。然後「負載均衡器」根據這個排行榜去轉發服務。

那麼這裡的問題就是統計的成本了，不停的做這些統計運算本身也會消耗一些效能，同時也會增加「負載均衡器」的實現難度和維護成本。

5.4 雜湊策略

Hash策略也比較好理解，就是將請求中的某個資訊進行hash計算，然後根據後端伺服器臺數取模，得到一個值，算出相同值的請求就被轉發到同一臺後端伺服器中。

常見的用法是對使用者的IP或者ID進行這個策略，然後「負載均衡器」就能保證同一個IP來源或者同一個使用者永遠會被送到同一個後端伺服器上了，一般用於處理快取、會話等功能的時候特別好用。

6、本文小結

基於運營成本的考慮，目前在網際網路專案中，HTTP服務端的負載均衡的具體解決方案，用的最多的還是Nginx（及其分支，比如淘寶的Tengin），如果有時間，建議可以把Nginx下載下來，仔細研究研究它的負載均衡原理，以及它所提供的幾種負載均衡演算法，理論聯絡實際來學習就更能促進你對相關知識的理解和掌握了。

得益於Nginx這種開源免費的高效能方案，它們間接地促進了網際網路的繁榮，感謝這些偉大開源方案背後的無私貢獻者們！