一、前言

在上一篇，通過springcloud整合nacos，了解了基于nacos作為服務(wù)注冊中心時(shí)實(shí)現(xiàn)微服務(wù)之間的快捷調(diào)用，其中，為了實(shí)現(xiàn)服務(wù)A對服務(wù)B的調(diào)用，在RestConfig配置類中配置RestTemplate時(shí)候，引入了一個(gè)叫做LoadBalanced的注解，于是不僅有小伙伴要問，這個(gè)注解是干嘛用的呢？本篇將詳細(xì)的探討這個(gè)問題。

二、什么是 Ribbon

2.1 ribbon簡介

Spring Cloud Ribbon 是基于Netflix Ribbon 實(shí)現(xiàn)的一套客戶端負(fù)載均衡工具，Ribbon客戶端組件提供了一系列的完善的配置，如超時(shí)，重試等。

通過Load Balancer獲取到服務(wù)提供的所有機(jī)器實(shí)例，Ribbon會自動(dòng)基于某種規(guī)則(輪詢，隨機(jī))去調(diào)用這些服務(wù)。Ribbon也可以實(shí)現(xiàn)我們自己的負(fù)載均衡算法。

2.1.1  ribbon在負(fù)載均衡中的角色

負(fù)載均衡這個(gè)概念大家都不陌生，幾乎可以說是互聯(lián)網(wǎng)公司標(biāo)配，目前主流負(fù)載方案主要分為以下兩種：

集中式負(fù)載均衡，在消費(fèi)者和服務(wù)提供方中間使用獨(dú)立的代理方式進(jìn)行負(fù)載，有硬件的（比如 F5），也有軟件的（比如 Nginx）；客戶端根據(jù)自身請求情況做負(fù)載均衡，Ribbon 就屬于客戶端自己做負(fù)載均衡，在dubbo中，客戶端也可以配置負(fù)載均衡策略，也是類似的思想；

2.2 客戶端負(fù)載均衡

顧名思義，就是由客戶端根據(jù)自身的情況做負(fù)載均衡策略的選擇或配置，比如spring cloud中的ribbon，簡單來說，當(dāng)服務(wù)提供者將自身的服務(wù)注冊到服務(wù)注冊中心之后，客戶端相應(yīng)的會維護(hù)一個(gè)服務(wù)器地址列表，在發(fā)送請求前，先通過負(fù)載均衡算法選擇一個(gè)服務(wù)器，然后進(jìn)行訪問，這就是客戶端負(fù)載均衡，即在客戶端就進(jìn)行負(fù)載均衡算法分配。

如下，為ribbon作為客戶端的負(fù)載均衡的調(diào)用流程圖。

2.3 服務(wù)端負(fù)載均衡

即集中式的管控負(fù)載均衡策略的組件，比如Nginx，即所有的請求過來之后，先通過Nginx進(jìn)行負(fù)載均衡，先發(fā)送請求到具體的微服務(wù)，然后通過nginx中配置的負(fù)載均衡算法，在多個(gè)服務(wù)器之間選擇一個(gè)進(jìn)行訪問，即在服務(wù)器端再進(jìn)行負(fù)載均衡算法分配。

2.4 常用負(fù)載均衡算法

下面列舉日常開發(fā)中經(jīng)常用到的一些負(fù)載均衡算法，可以說很多組件的負(fù)載均衡的底層算法思想都是大同小異

2.4.1 隨機(jī)算法

通過隨機(jī)選擇集群中的某個(gè)可用的服務(wù)進(jìn)行請求執(zhí)行，在集群的各服務(wù)器配置差不多的情況下可以考慮使用，一般這種方式使用較少

2.4.2 輪詢算法

負(fù)載均衡默認(rèn)的實(shí)現(xiàn)方式，請求過來之后，依次輪流從可用服務(wù)中選擇進(jìn)行處理

2.4.3 加權(quán)輪詢算法

通過對服務(wù)器性能的分型，給高配置，低負(fù)載的服務(wù)器分配更高的權(quán)重，均衡各個(gè)服務(wù)器的壓力;

