我們都對(duì)高可用有一個(gè)基本的認(rèn)識(shí)，其中負(fù)載均衡是高可用的核心工作。本文將通過(guò)如下幾個(gè)方面，讓你妥妥的吃透“負(fù)載均衡”。

[[246233]]

• 負(fù)載均衡是什么
• 常用負(fù)載均衡策略圖解
• 常用負(fù)載均衡策略優(yōu)缺點(diǎn)和適用場(chǎng)景
• 用健康探測(cè)來(lái)保障高可用
• 結(jié)語(yǔ)

負(fù)載均衡是什么

 

正如上圖所示的這樣，由一個(gè)獨(dú)立的統(tǒng)一入口來(lái)收斂流量，再做二次分發(fā)的過(guò)程就是負(fù)載均衡，它的本質(zhì)和分布式系統(tǒng)一樣，是分治。

如果大家習(xí)慣了開(kāi)車的時(shí)候用一些導(dǎo)航軟件，我們會(huì)發(fā)現(xiàn)，導(dǎo)航軟件的推薦路線方案會(huì)有一個(gè)數(shù)量的上限，比如 3 條、5 條。

因此，其實(shí)本質(zhì)上它也起到了一個(gè)類似負(fù)載均衡的作用，因?yàn)槿绻荒苋?Top3 的通暢路線，自然擁堵嚴(yán)重的路線就無(wú)法推薦給你了，使得車流的壓力被分?jǐn)偟搅讼鄬?duì)空閑的路線上。

在軟件系統(tǒng)中也是一樣的道理，為了避免流量分?jǐn)偛痪斐删植抗?jié)點(diǎn)負(fù)載過(guò)大(如 CPU 吃緊等)，所以引入一個(gè)獨(dú)立的統(tǒng)一入口來(lái)做類似上面的“導(dǎo)航”的工作。

但是，軟件系統(tǒng)中的負(fù)載均衡與導(dǎo)航的不同在于：導(dǎo)航是一個(gè)柔性策略，最終還是需要使用者做選擇，而前者則不同。

怎么均衡的背后是策略在起作用，而策略的背后是由某些算法或者說(shuō)邏輯來(lái)組成的。

比如，導(dǎo)航中的算法屬于路徑規(guī)劃范疇，在這個(gè)范疇內(nèi)又細(xì)分為靜態(tài)路徑規(guī)劃和動(dòng)態(tài)路徑規(guī)劃，并且，在不同的分支下還有各種具體計(jì)算的算法實(shí)現(xiàn)，如 Dijikstra、A* 等。

同樣的，在軟件系統(tǒng)中的負(fù)載均衡，也有很多算法或者說(shuō)邏輯在支撐著這些策略，巧的是也有靜態(tài)和動(dòng)態(tài)之分。

常用負(fù)載均衡策略圖解

下面來(lái)羅列一下日常工作中最常見(jiàn)的 5 種策略。

輪詢

 

這是最常用也最簡(jiǎn)單策略，平均分配，人人都有、一人一次。大致的代碼如下：

int  globalIndex = 0;   //注意是全局變量，不是局部變量。 
 
try 
{ 
 
    return servers[globalIndex]; 
} 
finally 
{ 
    globalIndex++; 
    if (globalIndex == 3) 
        globalIndex = 0; 
} 

加權(quán)輪詢

 

在輪詢的基礎(chǔ)上，增加了一個(gè)權(quán)重的概念。權(quán)重是一個(gè)泛化后的概念，可以用任意方式來(lái)體現(xiàn)，本質(zhì)上是一個(gè)能者多勞思想。

比如，可以根據(jù)宿主的性能差異配置不同的權(quán)重。大致的代碼如下：

int matchedIndex = -1; 
int total = 0; 
 
