導讀

Dubbo是一個分布式服務(wù)框架，能避免單點故障和支持服務(wù)的橫向擴容。一個服務(wù)通常會部署多個實例。如何從多個服務(wù) Provider 組成的集群中挑選出一個進行調(diào)用，就涉及到一個負載均衡的策略。

負載均衡職責是將網(wǎng)絡(luò)請求或者其他形式的負載“均攤”到不同的服務(wù)節(jié)點上，從而避免服務(wù)集群中部分節(jié)點壓力過大、資源緊張，而另一部分節(jié)點比較空閑的情況。通過合理的負載均衡算法，我們希望可以讓每個服務(wù)節(jié)點獲取到適合自己處理能力的負載，實現(xiàn)處理能力和流量的合理分配。常用的負載均衡可分為軟件負載均衡（比如，日常工作中使用的 Nginx）和硬件負載均衡（主要有 F5、Array、NetScaler 等，不過開發(fā)工程師在實踐中很少直接接觸到）。

Dubbo提供了 5 種負載均衡實現(xiàn)

• 基于 Hash 一致性的 ConsistentHashLoadBalance；
• 基于權(quán)重隨機算法的 RandomLoadBalance；
• 基于最少活躍調(diào)用數(shù)算法的 LeastActiveLoadBalance；
• 基于加權(quán)輪詢算法的 RoundRobinLoadBalance；
• 基于最短響應(yīng)時間的 ShortestResponseLoadBalance 。

LoadBalance 是一個擴展接口，默認使用的擴展實現(xiàn)是 RandomLoadBalance，其定義如下所示，其中的 @Adaptive 注解參數(shù)為 loadbalance，即動態(tài)生成的適配器會按照 URL 中的 loadbalance 參數(shù)值選擇擴展實現(xiàn)類。

@SPI(RandomLoadBalance.NAME)
public interface LoadBalance {
    @Adaptive("loadbalance")
    <T> Invoker<T> select(List<Invoker<T>> invokers, URL url, Invocation invocation) throws RpcException;
}

LoadBalance 接口中 select() 方法的核心功能是根據(jù)傳入的 URL 和 Invocation，以及自身的負載均衡算法，從 Invoker 集合中選擇一個 Invoker 返回。

ConsistentHashLoadBalance(一致性 Hash算法)

底層使用一致性 Hash 算法實現(xiàn)負載均衡。

一致性 Hash 負載均衡可以讓參數(shù)相同的請求每次都路由到相同的服務(wù)節(jié)點上，這種負載均衡策略可以在某些 Provider 節(jié)點下線的時候，讓這些節(jié)點上的流量平攤到其他 Provider 上，不會引起流量的劇烈波動。

假設(shè)現(xiàn)在有 1、2、3 三個 Provider 節(jié)點對外提供服務(wù)，有 100 個請求同時到達，如果想讓請求盡可能均勻地分布到這三個 Provider 節(jié)點上，我們可能想到的最簡單的方法就是 Hash 取模，即 hash(請求參數(shù)) % 3。如果參與 Hash 計算的是請求的全部參數(shù)，那么參數(shù)相同的請求將會落到同一個 Provider 節(jié)點上。不過此時如果突然有一個 Provider 節(jié)點出現(xiàn)宕機的情況，那我們就需要對 2 取模，即請求會重新分配到相應(yīng)的 Provider 之上。在極端情況下，甚至會出現(xiàn)所有請求的處理節(jié)點都發(fā)生了變化，這就會造成比較大的波動。

為了避免因一個 Provider 節(jié)點宕機，而導致大量請求的處理節(jié)點發(fā)生變化的情況，我們可以考慮使用一致性 Hash 算法。一致性 Hash 算法的原理也是取模算法，與 Hash 取模的不同之處在于：Hash 取模是對 Provider 節(jié)點數(shù)量取模，而一致性 Hash 算法是對 2^32 取模。

一致性 Hash 算法需要同時對 Provider 地址以及請求參數(shù)進行取模：

hash(Provider地址) % 2^32

hash(請求參數(shù)) % 2^32

Provider 地址和請求經(jīng)過對 2^32 取模得到的結(jié)果值，都會落到一個 Hash 環(huán)上.

一致性 Hash節(jié)點均勻分布

我們按順時針的方向，依次將請求分發(fā)到對應(yīng)的 Provider。這樣，當某臺 Provider 節(jié)點宕機或增加新的 Provider 節(jié)點時，只會影響這個 Provider 節(jié)點對應(yīng)的請求。

在理想情況下，一致性 Hash 算法會將這三個 Provider 節(jié)點均勻地分布到 Hash 環(huán)上，請求也可以均勻地分發(fā)給這三個 Provider 節(jié)點。但在實際情況中，這三個 Provider 節(jié)點地址取模之后的值，可能差距不大，這樣會導致大量的請求落到一個 Provider 節(jié)點上。就出現(xiàn)了數(shù)據(jù)傾斜的問題。所謂數(shù)據(jù)傾斜是指由于節(jié)點不夠分散，導致大量請求落到了同一個節(jié)點上，而其他節(jié)點只會接收到少量請求的情況。

為了解決一致性 Hash 算法中出現(xiàn)的數(shù)據(jù)傾斜問題，又演化出了 Hash 槽的概念。

