Ribbon負載均衡
SpringCloud已經洗掉了ribbon組件，所以需要手動匯入依賴，（要學是因為很多專案業務已經使用了ribbon）
服務拉取的時候添加了@LoadBalanced注解，實作負載均衡
1.負載均衡原理
SpringCloud底層其實是利用了一個名為Ribbon的組件，來實作負載均衡功能的，
那么我們發出的請求明明是http://userservice/user/1，怎么變成了http://localhost:8081/user/1的呢？
2.原始碼跟蹤
為什么我們只輸入了service名稱就可以訪問了呢？之前還要獲取ip和埠，
顯然有人幫我們根據service名稱，獲取到了服務實體的ip和埠，它就是LoadBalancerInterceptor，這個類會在對RestTemplate的請求進行攔截，然后從Eureka根據服務id獲取服務串列，隨后利用負載均衡演算法得到真實的服務地址資訊，替換服務id，
我們進行原始碼跟蹤：
1）LoadBalancerIntercepor
可以看到這里的intercept方法，攔截了用戶的HttpRequest請求，然后做了幾件事：
request.getURI()：獲取請求uri，本例中就是 http://user-service/user/8originalUri.getHost()：獲取uri路徑的主機名，其實就是服務id，user-servicethis.loadBalancer.execute()：處理服務id，和用戶請求，
這里的this.loadBalancer是LoadBalancerClient型別，我們繼續跟入，
2）LoadBalancerClient
繼續跟入execute方法：
代碼是這樣的：
- getLoadBalancer(serviceId)：根據服務id獲取ILoadBalancer，而ILoadBalancer會拿著服務id去eureka中獲取服務串列并保存起來，
- getServer(loadBalancer)：利用內置的負載均衡演算法，從服務串列中選擇一個，本例中，可以看到獲取了8082埠的服務放行后，再次訪問并跟蹤，發現獲取的是8081：果然實作了負載均衡，
3）負載均衡策略IRule
在剛才的代碼中，可以看到獲取服務使通過一個getServer方法來做負載均衡:
我們繼續跟入：
繼續跟蹤原始碼chooseServer方法，發現這么一段代碼：
我們看看這個rule是誰：
這里的rule默認值是一個RoundRobinRule，看類的介紹：
這不就是輪詢的意思嘛，
到這里，整個負載均衡的流程我們就清楚了，
4）總結
SpringCloudRibbon的底層采用了一個攔截器，攔截了RestTemplate發出的請求，對地址做了修改，用一幅圖來總結一下：
基本流程如下：【重點】
- 攔截我們的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有很多不同的實作類：
不同規則的含義如下：默認的實作就是ZoneAvoidanceRule，是一種輪詢方案
| 內置負載均衡規則類 | 規則描述 |
|---|---|
| RoundRobinRule | 簡單輪詢服務串列來選擇服務器，它是Ribbon默認的負載均衡規則， |
| AvailabilityFilteringRule | 對以下兩種服務器進行忽略： （1）在默認情況下，這臺服務器如果3次連接失敗，這臺服務器就會被設定為“短路”狀態，短路狀態將持續30秒，如果再次連接失敗，短路的持續時間就會幾何級地增加， （2）并發數過高的服務器，如果一個服務器的并發連接數過高，配置了AvailabilityFilteringRule規則的客戶端也會將其忽略，并發連接數的上限，可以由客戶端的 |
| WeightedResponseTimeRule | 為每一個服務器賦予一個權重值，服務器回應時間越長，這個服務器的權重就越小，這個規則會隨機選擇服務器，這個權重值會影響服務器的選擇， |
| ZoneAvoidanceRule | 以區域可用的服務器為基礎進行服務器的選擇，使用Zone對服務器進行分類，這個Zone可以理解為一個機房、一個機架等，而后再對Zone內的多個服務做輪詢， |
| BestAvailableRule | 忽略那些短路的服務器，并選擇并發數較低的服務器， |
| RandomRule | 隨機選擇一個可用的服務器， |
| RetryRule | 重試機制的選擇邏輯 |
2）自定義負載均衡策略
注意，一般用默認的負載均衡規則，不做修改，
通過定義IRule實作可以修改負載均衡規則，有兩種方式：（二選一即可）
-
代碼方式：在order-service中的OrderApplication類中，定義一個新的IRule：
優：配置靈活 劣：修改時需要重新打包
@Bean
public IRule randomRule(){
return new RandomRule();
}
-
組態檔方式：在order-service的application.yml檔案中，添加新的配置也可以修改規則：【推薦】
優：直觀，方便，修改后無需重新打包 劣：無法全域配置，需要對每個服務設定負責均衡規則
userservice: # 給某個微服務配置負載均衡規則，這里是userservice服務
ribbon:
NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule # 負載均衡規則
4.饑餓加載
推薦修改為饑餓加載，在消費者的yaml中設定
Ribbon默認是采用懶加載，即第一次訪問時才會去創建LoadBalanceClient，請求時間會很長，
而饑餓加載則會在專案啟動時創建，降低第一次訪問的耗時，通過下面配置開啟饑餓加載：
ribbon:
eager-load:
enabled: true #開啟饑餓加載
clients: #指定饑餓加載的服務名稱
- userservice
- xxx
本文來自博客園，作者：不吃紫菜，遵循CC 4.0 BY-SA著作權協議，轉載請附上原文出處鏈接：https://www.cnblogs.com/buchizicai/p/17093490.html及本宣告，
本文著作權歸作者所有，歡迎轉載，但未經作者同意必須保留此段宣告，且在文章頁面明顯位置給出原文連接，否則保留追究法律責任的權利，
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/543655.html
標籤：其他