查看: 560|回復: 0

僅需這一篇,帶你吃透「負載均衡」!

發表于 2018-10-24 16:21:01
一、「負載均衡」是什么
正如題圖所示的這樣,由一個獨立的統一入口來收斂流量,再做二次分發的過程就是「負載均衡」,它的本質和「分布式系統」一樣,是「分治」。
如果大家習慣了開車的時候用一些導航軟件,我們會發現,導航軟件的推薦路線方案會有一個數量的上限,比如3條、5條。因此,其實本質上它也起到了一個類似「負載均衡」的作用,因為如果只能取Top3的通暢路線,自然擁堵嚴重的路線就無法推薦給你了,使得車流的壓力被分攤到了相對空閑的路線上。
在軟件系統中也是一樣的道理,為了避免流量分攤不均,造成局部節點負載過大(如CPU吃緊等),所以引入一個獨立的統一入口來做類似上面的“導航”的工作。但是,軟件系統中的「負載均衡」與導航的不同在于,導航是一個柔性策略,最終還是需要使用者做選擇,而前者則不同。
怎么均衡的背后是策略在起作用,而策略的背后是由某些算法或者說邏輯來組成的。比如,導航中的算法屬于「路徑規劃」范疇,在這個范疇內又細分為「靜態路徑規劃」和「動態路徑規劃」,并且,在不同的分支下還有各種具體計算的算法實現,如Dijikstra、A*等。同樣的,在軟件系統中的負載均衡,也有很多算法或者說邏輯在支撐著這些策略,巧的是也有靜態和動態之分。
二、常用「負載均衡」策略圖解
下面來羅列一下日常工作中最常見的5種策略。
1、輪詢




這是最常用也最簡單策略,平均分配,人人都有、一人一次。大致的代碼如下。




2、加權輪詢




在輪詢的基礎上,增加了一個權重的概念。權重是一個泛化后的概念,可以用任意方式來體現,本質上是一個能者多勞思想。比如,可以根據宿主的性能差異配置不同的權重。大致的代碼如下:




這段代碼的過程如下圖的表格。"()"中的數字就是自增數,代碼中的cur_weight。




值得注意的是,加權輪詢本身還有不同的實現方式,雖說最終的比例都是2:1:2。但是在請求送達的先后順序上可以所有不同。比如「5-4,3,2-1」和上面的案例相比,最終比例是一樣的,但是效果不同。「5-4,3,2-1」更容易產生并發問題,導致服務端擁塞,且這個問題隨著權重數字越大越嚴重。例子:10:5:3的結果是「18-17-16-15-14-13-12-11-10-9,8-7-6-5-4,3-2-1」
在此我向大家推薦一個java學習交流群。交流學習群號:874811168 里面會分享一些資深架構師錄制的視頻錄像:有Spring,MyBatis,Netty源碼分析,高并發、高性能、分布式、微服務架構的原理,JVM性能優化、分布式架構等這些成為架構師必備的知識體系。還能領取免費的學習資源,一起學習,一起進步,目前受益良多。
3、最少連接數




這是一種根據實時的負載情況,進行動態負載均衡的方式。維護好活動中的連接數量,然后取最小的返回即可。大致的代碼如下。




4、最快響應




這也是一種動態負載均衡策略,它的本質是根據每個節點對過去一段時間內的響應情況來分配,響應越快分配的越多。具體的運作方式也有很多,上圖的這種可以理解為,將最近一段時間的請求耗時的平均值記錄下來,結合前面的「加權輪詢」來處理,所以等價于2:1:3的加權輪詢。
題外話:一般來說,同機房下的延遲基本沒什么差異,響應時間的差異主要在服務的處理能力上。如果在跨地域(例:浙江->上海,還是浙江->北京)的一些請求處理中運用,大多數情況會使用定時「ping」的方式來獲取延遲情況,因為是OSI的L3轉發,數據更干凈,準確性更高。
5、Hash法




hash法的負載均衡與之前的幾種不同在于,它的結果是由客戶端決定的。通過客戶端帶來的某個標識經過一個標準化的散列函數進行打散分攤。
上圖中的散列函數運用的是最簡單粗暴的「取余法」。
題外話:散列函數除了取余之外,還有諸如「變基」、「折疊」、「平方取中法」等等,此處不做展開,有興趣的小伙伴可自行查閱資料。
另外,被求余的參數其實可以是任意的,只要最終轉化成一個整數參與運算即可。最常用的應該是用來源ip地址作為參數,這樣可以確保相同的客戶端請求盡可能落在同一臺服務器上。
三、常用「負載均衡」策略優缺點和適用場景
我們知道,沒有完美的事物,負載均衡策略也是一樣。上面列舉的這些最常用的策略也有各自的優缺點和適用場景,我稍作了整理,如下。




這些負載均衡算法之所以常用也是因為簡單,想要更優的效果,必然就需要更高的復雜度。比如,可以將簡單的策略組合使用、或者通過更多維度的數據采樣來綜合評估、甚至是基于進行數據挖掘后的預測算法來做。
四、用「健康探測」來保障高可用
不管是什么樣的策略,難免會遇到機器故障或者程序故障的情況。所以要確保負載均衡能更好的起到效果,還需要結合一些「健康探測」機制。定時的去探測服務端是不是還能連上,響應是不是超出預期的慢。如果節點屬于“不可用”的狀態的話,需要將這個節點臨時從待選取列表中移除,以提高可用性。一般常用的「健康探測」方式有3種。
1、HTTP探測
使用Get/Post的方式請求服務端的某個固定的URL,判斷返回的內容是否符合預期。一般使用Http狀態碼、response中的內容來判斷。
2、TCP探測
基于Tcp的三次握手機制來探測指定的IP + 端口。最佳實踐可以借鑒阿里云的SLB機制,如下圖。




值得注意的是,為了盡早釋放連接,在三次握手結束后立馬跟上RST來中斷TCP連接。
3、UDP探測
可能有部分應用使用的UDP協議。在此協議下可以通過報文來進行探測指定的IP + 端口。最佳實踐同樣可以借鑒阿里云的SLB機制,如下圖。




結果的判定方式是:在服務端沒有返回任何信息的情況下,默認正常狀態。否則會返回一個ICMP的報錯信息。
五、結語
用一句話來概括負載均衡的本質是:
將請求或者說流量,以期望的規則分攤到多個操作單元上進行執行。
通過它可以實現橫向擴展(scale out),將冗余的作用發揮為「高可用」。另外,還可以物盡其用,提升資源使用率。
歡迎工作一到五年的java工程師朋友們加入Java填坑之路:860113481
群內提供免費的Java架構學習資料(里面有高可用、高并發、高性能及分布式、Jvm性能調優、Spring源碼,MyBatis,Netty,Redis,Kafka,Mysql,Zookeeper,Tomcat,Docker,Dubbo,Nginx等多個知識點的架構資料)合理利用自己每一分每一秒的時間來學習提升自己,不要再用"沒有時間“來掩飾自己思想上的懶惰!趁年輕,使勁拼,給未來的自己一個交代!



回復

使用道具 舉報