分佈式系統關注點——僅需這一篇，吃透「負載均衡」

1、「負載均衡」是什麼

正如題圖所示的這樣，由一個獨立的統一入口來收斂流量，再作二次分發的過程就是「負載均衡」，它的本質和「分佈式系統」同樣，是「分治」。



    若是你們習慣了開車的時候用一些導航軟件，咱們會發現，導航軟件的推薦路線方案會有一個數量的上限，好比3條、5條。所以，其實本質上它也起到了一個相似「負載均衡」的做用，由於若是隻能取Top3的通暢路線，天然擁堵嚴重的路線就沒法推薦給你了，使得車流的壓力被分攤到了相對空閒的路線上。



    在軟件系統中也是同樣的道理，爲了不流量分攤不均，形成局部節點負載過大（如CPU吃緊等），因此引入一個獨立的統一入口來作相似上面的「導航」的工做。可是，軟件系統中的「負載均衡」與導航的不一樣在於，導航是一個柔性策略，最終仍是須要使用者作選擇，而前者則不一樣。



    怎麼均衡的背後是策略在起做用，而策略的背後是由某些算法或者說邏輯來組成的。好比，導航中的算法屬於「路徑規劃」範疇，在這個範疇內又細分爲「靜態路徑規劃」和「動態路徑規劃」，而且，在不一樣的分支下還有各類具體計算的算法實現，如Dijikstra、A*等。一樣的，在軟件系統中的負載均衡，也有不少算法或者說邏輯在支撐着這些策略，巧的是也有靜態和動態之分。

2、經常使用「負載均衡」策略圖解

下面來羅列一下平常工做中最多見的5種策略。

01 輪詢

　　這是最經常使用也最簡單策略，平均分配，人人都有、一人一次。大體的代碼以下。

複製代碼
int globalIndex = 0; //注意是全局變量，不是局部變量。

try
{

return servers[globalIndex];

}
finally
{

globalIndex++;
if (globalIndex == 3)
    globalIndex = 0;

}
複製代碼

02 加權輪詢

在輪詢的基礎上，增長了一個權重的概念。權重是一個泛化後的概念，能夠用任意方式來體現，本質上是一個能者多勞思想。好比，能夠根據宿主的性能差別配置不一樣的權重。大體的代碼以下。

複製代碼
int matchedIndex = -1;
int total = 0;

for (int i = 0; i < servers.Length; i++)
{

servers[i].cur_weight += servers[i].weight;//①每次循環的時候作自增（步長=權重值）
  total += servers[i].weight;//②將每一個節點的權重值累加到彙總值中
  if (matchedIndex == -1 || servers[matchedIndex].cur_weight < servers[i].cur_weight) //③若是 當前節點的自增數 > 當前待返回節點的自增數，則覆蓋。
  {
        matchedIndex = i;
  }

}

servers[matchedIndex].cur_weight -= total;//④被選取的節點減去②的彙總值，以下降下一次被選舉時的初始權重值。
return servers[matchedIndex];
複製代碼

這段代碼的過程以下圖的表格。"()"中的數字就是自增數，代碼中的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」

03 最少鏈接數

這是一種根據實時的負載狀況，進行動態負載均衡的方式。維護好活動中的鏈接數量，而後取最小的返回便可。大體的代碼以下。

var matchedServer = servers.orderBy(e => e.active_conns).first();

matchedServer.active_conns += 1;

return matchedServer;

//在鏈接關閉時還需對active_conns作減1的動做。
複製代碼

04 最快響應

這也是一種動態負載均衡策略，它的本質是根據每一個節點對過去一段時間內的響應狀況來分配，響應越快分配的越多。具體的運做方式也有不少，上圖的這種能夠理解爲，將最近一段時間的請求耗時的平均值記錄下來，結合前面的「加權輪詢」來處理，因此等價於2：1：3的加權輪詢。



    題外話：通常來講，同機房下的延遲基本沒什麼差別，響應時間的差別主要在服務的處理能力上。若是在跨地域（例：浙江->上海，仍是浙江->北京）的一些請求處理中運用，大多數狀況會使用定時「ping」的方式來獲取延遲狀況，由於是OSI的L3轉發，數據更乾淨，準確性更高。

05 Hash法

hash法的負載均衡與以前的幾種不一樣在於，它的結果是由客戶端決定的。經過客戶端帶來的某個標識通過一個標準化的散列函數進行打散分攤。



    上圖中的散列函數運用的是最簡單粗暴的「取餘法」。

    題外話：散列函數除了取餘以外，還有諸如「變基」、「摺疊」、「平方取中法」等等，此處不作展開，有興趣的小夥伴可自行查閱資料。



    另外，被求餘的參數其實能夠是任意的，只要最終轉化成一個整數參與運算便可。最經常使用的應該是用來源ip地址做爲參數，這樣能夠確保相同的客戶端請求儘量落在同一臺服務器上。

3、經常使用「負載均衡」策略優缺點和適用場景

咱們知道，沒有完美的事物，負載均衡策略也是同樣。上面列舉的這些最經常使用的策略也有各自的優缺點和適用場景，我稍做了整理，以下。

這些負載均衡算法之因此經常使用也是由於簡單，想要更優的效果，必然就須要更高的複雜度。好比，能夠將簡單的策略組合使用、或者經過更多維度的數據採樣來綜合評估、甚至是基於進行數據挖掘後的預測算法來作。

4、用「健康探測」來保障高可用

不論是什麼樣的策略，不免會遇到機器故障或者程序故障的狀況。因此要確保負載均衡能更好的起到效果，還須要結合一些「健康探測」機制。定時的去探測服務端是否是還能連上，響應是否是超出預期的慢。若是節點屬於「不可用」的狀態的話，須要將這個節點臨時從待選取列表中移除，以提升可用性。通常經常使用的「健康探測」方式有3種。

此我向你們推薦一個Java學習交流羣。交流學習羣號：874811168 裏面會分享一些資深架構師錄製的視頻錄像：有Spring，MyBatis，Netty源碼分析，高併發、高性能、分佈式、微服務架構的原理，JVM性能優化、分佈式架構等這些成爲架構師必備的知識體系。還能領取免費的學習資源，一塊兒學習，一塊兒進步，目前受益良多。

01 HTTP探測

使用Get/Post的方式請求服務端的某個固定的URL，判斷返回的內容是否符合預期。通常使用Http狀態碼、response中的內容來判斷。

02 TCP探測

基於Tcp的三次握手機制來探測指定的IP + 端口。最佳實踐能夠借鑑阿里雲的SLB機制，以下圖。

▲圖片來源於阿里雲，版權歸原做者全部

值得注意的是，爲了儘早釋放鏈接，在三次握手結束後立馬跟上RST來中斷TCP鏈接。

03 UDP探測

可能有部分應用使用的UDP協議。在此協議下能夠經過報文來進行探測指定的IP + 端口。最佳實踐一樣能夠借鑑阿里雲的SLB機制，以下圖。

▲圖片來源於阿里雲，版權歸原做者全部

結果的斷定方式是：在服務端沒有返回任何信息的狀況下，默認正常狀態。不然會返回一個ICMP的報錯信息。

5、結語

用一句話來歸納負載均衡的本質是：

    將請求或者說流量，以指望的規則分攤到多個操做單元上進行執行。

    經過它能夠實現橫向擴展（scale out），將冗餘的做用發揮爲「高可用」。另外，還能夠物盡其用，提高資源使用率。