關於負載均衡的一切:總結與思考

發表於2018-01-02

古人云,不患寡而患不均。

在計算機的世界,這就是大家耳熟能詳的負載均衡(load balancing),所謂負載均衡,就是說如果一組計算機節點(或者一組程式)提供相同的(同質的)服務,那麼對服務的請求就應該均勻的分攤到這些節點上。負載均衡的前提一定是“provide a single Internet service from multiple servers”, 這些提供服務的節點被稱之為server farm、server pool或者backend servers。

這裡的服務是廣義的,可以是簡單的計算,也可能是資料的讀取或者儲存。負載均衡也不是新事物,這種思想在多核CPU時代就有了,只不過在分散式系統中,負載均衡更是無處不在,這是分散式系統的天然特性決定的,分散式就是利用大量計算機節點完成單個計算機無法完成的計算、儲存服務,既然有大量計算機節點,那麼均衡的排程就非常重要。

負載均衡的意義在於,讓所有節點以最小的代價、最好的狀態對外提供服務,這樣系統吞吐量最大,效能更高,對於使用者而言請求的時間也更小。而且,負載均衡增強了系統的可靠性,最大化降低了單個節點過載、甚至crash的概率。不難想象,如果一個系統絕大部分請求都落在同一個節點上,那麼這些請求響應時間都很慢,而且萬一節點降級或者崩潰,那麼所有請求又會轉移到下一個節點,造成雪崩。

事實上,網上有很多文章介紹負載均衡的演算法,大多都是大同小異。本文更多的是自己對這些演算法的總結與思考。

一分鐘瞭解負載均衡的一切

本章節的標題和內容都來自一分鐘瞭解負載均衡的一切這一篇文章。當然,原文的標題是誇張了點,不過文中列出了在一個大型web網站中各層是如何用到負載均衡的,一目瞭然。

常見網際網路分散式架構如上,分為客戶端層、反向代理nginx層、站點層、服務層、資料層。可以看到,每一個下游都有多個上游呼叫,只需要做到,每一個上游都均勻訪問每一個下游,就能實現“將請求/資料【均勻】分攤到多個操作單元上執行”。

(1)【客戶端層】到【反向代理層】的負載均衡,是通過“DNS輪詢”實現的
(2)【反向代理層】到【站點層】的負載均衡,是通過“nginx”實現的
(3)【站點層】到【服務層】的負載均衡,是通過“服務連線池”實現的
(4)【資料層】的負載均衡,要考慮“資料的均衡”與“請求的均衡”兩個點,常見的方式有“按照範圍水平切分”與“hash水平切分”。

資料層的負載均衡,在我之前的《帶著問題學習分散式系統之資料分片》中有詳細介紹。

演算法衡量

在我看來,當我們提到一個負載均衡演算法,或者具體的應用場景時,應該考慮以下問題

第一,是否意識到不同節點的服務能力是不一樣的,比如CPU、記憶體、網路、地理位置

第二,是否意識到節點的服務能力是動態變化的,高配的機器也有可能由於一些突發原因導致處理速度變得很慢

第三,是否考慮將同一個客戶端,或者說同樣的請求分發到同一個處理節點,這對於“有狀態”的服務非常重要,比如session,比如分散式儲存

第四,誰來負責負載均衡,即誰充當負載均衡器(load balancer),balancer本身是否會成為瓶頸

下面會結合具體的演算法來考慮這些問題

負載均衡演算法

輪詢演算法(round-robin)

思想很簡單,就是提供同質服務的節點逐個對外提供服務,這樣能做到絕對的均衡。Python示例程式碼如下

可以看到,所有的節點都是以同樣的概率提供服務,即沒有考慮到節點的差異,也許同樣數目的請求,高配的機器CPU才20%,低配的機器CPU已經80%了

加權輪詢演算法(weight round-robin)

加權輪訓演算法就是在輪訓演算法的基礎上,考慮到機器的差異性,分配給機器不同的權重,能者多勞。注意,這個權重的分配依賴於請求的型別,比如計算密集型,那就考慮CPU、記憶體;如果是IO密集型,那就考慮磁碟效能。Python示例程式碼如下

隨機演算法(random)

這個就更好理解了,隨機選擇一個節點服務,按照概率,只要請求數量足夠多,那麼也能達到絕對均衡的效果。而且實現簡單很多

加權隨機演算法(random)

如同加權輪訓演算法至於輪訓演算法一樣,也是在隨機的時候引入不同節點的權重,實現也很類似。

當然,如果節點列表以及權重變化不大,那麼也可以對所有節點歸一化,然後按概率區間選擇

雜湊法(hash)

根據客戶端的IP,或者請求的“Key”,計算出一個hash值,然後對節點數目取模。好處就是,同一個請求能夠分配到同樣的服務節點,這對於“有狀態”的服務很有必要

只要hash結果足夠分散,也是能做到絕對均衡的。

一致性雜湊

雜湊演算法的缺陷也很明顯,當節點的數目發生變化的時候,請求會大概率分配到其他的節點,引發到一系列問題,比如sticky session。而且在某些情況,比如分散式儲存,是絕對的不允許的。

為了解決這個雜湊演算法的問題,又引入了一致性雜湊演算法,簡單來說,一個物理節點與多個虛擬節點對映,在hash的時候,使用虛擬節點數目而不是物理節點數目。當物理節點變化的時候,虛擬節點的數目無需變化,只涉及到虛擬節點的重新分配。而且,調整每個物理節點對應的虛擬節點數目,也就相當於每個物理節點有不同的權重