2.4.4 IP地址hash

根據(jù)請求的地址進(jìn)行Hash，通過客戶端請求的地址的HASH值取模映射進(jìn)行服務(wù)器調(diào)度，  ip --->hash，這樣相同請求的IP將會被打到相同的服務(wù)器處理；

2.4.5 最小鏈接數(shù)

即使請求均衡了，壓力也不一定會均衡，最小連接數(shù)法就是根據(jù)服務(wù)器的情況，比如請求積壓數(shù)等參數(shù)，將請求分配到當(dāng)前壓力最小的服務(wù)器上，最小連接數(shù)也叫最小活躍數(shù)。

三、Ribbon中負(fù)載均衡策略總探究

3.1 nacos中使用ribbon過程

在上一篇，springcloud-alibaba整合nacos中，客戶端通過nacos進(jìn)行服務(wù)調(diào)用默認(rèn)使用的就是Ribbon負(fù)載均衡，只需下面兩步

3.1.1 添加配置類

添加一個(gè)RestTemplate 的配置bean，使用LoadBalanced注解標(biāo)注

@Configuration
public class RestConfig {
 
    @Bean
    @LoadBalanced
    public RestTemplate restTemplate(){
        return new RestTemplate();
    }
 
}

3.1.2 接口層調(diào)用

具體調(diào)用的時(shí)候，仍然使用restTemplate調(diào)用即可，如果服務(wù)端有多個(gè)實(shí)例，將會自動(dòng)走默認(rèn)負(fù)載均衡策略；

@RestController
@RequestMapping("/order")
public class OrderController {
 
    @Autowired
    RestTemplate restTemplate;
 
    @Value("${service-url.nacos-user-service}")
    private String serverURL;
 
    //localhost:8083/order/add
    @GetMapping("/add")
    public String add(){
        System.out.println("下單成功");
        //String forObject = restTemplate.getForObject("http://localhost:8082/stock/reduct", String.class);
        String forObject = restTemplate.getForObject(serverURL + "/stock/reduct", String.class);
        System.out.println(forObject);
        return "add order  :" + forObject;
    }
 
}

3.2 Ribbon中負(fù)載均衡配置策略

通過完整的類的依賴關(guān)系圖，可以看到Ribbon提供了很多種負(fù)載均衡策略，下面就Ribbon中常用的負(fù)載均衡策略做詳細(xì)的解讀。

3.2.1 IRule

這是所有負(fù)載均衡策略的父接口，里邊的核心方法就是choose方法，用來選擇一個(gè)服務(wù)實(shí)例

3.2.2  AbstractLoadBalancerRule

一個(gè)抽象類，里邊主要定義了一個(gè)ILoadBalancer，這里定義它的目的主要是輔助負(fù)責(zé)均衡策略選取合適的服務(wù)端實(shí)例。

3.2.3  RandomRule

這種負(fù)載均衡策略就是隨機(jī)從多個(gè)服務(wù)實(shí)例中選擇一個(gè)服務(wù)實(shí)例

通過源碼發(fā)現(xiàn)，在RandomRule的無參構(gòu)造方法中初始化了一個(gè)Random對象，然后在它重寫的choose方法又調(diào)用了choose(ILoadBalancer lb, Object key)這個(gè)重載的choose方法，在這個(gè)重載的choose方法中，每次利用random對象生成一個(gè)不大于服務(wù)實(shí)例總數(shù)的隨機(jī)數(shù)，并將該數(shù)作為下標(biāo)所以獲取一個(gè)服務(wù)實(shí)例；

可以參閱源碼

public Server choose(ILoadBalancer lb, Object key) {
        if (lb == null) {
            return null;
        } else {
            Server server = null;
 
            while(server == null) {
                if (Thread.interrupted()) {
                    return null;
                }
 
                List<Server> upList = lb.getReachableServers();
                List<Server> allList = lb.getAllServers();
                int serverCount = allList.size();
                if (serverCount == 0) {
                    return null;
                }
 
                int index = this.chooseRandomInt(serverCount);
                server = (Server)upList.get(index);
                if (server == null) {
                    Thread.yield();
                } else {
                    if (server.isAlive()) {
                        return server;
                    }
 
                    server = null;
                    Thread.yield();
                }
            }
 
            return server;
        }
    }

