柚子快報(bào)邀請(qǐng)碼778899分享：微服務(wù)之Ribbon負(fù)載均衡

http://yzkb.51969.com/

?個(gè)人主頁：阿杰的博客 ?個(gè)人簡(jiǎn)介：大家好，我是阿杰，一個(gè)正在努力讓自己變得更好的男人? 目前狀況?：24屆畢業(yè)生，奮斗在找實(shí)習(xí)的路上? ??為了讓更多的人看到更優(yōu)質(zhì)的博客，阿杰正在努力的更新學(xué)習(xí)中心中的內(nèi)容。

文章目錄

?負(fù)載均衡的原理?源碼追蹤?負(fù)載均衡策略IRule?總結(jié)

?負(fù)載均衡策略?自定義負(fù)載均衡策略

?饑餓加載

上章提到 @LoadBalanced注解，即可實(shí)現(xiàn)負(fù)載均衡功能，這是什么原理呢？

?負(fù)載均衡的原理

SpringCloud底層其實(shí)是利用了一個(gè)名為Ribbon的組件，來實(shí)現(xiàn)負(fù)載均衡

那么我們發(fā)出的請(qǐng)求明明是http://userservice/user/1，怎么變成了http://localhost:8081的呢？

?源碼追蹤

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

顯然有人幫我們根據(jù)service名稱，獲取到了服務(wù)實(shí)例的ip和端口。它就是LoadBalancerInterceptor，這個(gè)類會(huì)在對(duì)RestTemplate的請(qǐng)求進(jìn)行攔截，然后從Eureka根據(jù)服務(wù)id獲取服務(wù)列表，隨后利用負(fù)載均衡算法得到真實(shí)的服務(wù)地址信息，替換服務(wù)id。

我們進(jìn)行源碼跟蹤：

####? LoadBalancerIntercepor

可以看到這里的intercept方法，攔截了用戶的HttpRequest請(qǐng)求，然后做了幾件事：

request.getURI()：獲取請(qǐng)求uri，本例中就是 http://user-service/user/8originalUri.getHost()：獲取uri路徑的主機(jī)名，其實(shí)就是服務(wù)id，user-servicethis.loadBalancer.execute()：處理服務(wù)id，和用戶請(qǐng)求。

這里的this.loadBalancer是LoadBalancerClient類型

####? LoadBalancerClient

繼續(xù)跟入execute方法：

代碼是這樣的：

getLoadBalancer(serviceId)：根據(jù)服務(wù)id獲取ILoadBalancer，而ILoadBalancer會(huì)拿著服務(wù)id去eureka中獲取服務(wù)列表并保存起來。getServer(loadBalancer)：利用內(nèi)置的負(fù)載均衡算法，從服務(wù)列表中選擇一個(gè)。本例中，可以看到獲取了8082端口的服務(wù)

放行后，再次訪問并跟蹤，發(fā)現(xiàn)獲取的是8081：

實(shí)現(xiàn)了負(fù)載均衡。

?負(fù)載均衡策略IRule

在剛才的代碼中，可以看到獲取服務(wù)使通過一個(gè)getServer方法來做負(fù)載均衡:

我們繼續(xù)跟入：

繼續(xù)跟蹤源碼chooseServer方法，發(fā)現(xiàn)這么一段代碼：

我們看看這個(gè)rule是誰：

這里的rule默認(rèn)值是一個(gè)RoundRobinRule，看類的介紹：

這不就是輪詢的意思嘛。

到這里，整個(gè)負(fù)載均衡的流程

?總結(jié)

SpringCloudRibbon的底層采用了一個(gè)攔截器，攔截了RestTemplate發(fā)出的請(qǐng)求，對(duì)地址做了修改。用一幅圖來總結(jié)一下：

攔截流程

攔截我們RestTemplate 發(fā)送的請(qǐng)求交給RibbonLoadBalancerClient 從請(qǐng)求url中獲取服務(wù)名稱，user-service向eureka-server中查詢服務(wù)列表IRule利用內(nèi)置負(fù)載均衡從返回的列表中選擇一個(gè)RibbonLoadBalancerClient 修改請(qǐng)求地址，用ip+端口代替服務(wù)名

