零、需求緣起

第一篇文章“一分鐘了解負載均衡”和大家share了互聯網架構中反向代理層、站點層、服務層、數據層的常用負載均衡方法。

第二篇文章“lvs為何不能完全代替DNS輪詢”和大家share了互聯網接入層負載均衡需要解決的問題及架構演進。

在這兩篇文章中，都強調了“負載均衡是指，將請求/數據【均勻】分攤到多個操作單元上執行，負載均衡的關鍵在于【均勻】”。

然而，后端的service有可能部署在硬件條件不同的服務器上：

1)如果對標最低配的服務器“均勻”分攤負載，高配的服務器的利用率不足;

2)如果對標最高配的服務器“均勻”分攤負載，低配的服務器可能會扛不住;

能否根據異構服務器的處理能力來動態、自適應進行負載均衡及過載保護，是本文要討論的問題。

一、service層的負載均衡通常是怎么做的

“一分鐘了解負載均衡”中提到，service層的負載均衡，一般是通過service連接池來實現的，調用方連接池會建立與下游服務多個連接，每次請求“隨機”獲取連接，來保證service訪問的均衡性。

“RPC-client實現細節”中提到，負載均衡、故障轉移、超時處理等細節也都是通過調用方連接池來實現的。

這個調用方連接池能否實現，根據service的處理能力，動態+自適應的進行負載調度呢?

二、通過“靜態權重”標識service的處理能力

調用方通過連接池組件訪問下游service，通常采用“隨機”的方式返回連接，以保證下游service訪問的均衡性。

要打破這個隨機性，最容易想到的方法，只要為每個下游service設置一個“權重”，代表service的處理能力，來調整訪問到每個service的概率，例如：

假設service-ip1，service-ip2，service-ip3的處理能力相同，可以設置weight1=1，weight2=1，weight3=1，這樣三個service連接被獲取到的概率分別就是1/3，1/3，1/3，能夠保證均衡訪問。

假設service-ip1的處理能力是service-ip2，service-ip3的處理能力的2倍，可以設置weight1=2，weight2=1，weight3=1，這樣三個service連接被獲取到的概率分別就是2/4，1/4，1/4，能夠保證處理能力強的service分別到等比的流量，不至于資源浪費。

使用nginx做反向代理與負載均衡，就有類似的機制。

這個方案的優點是：簡單，能夠快速的實現異構服務器的負載均衡。

缺點也很明顯：這個權重是固定的，無法自適應動態調整，而很多時候，服務器的處理能力是很難用一個固定的數值量化。

三、通過“動態權重”標識service的處理能力

提問：通過什么來標識一個service的處理能力呢?

回答：其實一個service能不能處理得過來，能不能響應得過來，應該由調用方說了算。調用服務，快速處理了，處理能力跟得上;調用服務，處理超時了，處理能力很有可能跟不上了。

動態權重設計

1.用一個動態權重來標識每個service的處理能力，默認初始處理能力相同，即分配給每個service的概率相等;

2.每當service成功處理一個請求，認為service處理能力足夠，權重動態+1

3.每當service超時處理一個請求，認為service處理能力可能要跟不上了，權重動態-10(權重下降會更快)

4.為了方便權重的處理，可以把權重的范圍限定為[0, 100]，把權重的初始值設為60分

舉例說明：

假設service-ip1，service-ip2，service-ip3的動態權重初始值weight1=weight2=weight3=60，剛開始時，請求分配給這3臺service的概率分別是60/180，60/180，60/180，即負載是均衡的。

隨著時間的推移，處理能力強的service成功處理的請求越來越多，處理能力弱的service偶爾有超時，隨著動態權重的增減，權重可能變化成了weight1=100，weight2=60，weight3=40，那么此時，請求分配給這3臺service的概率分別是100/200，60/200，40/200，即處理能力強的service會被分配到更多的流量。

四、過載保護

提問：什么是過載保護?

圖示：無過載保護的負載與處理能力圖(會掉底)

回答：互聯網軟件架構設計中所指的過載保護，是指當系統負載超過一個service的處理能力時，如果service不進行自我保護，可能導致對外呈現處理能力為0，且不能自動恢復的現象。而service的過載保護，是指即使系統負載超過一個service的處理能力，service讓能保證對外提供有損的穩定服務。

圖示：有過載保護的負載與處理能力圖(不會掉底)

提問：如何進行過載保護?

回答：最簡易的方式，服務端設定一個負載閾值，超過這個閾值的請求壓過來，全部拋棄。這個方式不是特別優雅。

五、如何借助“動態權重”來實施過載保護

動態權重是用來標識每個service的處理能力的一個值，它是RPC-client客戶端連接池層面的一個東東。服務端處理超時，客戶端RPC-client連接池都能夠知道，這里只要實施一些策略，就能夠對“疑似過載”的服務器進行降壓，而不用服務器“拋棄請求”這么粗暴的實施過載保護。

應該實施一些什么樣的策略呢，例如：

1.如果某一個service的連接上，連續3個請求都超時，即連續-10分三次，客戶端就可以認為，服務器慢慢的要處理不過來了，得給這個service緩一小口氣，于是設定策略：接下來的若干時間內，例如1秒(或者接下來的若干個請求)，請求不再分配給這個service;

2.如果某一個service的動態權重，降為了0(像連續10個請求超時，中間休息了3次還超時)，客戶端就可以認為，服務器完全處理不過來了，得給這個service喘一大口氣，于是設定策略：接下來的若干時間內，例如1分鐘(為什么是1分鐘，根據經驗，此時service一般在發生fullGC，差不多1分鐘能回過神來)，請求不再分配給這個service;

3.可以有更復雜的保護策略…

這樣的話，不但能借助“動態權重”來實施動態自適應的異構服務器負載均衡，還能在客戶端層面更優雅的實施過載保護，在某個下游service快要響應不過來的時候，給其喘息的機會。

需要注意的是：要防止客戶端的過載保護引起service的雪崩，如果“整體負載”已經超過了“service集群”的處理能力，怎么轉移請求也是處理不過來的，還得通過拋棄請求來實施自我保護。

六、總結

1.service的負載均衡、故障轉移、超時處理通常是RPC-client連接池層面來實施的

2.異構服務器負載均衡，最簡單的方式是靜態權重法，缺點是無法自適應動態調整

3.動態權重法，可以動態的根據service的處理能力來分配負載，需要有連接池層面的微小改動

4.過載保護，是在負載過高時，service為了保護自己，保證一定處理能力的一種自救方法

5.動態權重法，還可以用做service的過載保護

本文作者：58沈劍

來源：51CTO

總結

以上是生活随笔為你收集整理的如何实施异构服务器的负载均衡及过载保护？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。