3.2.4  RoundRobinRule

RoundRobinRule 這種負(fù)載均衡策略也叫線性輪詢負(fù)載均衡策略

這個(gè)類的choose(ILoadBalancer lb, Object key)方法整體邏輯是這樣的：

• 開啟一個(gè)計(jì)數(shù)器count，在while循環(huán)中遍歷務(wù)清單，獲取清單之前先通過incrementAndGetModulo方法獲取一個(gè)下標(biāo)，這個(gè)下標(biāo)是一個(gè)不斷自增長的數(shù)先加1然后和服務(wù)清單總數(shù)取模之后獲取到的（所以這個(gè)下標(biāo)從來不會越界）；
• 然后拿著下標(biāo)再去服務(wù)清單列表中取服務(wù)，每次循環(huán)計(jì)數(shù)器都會加1，如果連續(xù)10次都沒有取到服務(wù)，則會報(bào)一個(gè)警告No available alive servers after 10 tries from load balancer: XXXX；

3.2.5  RetryRule

在輪詢基礎(chǔ)上重試，即這種負(fù)載均衡策略帶有重試功能

它整體工作流程是這樣：

• 首先RetryRule中定義了一個(gè)subRule，它的實(shí)現(xiàn)類是RoundRobinRule；
• 然后在RetryRule的choose(ILoadBalancer lb, Object key)方法中，每次還是采用RoundRobinRule中的choose規(guī)則來選擇一個(gè)服務(wù)實(shí)例；
• 如果選到的實(shí)例正常就返回，如果選擇的服務(wù)實(shí)例為null或者已經(jīng)失效，則在失效時(shí)間deadline之前不斷的進(jìn)行重試（重試時(shí)獲取服務(wù)的策略還是RoundRobinRule中定義的策略）；
• 如果超過了deadline還是沒取到則會返回一個(gè)null；

3.2.6 WeightedResponseTimeRule

顧名思義，帶有權(quán)重功能，權(quán)重 — nacos的NacosRule ，Nacos還擴(kuò)展了一個(gè)自己的基于配置的權(quán)重?cái)U(kuò)展 

大致工作原理如下：

• WeightedResponseTimeRule是RoundRobinRule的一個(gè)子類，在WeightedResponseTimeRule中對RoundRobinRule的功能進(jìn)行了擴(kuò)展；
• WeightedResponseTimeRule中會根據(jù)每一個(gè)實(shí)例的運(yùn)行情況來給計(jì)算出該實(shí)例的一個(gè)權(quán)重，然后在挑選實(shí)例的時(shí)候則根據(jù)權(quán)重進(jìn)行挑選，這樣能夠?qū)崿F(xiàn)更優(yōu)的實(shí)例調(diào)用；
• WeightedResponseTimeRule中有一個(gè)名叫DynamicServerWeightTask的定時(shí)任務(wù)，默認(rèn)情況下每隔30秒會計(jì)算一次各個(gè)服務(wù)實(shí)例的權(quán)重；
• 權(quán)重計(jì)算規(guī)則很簡單，如果一個(gè)服務(wù)的平均響應(yīng)時(shí)間越短則權(quán)重越大，那么該服務(wù)實(shí)例被選中執(zhí)行任務(wù)的概率也就越大；

3.2.7 ClientConfigEnabledRoundRobinRule

這種策略實(shí)現(xiàn)很簡單，內(nèi)部定義了RoundRobinRule，choose方法還是采用了RoundRobinRule的 choose方法，所以它的選擇策略和RoundRobinRule的選擇策略一致，就不再過多不贅述。

3.2.8 BestAvailableRule