for (int i = 0; i < servers.Length; i++) 
{ 
      servers[i].cur_weight += servers[i].weight;//①每次循環(huán)的時(shí)候做自增（步長(zhǎng)=權(quán)重值） 
      total += servers[i].weight;//②將每個(gè)節(jié)點(diǎn)的權(quán)重值累加到匯總值中 
      if (matchedIndex == -1 || servers[matchedIndex].cur_weight < servers[i].cur_weight) //③如果 當(dāng)前節(jié)點(diǎn)的自增數(shù) > 當(dāng)前待返回節(jié)點(diǎn)的自增數(shù)，則覆蓋。 
      { 
            matchedIndex = i; 
      } 
} 
 
servers[matchedIndex].cur_weight -= total;//④被選取的節(jié)點(diǎn)減去②的匯總值，以降低下一次被選舉時(shí)的初始權(quán)重值。 
return servers[matchedIndex]; 

這段代碼的過(guò)程如下圖的表格。"()"中的數(shù)字就是自增數(shù)，即代碼中的 cur_weight。

 

值得注意的是，加權(quán)輪詢本身還有不同的實(shí)現(xiàn)方式，雖說(shuō)最終的比例都是 2：1：2。

但是在請(qǐng)求送達(dá)的先后順序上可以有所不同。比如「5-4，3，2-1」和上面的案例相比，最終比例是一樣的，但是效果不同。

「5-4，3，2-1」更容易產(chǎn)生并發(fā)問(wèn)題，導(dǎo)致服務(wù)端擁塞，且這個(gè)問(wèn)題隨著權(quán)重?cái)?shù)字越大越嚴(yán)重。

例子：10：5：3 的結(jié)果是「18-17-16-15-14-13-12-11-10-9，8-7-6-5-4，3-2-1」

最少連接數(shù)

 

這是一種根據(jù)實(shí)時(shí)的負(fù)載情況，進(jìn)行動(dòng)態(tài)負(fù)載均衡的方式。維護(hù)好活動(dòng)中的連接數(shù)量，然后取最小的返回即可。大致的代碼如下：

var matchedServer = servers.orderBy(e => e.active_conns).first(); 
 
matchedServer.active_conns += 1; 
 
return matchedServer; 
 
//在連接關(guān)閉時(shí)還需對(duì)active_conns做減1的動(dòng)作。 

最快響應(yīng)

 

這也是一種動(dòng)態(tài)負(fù)載均衡策略，它的本質(zhì)是根據(jù)每個(gè)節(jié)點(diǎn)對(duì)過(guò)去一段時(shí)間內(nèi)的響應(yīng)情況來(lái)分配，響應(yīng)越快分配的越多。

具體的運(yùn)作方式也有很多，上圖的這種可以理解為，將最近一段時(shí)間的請(qǐng)求耗時(shí)的平均值記錄下來(lái)，結(jié)合前面的加權(quán)輪詢來(lái)處理，所以等價(jià)于 2：1：3 的加權(quán)輪詢。

題外話：一般來(lái)說(shuō)，同機(jī)房下的延遲基本沒(méi)什么差異，響應(yīng)時(shí)間的差異主要在服務(wù)的處理能力上。

如果在跨地域(例：浙江->上海，還是浙江->北京)的一些請(qǐng)求處理中運(yùn)用，大多數(shù)情況會(huì)使用定時(shí)「Ping」的方式來(lái)獲取延遲情況，因?yàn)槭?OSI 的 L3 轉(zhuǎn)發(fā)，數(shù)據(jù)更干凈，準(zhǔn)確性更高。

Hash 法

 

Hash 法的負(fù)載均衡與之前的幾種不同在于，它的結(jié)果是由客戶端決定的。通過(guò)客戶端帶來(lái)的某個(gè)標(biāo)識(shí)經(jīng)過(guò)一個(gè)標(biāo)準(zhǔn)化的散列函數(shù)進(jìn)行打散分?jǐn)?。上圖中的散列函數(shù)運(yùn)用的是最簡(jiǎn)單粗暴的取余法。

