不懂高性能的負載均衡設計？沒關系，架構師帶你飛

在軟體系統的架構設計中，對叢集的負載均衡設計是作為高性能系統優化環節中必不可少的方案。負載均衡本質上是用于将使用者流量進行均衡減壓的，是以在網際網路的大流量項目中，其重要性不言而喻。

一、什麼是負載均衡？

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

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

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

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

（可以按照圖中去了解，圖檔來源網絡）

二、負載均衡方案有幾種？

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

基于DNS負載均衡

基于硬體負載均衡

基于軟體負載均衡

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

（網絡圖檔）

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

輪詢政策

負載度政策

響應政策

哈希政策

下面來分别介紹一下這幾種均衡算法/政策的特點：

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

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

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

這種方式就充分的結合了後端伺服器的運作狀态，來動态的配置設定流量了，比輪詢的方式更為科學一些。

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

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

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

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

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

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

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

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

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

以上，就是實作高性能負載均衡的常見技術方案和政策了，歡迎大家一起交流。

為什麼某些人會一直比你優秀，是因為他本身就很優秀還一直在持續努力變得更優秀，而你是不是還在滿足于現狀内心在竊喜？

歡迎工作一到五年的Java工程師朋友們加入Java架構開發：744677563

群内提供免費的Java架構學習資料（裡面有高可用、高并發、高性能及分布式、Jvm性能調優、Spring源碼，MyBatis，Netty,Redis,Kafka,Mysql,Zookeeper,Tomcat,Docker,Dubbo,Nginx等多個知識點的架構資料）合理利用自己每一分每一秒的時間來學習提升自己，不要再用"沒有時間“來掩飾自己思想上的懶惰！趁年輕，使勁拼，給未來的自己一個交代！