• BestAvailableRule繼承自ClientConfigEnabledRoundRobinRule；
• 它在ClientConfigEnabledRoundRobinRule的基礎(chǔ)上主要增加了根據(jù)loadBalancerStats中保存的服務(wù)實(shí)例的狀態(tài)信息來過濾掉失效的服務(wù)實(shí)例的功能，然后順便找出并發(fā)請求最小的服務(wù)實(shí)例來使用；
• 然而loadBalancerStats有可能為null，如果loadBalancerStats為null，則BestAvailableRule將采用它的父類即ClientConfigEnabledRoundRobinRule的服務(wù)選取策略（線性輪詢）；

3.2.9 ZoneAvoidanceRule

默認(rèn)規(guī)則 ，復(fù)合判斷server所在區(qū)域的性能和server的可用性選擇服務(wù)器

• ZoneAvoidanceRule是PredicateBasedRule的一個(gè)實(shí)現(xiàn)類，只不過這里多一個(gè)過濾條件；
• ZoneAvoidanceRule中的過濾條件是以ZoneAvoidancePredicate為主過濾條件和以AvailabilityPredicate為次過濾條件組成的一個(gè)叫做CompositePredicate的組合過濾條件；
• 過濾成功之后，繼續(xù)采用線性輪詢(RoundRobinRule)的方式從過濾結(jié)果中選擇一個(gè)出來；

3.2.10 AvailabilityFilteringRule

先過濾掉故障實(shí)例，再選擇并發(fā)較小的實(shí)例，具體來說，過濾掉一直連接失敗的被標(biāo)記為circuit tripped的后端Server，并過濾掉那些高并發(fā)的后端Server或者使用一個(gè)AvailabilityPredicate來 包含過濾server的邏輯，其實(shí)就是檢查status里記錄的各個(gè)Server的運(yùn)行狀態(tài)。

四、Ribbon負(fù)載均衡策略修改

上面詳細(xì)了解了Ribbon中的常用的一些負(fù)載均衡配置策略，接下來通過實(shí)際操作演示下如何修改Ribbon的負(fù)載均衡配置策略。

4.1  通過配置類方式修改

這是一種比較靈活的修改配置方式，只需要添加一個(gè)配置類，并配置指定的負(fù)載均衡bean即可

4.1.1  增加一個(gè)負(fù)載均衡策略配置類

注意這里有個(gè)坑，自定義的配置類不能寫在@SpringbootApplication注解的@CompentScan掃描得到的地方，否則自定義的配置類就會被所有的 RibbonClients共享。

因此實(shí)際開發(fā)中不建議這么使用，推薦yml方式

工程的目錄結(jié)構(gòu)如下

RibbonRandomRuleConfig 配置類

@Configuration
public class RibbonRandomRuleConfig {
 
    @Bean
    public IRule iRule(){
        return new RandomRule();
    }
}

4.1.2  啟動(dòng)類指定負(fù)載均衡配置類

@SpringBootApplication
@RibbonClients(value = {
        @RibbonClient(name = "stock-service",configuration = RibbonRandomRuleConfig.class)
})
public class RibbonOrderApp {
 
    public static void main(String[] args) {
        SpringApplication.run(RibbonOrderApp.class,args);
    }
 
}

4.1.3  測試負(fù)載均衡策略是否生效

分別啟動(dòng)stock-service的兩個(gè)工程，再啟動(dòng)order工程，stock-service可以在idea中通過區(qū)分端口的方式

啟動(dòng)完成之后，檢查nacos，可以看到stock-service有兩個(gè)服務(wù)實(shí)例，這正好是我們希望的

調(diào)用order模塊的接口：http://localhost:8030/order/add，由于是客戶端負(fù)載均衡，而且我們配置的是隨機(jī)的策略，預(yù)計(jì)在隨機(jī)調(diào)用該接口之后，會呈現(xiàn)出不同的接口

 多調(diào)用幾次，可以看到8021與8023對應(yīng)的服務(wù)不斷交替出現(xiàn)，并且沒什么規(guī)律

4.2  通過配置文件方式修改

4.2.1 修改啟動(dòng)類

去掉啟動(dòng)類中的注解信息

@SpringBootApplication
/*@RibbonClients(value = {
        @RibbonClient(name = "stock-service",configuration = RibbonRandomRuleConfig.class)
})*/
public class RibbonOrderApp {
 