題外話：散列函數(shù)除了取余之外，還有諸如變基、折疊、平方取中法等等，此處不做展開(kāi)，有興趣的小伙伴可自行查閱資料。

另外，被求余的參數(shù)其實(shí)可以是任意的，只要最終轉(zhuǎn)化成一個(gè)整數(shù)參與運(yùn)算即可。

最常用的應(yīng)該是用來(lái)源 IP 地址作為參數(shù)，這樣可以確保相同的客戶端請(qǐng)求盡可能落在同一臺(tái)服務(wù)器上。

常用負(fù)載均衡策略優(yōu)缺點(diǎn)和適用場(chǎng)景

我們知道，沒(méi)有完美的事物，負(fù)載均衡策略也是一樣。上面列舉的這些最常用的策略也有各自的優(yōu)缺點(diǎn)和適用場(chǎng)景，我稍作了整理，如下。

 

這些負(fù)載均衡算法之所以常用也是因?yàn)楹?jiǎn)單，想要更優(yōu)的效果，必然就需要更高的復(fù)雜度。

比如，可以將簡(jiǎn)單的策略組合使用、或者通過(guò)更多維度的數(shù)據(jù)采樣來(lái)綜合評(píng)估、甚至是基于進(jìn)行數(shù)據(jù)挖掘后的預(yù)測(cè)算法來(lái)做。

用健康探測(cè)來(lái)保障高可用

不管是什么樣的策略，難免會(huì)遇到機(jī)器故障或者程序故障的情況。所以要確保負(fù)載均衡能更好的起到效果，還需要結(jié)合一些健康探測(cè)機(jī)制。定時(shí)的去探測(cè)服務(wù)端是不是還能連上，響應(yīng)是不是超出預(yù)期的慢。

如果節(jié)點(diǎn)屬于“不可用”的狀態(tài)的話，需要將這個(gè)節(jié)點(diǎn)臨時(shí)從待選取列表中移除，以提高可用性。一般常用的健康探測(cè)方式有 3 種。

HTTP 探測(cè)

使用 Get/Post 的方式請(qǐng)求服務(wù)端的某個(gè)固定的 URL，判斷返回的內(nèi)容是否符合預(yù)期。一般使用 HTTP 狀態(tài)碼、Response 中的內(nèi)容來(lái)判斷。

TCP 探測(cè)

基于 TCP 的三次握手機(jī)制來(lái)探測(cè)指定的 IP + 端口。最佳實(shí)踐可以借鑒阿里云的 SLB 機(jī)制，如下圖：

 

▲圖片來(lái)源于阿里云，版權(quán)歸原作者所有

值得注意的是，為了盡早釋放連接，在三次握手結(jié)束后立馬跟上 RST 來(lái)中斷 TCP 連接。

UDP 探測(cè)

可能有部分應(yīng)用使用的是 UDP 協(xié)議。在此協(xié)議下可以通過(guò)報(bào)文來(lái)進(jìn)行探測(cè)指定的 IP + 端口。最佳實(shí)踐同樣可以借鑒阿里云的 SLB 機(jī)制，如下圖：

 

▲圖片來(lái)源于阿里云，版權(quán)歸原作者所有

結(jié)果的判定方式是：在服務(wù)端沒(méi)有返回任何信息的情況下，默認(rèn)是正常狀態(tài)。否則會(huì)返回一個(gè) ICMP 的報(bào)錯(cuò)信息。

結(jié)語(yǔ)

用一句話來(lái)概括負(fù)載均衡的本質(zhì)是：將請(qǐng)求或者說(shuō)流量，以期望的規(guī)則分?jǐn)偟蕉鄠€(gè)操作單元上進(jìn)行執(zhí)行。

通過(guò)它可以實(shí)現(xiàn)橫向擴(kuò)展(scale out)，將冗余的作用發(fā)揮為高可用。另外，還可以物盡其用，提升資源使用率。