（4）什麼是Ribbon負載均衡

word發表於2022-02-09
負載

4.Ribbon負載均衡

上一節中，我們新增了@LoadBalanced註解，即可實現負載均衡功能，這是什麼原理呢？

4.1.負載均衡原理

SpringCloud底層其實是利用了一個名為Ribbon的元件，來實現負載均衡功能的。

image-20210713224517686

那麼我們發出的請求明明是http://userservice/user/1，怎麼變成了http://localhost:8081的呢？

4.2.原始碼跟蹤

為什麼我們只輸入了service名稱就可以訪問了呢？之前還要獲取ip和埠。

顯然有人幫我們根據service名稱，獲取到了服務例項的ip和埠。它就是LoadBalancerInterceptor，這個類會在對RestTemplate的請求進行攔截，然後從Eureka根據服務id獲取服務列表，隨後利用負載均衡演算法得到真實的服務地址資訊，替換服務id。

我們進行原始碼跟蹤：

1）LoadBalancerIntercepor

1525620483637

可以看到這裡的intercept方法，攔截了使用者的HttpRequest請求，然後做了幾件事：

  • request.getURI()：獲取請求uri，本例中就是 http://user-service/user/8
  • originalUri.getHost()：獲取uri路徑的主機名，其實就是服務id，user-service
  • this.loadBalancer.execute()：處理服務id，和使用者請求。

這裡的this.loadBalancer是LoadBalancerClient型別，我們繼續跟入。

2）LoadBalancerClient

繼續跟入execute方法：

1525620787090

程式碼是這樣的：

  • getLoadBalancer(serviceId)：根據服務id獲取ILoadBalancer，而ILoadBalancer會拿著服務id去eureka中獲取服務列表並儲存起來。
  • getServer(loadBalancer)：利用內建的負載均衡演算法，從服務列表中選擇一個。本例中，可以看到獲取了8082埠的服務

放行後，再次訪問並跟蹤，發現獲取的是8081：

1525620835911

果然實現了負載均衡。

3）負載均衡策略IRule

在剛才的程式碼中，可以看到獲取服務使通過一個getServer方法來做負載均衡:

image-20220209084807321

我們繼續跟入：

1544361421671

繼續跟蹤原始碼chooseServer方法，發現這麼一段程式碼：

1525622652849

我們看看這個rule是誰：

1525622699666

這裡的rule預設值是一個RoundRobinRule，看類的介紹：

1525622754316

這不就是輪詢的意思嘛。

到這裡，整個負載均衡的流程我們就清楚了。

4）總結

SpringCloudRibbon的底層採用了一個攔截器，攔截了RestTemplate發出的請求，對地址做了修改。用一幅圖來總結一下：

image-20210713224724673

基本流程如下：

  • 攔截我們的RestTemplate請求http://userservice/user/1
  • RibbonLoadBalancerClient會從請求url中獲取服務名稱，也就是user-service
  • DynamicServerListLoadBalancer根據user-service到eureka拉取服務列表
  • eureka返回列表，localhost:8081、localhost:8082
  • IRule利用內建負載均衡規則，從列表中選擇一個，例如localhost:8081
  • RibbonLoadBalancerClient修改請求地址，用localhost:8081替代userservice，得到http://localhost:8081/user/1，發起真實請求

4.3.負載均衡策略

4.3.1.負載均衡策略

負載均衡的規則都定義在IRule介面中，而IRule有很多不同的實現類：

image-20210713225653000

不同規則的含義如下：

內建負載均衡規則類 規則描述
RoundRobinRule 簡單輪詢服務列表來選擇伺服器。它是Ribbon預設的負載均衡規則。
AvailabilityFilteringRule 對以下兩種伺服器進行忽略： （1）在預設情況下，這臺伺服器如果3次連線失敗，這臺伺服器就會被設定為“短路”狀態。短路狀態將持續30秒，如果再次連線失敗，短路的持續時間就會幾何級地增加。 （2）併發數過高的伺服器。如果一個伺服器的併發連線數過高，配置了AvailabilityFilteringRule規則的客戶端也會將其忽略。併發連線數的上限，可以由客戶端的..ActiveConnectionsLimit屬性進行配置。
WeightedResponseTimeRule 為每一個伺服器賦予一個權重值。伺服器響應時間越長，這個伺服器的權重就越小。這個規則會隨機選擇伺服器，這個權重值會影響伺服器的選擇。
ZoneAvoidanceRule 以區域可用的伺服器為基礎進行伺服器的選擇。使用Zone對伺服器進行分類，這個Zone可以理解為一個機房、一個機架等。而後再對Zone內的多個服務做輪詢。
BestAvailableRule 忽略那些短路的伺服器，並選擇併發數較低的伺服器。
RandomRule 隨機選擇一個可用的伺服器。
RetryRule 重試機制的選擇邏輯

預設的實現就是ZoneAvoidanceRule，是一種輪詢方案

4.3.2.自定義負載均衡策略

通過定義IRule實現可以修改負載均衡規則，有兩種方式：

  1. 程式碼方式：在order-service中的OrderApplication類中，定義一個新的IRule：
@Bean
public IRule randomRule(){
    return new RandomRule();
}
  1. 配置檔案方式：在order-service的application.yml檔案中，新增新的配置也可以修改規則：
userservice: # 給某個微服務配置負載均衡規則，這裡是userservice服務
  ribbon:
    NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule # 負載均衡規則

注意，一般用預設的負載均衡規則，不做修改。

4.4.飢餓載入

Ribbon預設是採用懶載入，即第一次訪問時才會去建立LoadBalanceClient，請求時間會很長。

而飢餓載入則會在專案啟動時建立，降低第一次訪問的耗時，通過下面配置開啟飢餓載入：

ribbon:
  eager-load:
    enabled: true
    clients: userservice

相關文章