Hash 槽解決數(shù)據(jù)傾斜的思路是：既然問題是由 Provider 節(jié)點在 Hash 環(huán)上分布不均勻造成的，那么可以虛擬出 n 組 P1、P2、P3 的 Provider 節(jié)點 ，讓多組 Provider 節(jié)點相對均勻地分布在 Hash 環(huán)上。如下圖所示，相同陰影的節(jié)點均為同一個 Provider 節(jié)點，比如 P1-1、P1-2……P1-99 表示的都是 P1 這個 Provider 節(jié)點。引入 Provider 虛擬節(jié)點之后，讓 Provider 在圓環(huán)上分散開來，以避免數(shù)據(jù)傾斜問題。

RandomLoadBalance(加權(quán)隨機算法)

RandomLoadBalance 是一個簡單、高效的負載均衡實現(xiàn)，它也是 Dubbo 默認使用的 LoadBalance 實現(xiàn)。

下面我們通過隨機數(shù)生成器在 [0, 10) 這個范圍內(nèi)生成一個隨機數(shù)，然后計算這個隨機數(shù)會落到哪個區(qū)間中。例如，隨機生成 4，就會落到 Provider A 對應(yīng)的區(qū)間中，此時 RandomLoadBalance 就會返回 Provider A 這個節(jié)點。

接下來我們再來看 RandomLoadBalance 中 doSelect() 方法的實現(xiàn)，其核心邏輯為三個關(guān)鍵點：

• 計算每個 Invoker 對應(yīng)的權(quán)重值以及總權(quán)重值；
• 當各個 Invoker 權(quán)重值不相等時，計算隨機數(shù)應(yīng)該落在哪個 Invoker 區(qū)間中，返回對應(yīng)的 Invoker 對象；
• 當各個 Invoker 權(quán)重值相同時，隨機返回一個 Invoker 即可。

RandomLoadBalance 經(jīng)過多次請求后，能夠?qū)⒄{(diào)用請求按照權(quán)重值均勻地分配到各個 Provider 節(jié)點上。

LeastActiveLoadBalance(最小活躍數(shù)負載均衡算法)

LeastActiveLoadBalance 使用的是最小活躍數(shù)負載均衡算法。它認為當前活躍請求數(shù)越小的 Provider 節(jié)點，剩余的處理能力越多，處理請求的效率也就越高，那么該 Provider 在單位時間內(nèi)就可以處理更多的請求，所以我們應(yīng)該優(yōu)先將請求分配給該 Provider 節(jié)點。

LeastActiveLoadBalance 需要配合 ActiveLimitFilter 使用，ActiveLimitFilter 會記錄每個接口方法的活躍請求數(shù)，在 LeastActiveLoadBalance 進行負載均衡時，只會從活躍請求數(shù)最少的 Invoker 集合里挑選 Invoker。

在 LeastActiveLoadBalance 的實現(xiàn)中，首先會選出所有活躍請求數(shù)最小的 Invoker 對象，之后的邏輯與RandomLoadBalance 完全一樣，按照這些 Invoker 對象的權(quán)重挑選最終的Invoker 對象。

RoundRobinLoadBalance(加權(quán)輪詢負載均衡算法)

輪詢指的是將請求輪流分配給每個 Provider。例如，有 A、B、C 三個 Provider 節(jié)點，按照普通輪詢的方式，我們會將第一個請求分配給 Provider A，將第二個請求分配給 Provider B，第三個請求分配給 Provider C，第四個請求再次分配給 Provider A……如此循環(huán)往復(fù)。

輪詢是一種無狀態(tài)負載均衡算法，實現(xiàn)簡單，適用于集群中所有 Provider 節(jié)點性能相近的場景。 但現(xiàn)實情況中就很難保證這一點了，因為很容易出現(xiàn)集群中性能最好和最差的 Provider 節(jié)點處理同樣流量的情況，這就可能導致性能差的 Provider 節(jié)點各方面資源非常緊張，甚至無法及時響應(yīng)了，但是性能好的 Provider 節(jié)點的各方面資源使用還較為空閑。這時我們可以通過加權(quán)輪詢的方式，降低分配到性能較差的 Provider 節(jié)點的流量。

加權(quán)之后，分配給每個 Provider 節(jié)點的流量比會接近或等于它們的權(quán)重比。例如，Provider 節(jié)點 A、B、C 權(quán)重比為 5:1:1，那么在 7 次請求中，節(jié)點 A 將收到 5 次請求，節(jié)點 B 會收到 1 次請求，節(jié)點 C 則會收到 1 次請求。

ShortestResponseLoadBalance(最短響應(yīng)時間的負載均衡算法)

ShortestResponseLoadBalance 是Dubbo 2.7 版本之后新增加的一個 LoadBalance 實現(xiàn)類。它實現(xiàn)了最短響應(yīng)時間的負載均衡算法，也就是從多個 Provider 節(jié)點中選出調(diào)用成功的且響應(yīng)時間最短的 Provider 節(jié)點，不過滿足該條件的 Provider 節(jié)點可能有多個，所以還要再使用隨機算法進行一次選擇，得到最終要調(diào)用的 Provider 節(jié)點。

以上就是Dubbo的負載均衡(LoadBalance)原理的詳細內(nèi)容，更多關(guān)于Dubbo 負載均衡的資料請關(guān)注腳本之家其它相關(guān)文章！

最新評論