最少連線演算法(least connection)

以上的諸多演算法,要麼沒有考慮到節點間的差異(輪訓、隨機、雜湊),要麼節點間的權重是靜態分配的(加權輪訓、加權隨機、一致性hash)。

考慮這麼一種情況,某臺機器出現故障,無法及時處理請求,但新的請求還是會以一定的概率源源不斷的分配到這個節點,造成請求的積壓。因此,根據節點的真實負載,動態地調整節點的權重就非常重要。當然,要獲得接節點的真實負載也不是一概而論的事情,如何定義負載,負載的收集是否及時,這都是需要考慮的問題。

每個節點當前的連線數目是一個非常容易收集的指標,因此lease connection是最常被人提到的演算法。也有一些側重不同或者更復雜、更客觀的指標,比如最小響應時間(least response time)、最小活躍數(least active)等等。

一點思考

有狀態的請求

首先來看看“演算法衡量”中提到的第三個問題:同一個請求是否分發到同樣的服務節點,同一個請求指的是同一個使用者或者同樣的唯一標示。什麼時候同一請求最好(必須)分發到同樣的服務節點呢?那就是有狀態 — 請求依賴某些存在於記憶體或者磁碟的資料,比如web請求的session,比如分散式儲存。怎麼實現呢,有以下幾種辦法:

(1)請求分發的時候,保證同一個請求分發到同樣的服務節點。

這個依賴於負載均衡演算法,比如簡單的輪訓,隨機肯定是不行的,雜湊法在節點增刪的時候也會失效。可行的是一致性hash,以及分散式儲存中的按範圍分段(即記錄哪些請求由哪個服務節點提供服務),代價是需要在load balancer中維護額外的資料。

(2)狀態資料在backend servers之間共享

保證同一個請求分發到同樣的服務節點,這個只是手段,目的是請求能使用到對應的狀態資料。如果狀態資料能夠在服務節點之間共享,那麼也能達到這個目的。比如服務節點連線到共享資料庫,或者記憶體資料庫如memcached

(3)狀態資料維護在客戶端

這個在web請求中也有使用,即cookie,不過要考慮安全性,需要加密。

關於load balancer

接下來回答第四個問題:關於load balancer,其實就是說,在哪裡做負載均衡,是客戶端還是服務端,是請求的發起者還是請求的3。具體而言,要麼是在客戶端,根據服務節點的資訊自行選擇,然後將請求直接傳送到選中的服務節點;要麼是在服務節點叢集之前放一個集中式代理(proxy),由代理負責請求求分發。不管哪一種,至少都需要知道當前的服務節點列表這一基礎資訊。

如果在客戶端實現負載均衡,客戶端首先得知道伺服器列表,要麼是靜態配置,要麼有簡單介面查詢,但backend server的詳細負載資訊,就不適用通過客戶端來查詢。因此,客戶端的負載均衡演算法要麼是比較簡單的,比如輪訓(加權輪訓)、隨機(加權隨機)、雜湊這幾種演算法,只要每個客戶端足夠隨機,按照大數定理,服務節點的負載也是均衡的。要在客戶端使用較為複雜的演算法,比如根據backend的實際負載,那麼就需要去額外的負載均衡服務(external load balancing service)查詢到這些資訊,在grpc中,就是使用的這種辦法

可以看到,load balancer與grpc server通訊,獲得grpc server的負載等具體詳細,然後grpc client從load balancer獲取這些資訊,最終grpc client直連到被選擇的grpc server。

而基於Proxy的方式是更為常見的,比如7層的Nginx,四層的F5、LVS,既有硬體路由,也有軟體分發。集中式的特點在於方便控制,而且能容易實現一些更精密,更復雜的演算法。但缺點也很明顯,一來負載均衡器本身可能成為效能瓶頸;二來可能引入額外的延遲,請求一定先發到達負載均衡器,然後到達真正的服務節點。

load balance proxy對於請求的響應(response),要麼不經過proxy,如LVS;要麼經過Proxy,如Nginx。下圖是LVS示意圖(來源見水印)

而如果response也是走load balancer proxy的話,那麼整個服務過程對客戶端而言就是完全透明的,也防止了客戶端去嘗試連線後臺伺服器,提供了一層安全保障!

值得注意的是,load balancer proxy不能成為單點故障(single point of failure),因此一般會設計為高可用的主從結構

 其他

這篇文章中提到,負載均衡是一種推模型,一定會選出一個服務節點,然後把請求推送過來。而換一種思路,使用訊息佇列,就變成了拉模型:空閒的服務節點主動去拉取請求進行處理,各個節點的負載自然也是均衡的。訊息佇列相比負載均衡好處在於,服務節點不會被大量請求沖垮,同時增加服務節點更加容易;缺點也很明顯,請求不是事實處理的。

想到另外一個例子,比如在gunicorn這種pre-fork模型中,master(gunicorn 中Arbiter)會fork出指定數量的worker程式,worker程式在同樣的埠上監聽,誰先監聽到網路連線請求,誰就提供服務,這也是worker程式之間的負載均衡。

references

wiki:Load balancing

一分鐘瞭解負載均衡的一切

grpc load-balancing.md

相關文章