負載均衡簡介

轉自：http://developer.51cto.com/art/201810/585029.htm

由一個獨立的統一入口來收斂流量，再做二次分發的過程就是負載均衡，它的本質和分散式系統一樣，是分治。在軟體系統中的負載均衡，有很多演算法或者說邏輯在支撐著這些策略，主要有靜態和動態之分。

常用負載均衡策略圖解

下面來羅列一下日常工作中最常見的 5 種策略。

輪詢

這是最常用也最簡單策略，平均分配，人人都有、一人一次。

加權輪詢

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

最少連線數

這是一種根據實時的負載情況，進行動態負載均衡的方式。維護好活動中的連線數量，然後取最小的返回即可。

最快響應

這也是一種動態負載均衡策略，它的本質是根據每個節點對過去一段時間內的響應情況來分配，響應越快分配的越多。

具體的運作方式也有很多，上圖的這種可以理解為，將最近一段時間的請求耗時的平均值記錄下來，結合前面的加權輪詢來處理，所以等價於 2：1：3 的加權輪詢。

題外話：一般來說，同機房下的延遲基本沒什麼差異，響應時間的差異主要在服務的處理能力上。

如果在跨地域(例：浙江->上海，還是浙江->北京)的一些請求處理中運用，大多數情況會使用定時「Ping」的方式來獲取延遲情況，因為是 OSI 的 L3 轉發，資料更乾淨，準確性更高。

Hash 法

Hash 法的負載均衡與之前的幾種不同在於，它的結果是由客戶端決定的。通過客戶端帶來的某個標識經過一個標準化的雜湊函式進行打散分攤。上圖中的雜湊函式運用的是最簡單粗暴的取餘法。

題外話：雜湊函式除了取餘之外，還有諸如變基、摺疊、平方取中法等等，此處不做展開，有興趣的小夥伴可自行查閱資料。

另外，被求餘的引數其實可以是任意的，只要最終轉化成一個整數參與運算即可。

最常用的應該是用來源 IP 地址作為引數，這樣可以確保相同的客戶端請求儘可能落在同一臺伺服器上。

常用負載均衡策略優缺點和適用場景

我們知道，沒有完美的事物，負載均衡策略也是一樣。上面列舉的這些最常用的策略也有各自的優缺點和適用場景，具體如下：

這些負載均衡演算法之所以常用也是因為簡單，想要更優的效果，必然就需要更高的複雜度。

比如，可以將簡單的策略組合使用、或者通過更多維度的資料取樣來綜合評估、甚至是基於進行資料探勘後的預測演算法來做。

用健康探測來保障高可用

不管是什麼樣的策略，難免會遇到機器故障或者程式故障的情況。所以要確保負載均衡能更好的起到效果，還需要結合一些健康探測機制。定時的去探測服務端是不是還能連上，響應是不是超出預期的慢。

如果節點屬於“不可用”的狀態的話，需要將這個節點臨時從待選取列表中移除，以提高可用性。一般常用的健康探測方式有 3 種。

HTTP 探測

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

TCP 探測

基於 TCP 的三次握手機制來探測指定的 IP + 埠。最佳實踐可以借鑑阿里雲的 SLB 機制，如下圖：

圖片來源於阿里雲，版權歸原作者所有

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

UDP 探測

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

圖片來源於阿里雲，版權歸原作者所有

結果的判定方式是：在服務端沒有返回任何資訊的情況下，預設是正常狀態。否則會返回一個 ICMP 的報錯資訊。

結語

用一句話來概括負載均衡的本質是：將請求或者說流量，以期望的規則分攤到多個操作單元上進行執行。

通過它可以實現橫向擴充套件(scale out)，將冗餘的作用發揮為高可用。另外，還可以物盡其用，提升資源使用率。