溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
這篇“SpringCloud Ribbon負載均衡使用策略是什么”文章的知識點大部分人都不太理解，所以小編給大家總結了以下內容，內容詳細，步驟清晰，具有一定的借鑒價值，希望大家閱讀完這篇文章能有所收獲，下面我們一起來看看這篇“SpringCloud Ribbon負載均衡使用策略是什么”文章吧。
Spring Cloud Ribbon 是基于Netflix Ribbon 實現的一套客戶端負載均衡工具，Ribbon客戶端組件提供了一系列的完善的配置，如超時，重試等。
通過Load Balancer獲取到服務提供的所有機器實例，Ribbon會自動基于某種規則(輪詢，隨機)去調用這些服務。Ribbon也可以實現我們自己的負載均衡算法。
負載均衡這個概念大家都不陌生，幾乎可以說是互聯網公司標配，目前主流負載方案主要分為以下兩種：
集中式負載均衡，在消費者和服務提供方中間使用獨立的代理方式進行負載，有硬件的（比如 F5），也有軟件的（比如 Nginx）；客戶端根據自身請求情況做負載均衡，Ribbon 就屬于客戶端自己做負載均衡，在dubbo中，客戶端也可以配置負載均衡策略，也是類似的思想；
顧名思義，就是由客戶端根據自身的情況做負載均衡策略的選擇或配置，比如spring cloud中的ribbon，簡單來說，當服務提供者將自身的服務注冊到服務注冊中心之后，客戶端相應的會維護一個服務器地址列表，在發送請求前，先通過負載均衡算法選擇一個服務器，然后進行訪問，這就是客戶端負載均衡，即在客戶端就進行負載均衡算法分配。
如下，為ribbon作為客戶端的負載均衡的調用流程圖。
即集中式的管控負載均衡策略的組件，比如Nginx，即所有的請求過來之后，先通過Nginx進行負載均衡，先發送請求到具體的微服務，然后通過nginx中配置的負載均衡算法，在多個服務器之間選擇一個進行訪問，即在服務器端再進行負載均衡算法分配。
下面列舉日常開發中經常用到的一些負載均衡算法，可以說很多組件的負載均衡的底層算法思想都是大同小異
通過隨機選擇集群中的某個可用的服務進行請求執行，在集群的各服務器配置差不多的情況下可以考慮使用，一般這種方式使用較少
負載均衡默認的實現方式，請求過來之后，依次輪流從可用服務中選擇進行處理
通過對服務器性能的分型，給高配置，低負載的服務器分配更高的權重，均衡各個服務器的壓力;
根據請求的地址進行Hash，通過客戶端請求的地址的HASH值取模映射進行服務器調度， ip --->hash，這樣相同請求的IP將會被打到相同的服務器處理；
即使請求均衡了，壓力也不一定會均衡，最小連接數法就是根據服務器的情況，比如請求積壓數等參數，將請求分配到當前壓力最小的服務器上，最小連接數也叫最小活躍數。
在springcloud-alibaba整合nacos中，客戶端通過nacos進行服務調用默認使用的就是Ribbon負載均衡，只需下面兩步
添加一個RestTemplate 的配置bean，使用LoadBalanced注解標注
@Configuration
public class RestConfig {
@Bean
@LoadBalanced
public RestTemplate restTemplate(){
return new RestTemplate();
}
}具體調用的時候，仍然使用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;
}
}通過完整的類的依賴關系圖，可以看到Ribbon提供了很多種負載均衡策略，下面就Ribbon中常用的負載均衡策略做詳細的解讀。
這是所有負載均衡策略的父接口，里邊的核心方法就是choose方法，用來選擇一個服務實例
一個抽象類，里邊主要定義了一個ILoadBalancer，這里定義它的目的主要是輔助負責均衡策略選取合適的服務端實例。
這種負載均衡策略就是隨機從多個服務實例中選擇一個服務實例
通過源碼發現，在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;
}
}RoundRobinRule 這種負載均衡策略也叫線性輪詢負載均衡策略
這個類的choose(ILoadBalancer lb, Object key)方法整體邏輯是這樣的：
開啟一個計數器count，在while循環中遍歷務清單，獲取清單之前先通過incrementAndGetModulo方法獲取一個下標，這個下標是一個不斷自增長的數先加1然后和服務清單總數取模之后獲取到的（所以這個下標從來不會越界）；
然后拿著下標再去服務清單列表中取服務，每次循環計數器都會加1，如果連續10次都沒有取到服務，則會報一個警告No available alive servers after 10 tries from load balancer: XXXX；
在輪詢基礎上重試，即這種負載均衡策略帶有重試功能
它整體工作流程是這樣：
首先RetryRule中定義了一個subRule，它的實現類是RoundRobinRule；
然后在RetryRule的choose(ILoadBalancer lb, Object key)方法中，每次還是采用RoundRobinRule中的choose規則來選擇一個服務實例；
如果選到的實例正常就返回，如果選擇的服務實例為null或者已經失效，則在失效時間deadline之前不斷的進行重試（重試時獲取服務的策略還是RoundRobinRule中定義的策略）；
如果超過了deadline還是沒取到則會返回一個null；
顧名思義，帶有權重功能，權重 — nacos的NacosRule ，Nacos還擴展了一個自己的基于配置的權重擴展
大致工作原理如下：
WeightedResponseTimeRule是RoundRobinRule的一個子類，在WeightedResponseTimeRule中對RoundRobinRule的功能進行了擴展；
WeightedResponseTimeRule中會根據每一個實例的運行情況來給計算出該實例的一個權重，然后在挑選實例的時候則根據權重進行挑選，這樣能夠實現更優的實例調用；
WeightedResponseTimeRule中有一個名叫DynamicServerWeightTask的定時任務，默認情況下每隔30秒會計算一次各個服務實例的權重；
權重計算規則很簡單，如果一個服務的平均響應時間越短則權重越大，那么該服務實例被選中執行任務的概率也就越大；
這種策略實現很簡單，內部定義了RoundRobinRule，choose方法還是采用了RoundRobinRule的 choose方法，所以它的選擇策略和RoundRobinRule的選擇策略一致，就不再過多不贅述。
BestAvailableRule繼承自ClientConfigEnabledRoundRobinRule；
它在ClientConfigEnabledRoundRobinRule的基礎上主要增加了根據loadBalancerStats中保存的服務實例的狀態信息來過濾掉失效的服務實例的功能，然后順便找出并發請求最小的服務實例來使用；
然而loadBalancerStats有可能為null，如果loadBalancerStats為null，則BestAvailableRule將采用它的父類即ClientConfigEnabledRoundRobinRule的服務選取策略（線性輪詢）；
默認規則 ，復合判斷server所在區域的性能和server的可用性選擇服務器
ZoneAvoidanceRule是PredicateBasedRule的一個實現類，只不過這里多一個過濾條件；
ZoneAvoidanceRule中的過濾條件是以ZoneAvoidancePredicate為主過濾條件和以AvailabilityPredicate為次過濾條件組成的一個叫做CompositePredicate的組合過濾條件；
過濾成功之后，繼續采用線性輪詢(RoundRobinRule)的方式從過濾結果中選擇一個出來；
先過濾掉故障實例，再選擇并發較小的實例，具體來說，過濾掉一直連接失敗的被標記為circuit tripped的后端Server，并過濾掉那些高并發的后端Server或者使用一個AvailabilityPredicate來 包含過濾server的邏輯，其實就是檢查status里記錄的各個Server的運行狀態。
上面詳細了解了Ribbon中的常用的一些負載均衡配置策略，接下來通過實際操作演示下如何修改Ribbon的負載均衡配置策略。
這是一種比較靈活的修改配置方式，只需要添加一個配置類，并配置指定的負載均衡bean即可
注意這里有個坑，自定義的配置類不能寫在@SpringbootApplication注解的@CompentScan掃描得到的地方，否則自定義的配置類就會被所有的 RibbonClients共享。
因此實際開發中不建議這么使用，推薦yml方式
工程的目錄結構如下
RibbonRandomRuleConfig 配置類
@Configuration
public class RibbonRandomRuleConfig {
@Bean
public IRule iRule(){
return new RandomRule();
}
}@SpringBootApplication
@RibbonClients(value = {
@RibbonClient(name = "stock-service",configuration = RibbonRandomRuleConfig.class)
})
public class RibbonOrderApp {
public static void main(String[] args) {
SpringApplication.run(RibbonOrderApp.class,args);
}
}分別啟動stock-service的兩個工程，再啟動order工程，stock-service可以在idea中通過區分端口的方式
啟動完成之后，檢查nacos，可以看到stock-service有兩個服務實例，這正好是我們希望的
調用order模塊的接口：http://localhost:8030/order/add，由于是客戶端負載均衡，而且我們配置的是隨機的策略，預計在隨機調用該接口之后，會呈現出不同的接口
多調用幾次，可以看到8021與8023對應的服務不斷交替出現，并且沒什么規律
去掉啟動類中的注解信息
@SpringBootApplication
/*@RibbonClients(value = {
@RibbonClient(name = "stock-service",configuration = RibbonRandomRuleConfig.class)
})*/
public class RibbonOrderApp {
public static void main(String[] args) {
SpringApplication.run(RibbonOrderApp.class,args);
}
}在配置文件下方增加如下配置，這里是哦也能夠的是nacos提供的基于權重的策略，也可以選擇其他的；
stock-service: ribbon: NFLoadBalancerRuleClassName: com.alibaba.cloud.nacos.ribbon.NacosRule
在nacos服務列表那一欄，進入到如下所示 stock-servide具體的詳情頁面
分別編輯兩個實例的權重大小，比如這里給8023實例權重為10，另一個保持默認為1
設置完成后按照預期猜想，設置權重更高的那個將會優先得到訪問的機會，啟動order服務，再次按照上面的方式調用多次觀察效果
粗略統計發現，在10多次的請求中，權重高的那個被訪問的次數更多，這也就符合我們的預期效果了；
從上面的ribbon類圖可以發現，通過實現 IRule 接口可以自定義負載策略，主要的選擇服務邏輯在 choose 方法中完成，最簡單的就是繼承AbstractLoadBalancerRule這個抽象類；
只需要繼承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) {
}
}stock-service: ribbon: #NFLoadBalancerRuleClassName: com.alibaba.cloud.nacos.ribbon.NacosRule #使用自定義的負載均衡策略 NFLoadBalancerRuleClassName: com.ribbon.CustomRule
將上一步的nacos中stock-service的兩個服務實例的權重都調整為1，然后再次訪問接口，可以看到呈現出隨機的效果；
Ribbon的負載均衡策略默認是懶加載，意味著只有在發起調用的時候才會創建客戶端，這帶來的問題是，如果網絡不好，第一次調用的時候可能會出現調用超時，我們通過控制臺日志也能看出來；
如何解決這個問題呢？可以手動開啟饑餓加載，來解決第一次調用慢的問題，只需要在配置文件中添加如下配置即可；
ribbon: eager-load: # 開啟ribbon饑餓加載 enabled: true # 配置stock-service使用ribbon饑餓加載，多個使用逗號分隔 clients: stock-service
再次重啟order服務，通過控制臺輸出日志可以看到，在啟動的時候負載均衡策略就被加載了；
Spring Cloud LoadBalancer是Spring Cloud官方自己提供的客戶端負載均衡器, 用來替代
Ribbon
Spring 官方提供了兩種負載均衡客戶端
RestTemplate是 Spring提供的用于訪問Rest服務的客戶端，RestTemplate提供了多種便捷訪問遠程Http服務的方法，能夠大大提高客戶端的編寫效率。默認情況下，RestTemplate默認依賴jdk的HTTP連接工具
WebClient是從Spring WebFlux 5.0版本開始提供的一個非阻塞的基于響應式編程的進行Http請求的客戶端工具。它的響應式編程的基于Reactor的。WebClient中提供了標準Http請求方式對應的get、post、put、delete等方法，可以用來發起相應的請求
<dependencies> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <!--nacos-config 配置中心-自帶動態刷新--> <!--<dependency> <groupId>com.alibaba.cloud</groupId> <artifactId>spring-cloud-starter-alibaba-nacos-config</artifactId> </dependency>--> <!--nacos-discovery 注冊中心-服務發現與注冊--> <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>
這里主要是將默認的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
@SpringBootApplication
//@EnableDiscoveryClient
public class BalancerOrderApp {
public static void main(String[] args) {
SpringApplication.run(BalancerOrderApp.class,args);
}
}啟動stock-service和當前order模塊，啟動完成后，界面調用：localhost:8033/order/add
loadbalancer默認走的是輪詢策略，通過反復調用上面的接口，可以看到請求的結果端口顯示看，是stock-service兩個服務輪著來的；
以上就是關于“SpringCloud Ribbon負載均衡使用策略是什么”這篇文章的內容，相信大家都有了一定的了解，希望小編分享的內容對大家有幫助，若想了解更多相關的知識內容，請關注億速云行業資訊頻道。
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
