Ribbon負載均衡 (原始碼分析)

不吃紫菜發表於2023-02-12
負載原始碼

Ribbon負載均衡

SpringCloud已經刪除了ribbon元件，所以需要手動匯入依賴。（要學是因為很多專案業務已經使用了ribbon）

服務拉取的時候新增了@LoadBalanced註解，實現負載均衡

1.負載均衡原理

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

image

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

2.原始碼跟蹤

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

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

我們進行原始碼跟蹤：

1）LoadBalancerIntercepor

image

可以看到這裡的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方法：

image

程式碼是這樣的：

  • getLoadBalancer(serviceId)：根據服務id獲取ILoadBalancer，而ILoadBalancer會拿著服務id去eureka中獲取服務列表並儲存起來。
  • getServer(loadBalancer)：利用內建的負載均衡演算法，從服務列表中選擇一個。本例中，可以看到獲取了8082埠的服務放行後，再次訪問並跟蹤，發現獲取的是8081：果然實現了負載均衡。

image

3）負載均衡策略IRule

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

image

我們繼續跟入：

image

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

image

我們看看這個rule是誰：

image

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

image

這不就是輪詢的意思嘛。

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

4）總結

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

image

基本流程如下：【重點】

  • 攔截我們的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，發起真實請求

3.負載均衡策略

預設設定是IRule介面下的ZoneAvoidanceRule 類（根據就近區域Zone來輪詢）

1）負載均衡策略

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

image

不同規則的含義如下：預設的實現就是ZoneAvoidanceRule，是一種輪詢方案

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

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.飢餓載入

推薦修改為飢餓載入，在消費者的yaml中設定

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

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

ribbon:
  eager-load:
    enabled: true #開啟飢餓載入
    clients:  #指定飢餓載入的服務名稱
      - userservice
      - xxx

相關文章