一、前言

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

二、什么是 Ribbon

2.1 ribbon簡介

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

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

2.1.1  ribbon在負載均衡中的角色

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

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

2.2 客戶端負載均衡

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

如下，為ribbon作為客戶端的負載均衡的調用流程圖。

2.3 服務端負載均衡

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

2.4 常用負載均衡算法

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

2.4.1 隨機算法

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

2.4.2 輪詢算法

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

2.4.3 加權輪詢算法

通過對服務器性能的分型，給高配置，低負載的服務器分配更高的權重，均衡各個服務器的壓力;

2.4.4 IP地址hash

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

2.4.5 最小鏈接數

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

三、Ribbon中負載均衡策略總探究

3.1 nacos中使用ribbon過程

在上一篇，springcloud-alibaba整合nacos中，客戶端通過nacos進行服務調用默認使用的就是Ribbon負載均衡，只需下面兩步

3.1.1 添加配置類

添加一個RestTemplate 的配置bean，使用LoadBalanced注解標注

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

3.1.2 接口層調用

具體調用的時候，仍然使用restTemplate調用即可，如果服務端有多個實例，將會自動走默認負載均衡策略；

@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中負載均衡配置策略

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

3.2.1 IRule

這是所有負載均衡策略的父接口，里邊的核心方法就是choose方法，用來選擇一個服務實例

3.2.2  AbstractLoadBalancerRule

一個抽象類，里邊主要定義了一個ILoadBalancer，這里定義它的目的主要是輔助負責均衡策略選取合適的服務端實例。

3.2.3  RandomRule

這種負載均衡策略就是隨機從多個服務實例中選擇一個服務實例

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

可以參閱源碼

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 這種負載均衡策略也叫線性輪詢負載均衡策略

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

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

3.2.5  RetryRule

在輪詢基礎上重試，即這種負載均衡策略帶有重試功能

它整體工作流程是這樣：

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

3.2.6 WeightedResponseTimeRule

顧名思義，帶有權重功能，權重 — nacos的NacosRule ，Nacos還擴展了一個自己的基于配置的權重擴展 

大致工作原理如下：

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

3.2.7 ClientConfigEnabledRoundRobinRule

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

3.2.8 BestAvailableRule

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

3.2.9 ZoneAvoidanceRule

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

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

3.2.10 AvailabilityFilteringRule

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

四、Ribbon負載均衡策略修改

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

4.1  通過配置類方式修改

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

4.1.1  增加一個負載均衡策略配置類

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

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

工程的目錄結構如下

RibbonRandomRuleConfig 配置類

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

4.1.2  啟動類指定負載均衡配置類

@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  測試負載均衡策略是否生效

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

啟動完成之后，檢查nacos，可以看到stock-service有兩個服務實例，這正好是我們希望的

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

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

4.2  通過配置文件方式修改

4.2.1 修改啟動類

去掉啟動類中的注解信息

@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 配置文件指定具體的負載均衡策略

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

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

4.2.3 修改stock-service 的權重配置

在nacos服務列表那一欄，進入到如下所示 stock-servide具體的詳情頁面

分別編輯兩個實例的權重大小，比如這里給8023實例權重為10，另一個保持默認為1

設置完成后按照預期猜想，設置權重更高的那個將會優(yōu)先得到訪問的機會，啟動order服務，再次按照上面的方式調用多次觀察效果

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

 4.3 自定義負載均衡策略

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

4.3.1 自定義負載均衡類

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

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
    #使用自定義的負載均衡策略
    NFLoadBalancerRuleClassName: com.ribbon.CustomRule

4.3.3 啟動工程并測試

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

4.3.4 ribbon負載均衡懶加載模式

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

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

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

再次重啟order服務，通過控制臺輸出日志可以看到，在啟動的時候負載均衡策略就被加載了；

五、Spring Cloud LoadBalancer

5.1 概述

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

Spring 官方提供了兩種負載均衡客戶端

5.1.1 RestTemplate

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

5.1.2 Webclient

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

5.2  RestTemplate 整合LoadBalancer

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

 <dependencies>
 
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
        </dependency>
 
        <!--nacos-config 配置中心-自帶動態(tài)刷新-->
        <!--<dependency>
            <groupId>com.alibaba.cloud</groupId>
            <artifactId>spring-cloud-starter-alibaba-nacos-config</artifactId>
        </dependency>-->
 
        <!--nacos-discovery 注冊中心-服務發(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  添加如下配置文件

這里主要是將默認的ribbon的loadbalancer負載均衡策略禁用掉

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

5.2.3 啟動類

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

5.2.4 模擬測試

啟動stock-service和當前order模塊，啟動完成后，界面調用：localhost:8033/order/add

loadbalancer默認走的是輪詢策略，通過反復調用上面的接口，可以看到請求的結果端口顯示看，是stock-service兩個服務輪著來的；

六、寫在文末

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

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

最新評論