    public static void main(String[] args) {
        SpringApplication.run(RibbonOrderApp.class,args);
    }
 
}

4.2.2 配置文件指定具體的負(fù)載均衡策略

在配置文件下方增加如下配置，這里是哦也能夠的是nacos提供的基于權(quán)重的策略，也可以選擇其他的；

stock-service:
  ribbon:
    NFLoadBalancerRuleClassName: com.alibaba.cloud.nacos.ribbon.NacosRule

4.2.3 修改stock-service 的權(quán)重配置

在nacos服務(wù)列表那一欄，進(jìn)入到如下所示 stock-servide具體的詳情頁面

分別編輯兩個(gè)實(shí)例的權(quán)重大小，比如這里給8023實(shí)例權(quán)重為10，另一個(gè)保持默認(rèn)為1

設(shè)置完成后按照預(yù)期猜想，設(shè)置權(quán)重更高的那個(gè)將會優(yōu)先得到訪問的機(jī)會，啟動(dòng)order服務(wù)，再次按照上面的方式調(diào)用多次觀察效果

粗略統(tǒng)計(jì)發(fā)現(xiàn)，在10多次的請求中，權(quán)重高的那個(gè)被訪問的次數(shù)更多，這也就符合我們的預(yù)期效果了；

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

 從上面的ribbon類圖可以發(fā)現(xiàn)，通過實(shí)現(xiàn) IRule 接口可以自定義負(fù)載策略，主要的選擇服務(wù)邏輯在 choose 方法中完成，最簡單的就是繼承AbstractLoadBalancerRule這個(gè)抽象類；

4.3.1 自定義負(fù)載均衡類

只需要繼承AbstractLoadBalancerRule抽象類，并重寫里面的choose方式，在該方式中，使用了類似的隨機(jī)算法的策略，也可以根據(jù)自身的需求，定制特定的負(fù)載均衡算法；

public class CustomRule extends AbstractLoadBalancerRule {
 
    private static Logger logger = LoggerFactory.getLogger(CustomRule.class);
 
 
    @Override
    public Server choose(Object o) {
 
        ILoadBalancer loadBalancer = this.getLoadBalancer();
        List<Server> reachableServers = loadBalancer.getReachableServers();
        int i = ThreadLocalRandom.current().nextInt(reachableServers.size());
        Server server = reachableServers.get(i);
        return server;
    }
 
    @Override
    public void initWithNiwsConfig(IClientConfig iClientConfig) {
 
    }
}

4.3.2 配置文件中使用自定義配置類

stock-service:
  ribbon:
    #NFLoadBalancerRuleClassName: com.alibaba.cloud.nacos.ribbon.NacosRule
    #使用自定義的負(fù)載均衡策略
    NFLoadBalancerRuleClassName: com.ribbon.CustomRule

4.3.3 啟動(dòng)工程并測試

將上一步的nacos中stock-service的兩個(gè)服務(wù)實(shí)例的權(quán)重都調(diào)整為1，然后再次訪問接口，可以看到呈現(xiàn)出隨機(jī)的效果；

4.3.4 ribbon負(fù)載均衡懶加載模式

Ribbon的負(fù)載均衡策略默認(rèn)是懶加載，意味著只有在發(fā)起調(diào)用的時(shí)候才會創(chuàng)建客戶端，這帶來的問題是，如果網(wǎng)絡(luò)不好，第一次調(diào)用的時(shí)候可能會出現(xiàn)調(diào)用超時(shí)，我們通過控制臺日志也能看出來；

如何解決這個(gè)問題呢？可以手動(dòng)開啟饑餓加載，來解決第一次調(diào)用慢的問題，只需要在配置文件中添加如下配置即可；

ribbon:
  eager-load:
    # 開啟ribbon饑餓加載
    enabled: true
    # 配置stock-service使用ribbon饑餓加載，多個(gè)使用逗號分隔
    clients: stock-service

再次重啟order服務(wù)，通過控制臺輸出日志可以看到，在啟動(dòng)的時(shí)候負(fù)載均衡策略就被加載了；