?負(fù)載均衡策略

負(fù)載均衡的規(guī)則都定義在IRule接口中，而IRule有很多不同的實(shí)現(xiàn)類：

不同規(guī)則的含義如下：

內(nèi)置負(fù)載均衡規(guī)則類規(guī)則描述RoundRobinRule簡(jiǎn)單輪詢服務(wù)列表來選擇服務(wù)器。它是Ribbon默認(rèn)的負(fù)載均衡規(guī)則。AvailabilityFilteringRule對(duì)以下兩種服務(wù)器進(jìn)行忽略： （1）在默認(rèn)情況下，這臺(tái)服務(wù)器如果3次連接失敗，這臺(tái)服務(wù)器就會(huì)被設(shè)置為“短路”狀態(tài)。短路狀態(tài)將持續(xù)30秒，如果再次連接失敗，短路的持續(xù)時(shí)間就會(huì)幾何級(jí)地增加。 （2）并發(fā)數(shù)過高的服務(wù)器。如果一個(gè)服務(wù)器的并發(fā)連接數(shù)過高，配置了AvailabilityFilteringRule規(guī)則的客戶端也會(huì)將其忽略。并發(fā)連接數(shù)的上限，可以由客戶端的..ActiveConnectionsLimit屬性進(jìn)行配置。WeightedResponseTimeRule為每一個(gè)服務(wù)器賦予一個(gè)權(quán)重值。服務(wù)器響應(yīng)時(shí)間越長(zhǎng)，這個(gè)服務(wù)器的權(quán)重就越小。這個(gè)規(guī)則會(huì)隨機(jī)選擇服務(wù)器，這個(gè)權(quán)重值會(huì)影響服務(wù)器的選擇。ZoneAvoidanceRule以區(qū)域可用的服務(wù)器為基礎(chǔ)進(jìn)行服務(wù)器的選擇。使用Zone對(duì)服務(wù)器進(jìn)行分類，這個(gè)Zone可以理解為一個(gè)機(jī)房、一個(gè)機(jī)架等。而后再對(duì)Zone內(nèi)的多個(gè)服務(wù)做輪詢。BestAvailableRule忽略那些短路的服務(wù)器，并選擇并發(fā)數(shù)較低的服務(wù)器。RandomRule隨機(jī)選擇一個(gè)可用的服務(wù)器。RetryRule重試機(jī)制的選擇邏輯

默認(rèn)的實(shí)現(xiàn)就是ZoneAvoidanceRule，是一種輪詢方案

?自定義負(fù)載均衡策略

通過定義IRule實(shí)現(xiàn)可以修改負(fù)載均衡規(guī)則，有兩種方式：

代碼方式：在order-service中的OrderApplication類中，定義一個(gè)新的IRule：

@Bean

public IRule randomRule(){

return new RandomRule();

}

配置文件方式：在order-service的application.yml文件中，添加新的配置也可以修改規(guī)則：

userservice: # 給某個(gè)微服務(wù)配置負(fù)載均衡規(guī)則，這里是userservice服務(wù)

ribbon:

NFLoadBalancerRuleClassName: com.netflix.loadbalancer.RandomRule # 負(fù)載均衡規(guī)則

注意，一般用默認(rèn)的負(fù)載均衡規(guī)則，不做修改。

?饑餓加載

Ribbon默認(rèn)是采用懶加載，即第一次訪問時(shí)才會(huì)去創(chuàng)建LoadBalanceClient，請(qǐng)求時(shí)間會(huì)很長(zhǎng)。

而饑餓加載則會(huì)在項(xiàng)目啟動(dòng)時(shí)創(chuàng)建，降低第一次訪問的耗時(shí)，通過下面配置開啟饑餓加載：

ribbon:

eager-load:

enabled: true

clients: userservice

柚子快報(bào)邀請(qǐng)碼778899分享：微服務(wù)之Ribbon負(fù)載均衡

http://yzkb.51969.com/

相關(guān)閱讀