五、Spring Cloud LoadBalancer

5.1 概述

Spring Cloud LoadBalancer是Spring Cloud官方自己提供的客戶端負(fù)載均衡器, 用來替代
Ribbon

Spring 官方提供了兩種負(fù)載均衡客戶端

5.1.1 RestTemplate

RestTemplate是 Spring提供的用于訪問Rest服務(wù)的客戶端，RestTemplate提供了多種便捷訪問遠(yuǎn)程Http服務(wù)的方法，能夠大大提高客戶端的編寫效率。默認(rèn)情況下，RestTemplate默認(rèn)依賴jdk的HTTP連接工具

5.1.2 Webclient

WebClient是從Spring WebFlux 5.0版本開始提供的一個(gè)非阻塞的基于響應(yīng)式編程的進(jìn)行Http請求的客戶端工具。它的響應(yīng)式編程的基于Reactor的。WebClient中提供了標(biāo)準(zhǔn)Http請求方式對應(yīng)的get、post、put、delete等方法，可以用來發(fā)起相應(yīng)的請求

5.2  RestTemplate 整合LoadBalancer

5.2.1 創(chuàng)建一個(gè)新的order模塊，引入下面的依賴

 <dependencies>
 
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
        </dependency>
 
        <!--nacos-config 配置中心-自帶動(dòng)態(tài)刷新-->
        <!--<dependency>
            <groupId>com.alibaba.cloud</groupId>
            <artifactId>spring-cloud-starter-alibaba-nacos-config</artifactId>
        </dependency>-->
 
        <!--nacos-discovery 注冊中心-服務(wù)發(fā)現(xiàn)與注冊-->
        <dependency>
            <groupId>com.alibaba.cloud</groupId>
            <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
            <exclusions>
                <exclusion>
                    <groupId>org.springframework.cloud</groupId>
                    <artifactId>spring‐cloud‐starter‐netflix‐ribbon</artifactId>
                </exclusion>
            </exclusions>
        </dependency>
 
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring‐cloud‐starter‐loadbalancer</artifactId>
        </dependency>
 
    </dependencies>

5.2.2  添加如下配置文件

這里主要是將默認(rèn)的ribbon的loadbalancer負(fù)載均衡策略禁用掉

server:
  port: 8033
 
spring:
  application:
    name: order-service
  cloud:
    nacos:
      discovery:
        server-addr: localhost:8848 #服務(wù)注冊中心地址
      #config:
        #server-addr: localhost:8848 #配置中心地址
    loadbalancer:
      ribbon:
        enabled: false
 
service-url:
  nacos-user-service: http://stock-service

5.2.3 啟動(dòng)類

@SpringBootApplication
//@EnableDiscoveryClient
public class BalancerOrderApp {
    public static void main(String[] args) {
        SpringApplication.run(BalancerOrderApp.class,args);
    }
 
}

5.2.4 模擬測試

啟動(dòng)stock-service和當(dāng)前order模塊，啟動(dòng)完成后，界面調(diào)用：localhost:8033/order/add

loadbalancer默認(rèn)走的是輪詢策略，通過反復(fù)調(diào)用上面的接口，可以看到請求的結(jié)果端口顯示看，是stock-service兩個(gè)服務(wù)輪著來的；

六、寫在文末

在微服務(wù)治理過程中，盡管來說Ribbon現(xiàn)在使用的并不算太多，但Ribbon在springcloud的生態(tài)體系下的出現(xiàn)，可以說具有重要的意義，真正將客戶端負(fù)載均衡的思想進(jìn)行了落地和解決，而且提供了較為完備的負(fù)載均衡策略，給予了開發(fā)者相當(dāng)?shù)臄U(kuò)展性，這也為其他的微服務(wù)治理框架提供了很好的思路。

到此這篇關(guān)于Spring Cloud Ribbon 負(fù)載均衡使用策略示例詳解的文章就介紹到這了,更多相關(guān)Spring Cloud Ribbon 負(fù)載均衡使用策略內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！

最新評論