SpringCloud 服務負載均衡和呼叫 Ribbon、OpenFeign
阿新 • • 發佈:2020-09-04
# 1、Ribbon
Spring Cloud Ribbon是基於Netflix Ribbon實現的—套客戶端―負載均衡的工具。
簡單的說,Ribbon是Netlix釋出的開源專案,主要功能是提供客戶端的軟體負載均衡演算法和服務呼叫。Ribbon客戶端元件提供一系列完善的配置項如連線超時,重試等。簡單的說,就是在配置檔案中列出Load Balancer(簡稱LB)後面所有的機器,Ribbon會自動的幫助你基於某種規則(如簡單輪詢,隨機連線等)去連線這些機器。我們很容易使用Ribbon實現自定義的負載均衡演算法。
目前Ribbon和Eureka進入到維護模式。停更不停用
> 負載均衡:
**LB負載均衡(Load Balance)是什麼?**
簡單的說就是將使用者的請求平攤的分配到多個服務上,從而達到系統的HA(高可用)。1
常見的負載均衡有軟體Nginx,LVS,硬體F5等。
**Ribbon本地負載均衡客戶端VS Nginx服務端負載均衡區別**
Nginx是伺服器負載均衡,客戶端所有請求都會交給nginx,然後由nginx實現轉發請求。即負載均衡是由服務端實現的。
Ribbon本地負載均衡,在呼叫微服務介面時候,會在註冊中心上獲取註冊資訊服務列表之後快取到VM本地,從而在本地實現RPC遠
程服務呼叫技術。
1、集中式LB
即在服務的消費方和提供方之間使用獨立的LB設施(可以是硬體,如F5,也可以是軟體,如nginx)由該設施負責把訪問請求通過某種策咯轉發至服務的提供方;
2、程序內LB
將LB邏輯整合到消費方,消費方從服務註冊中心獲知有哪些地址可用,然後自己再從這些地址中選擇出一個合適的伺服器。Ribbon就屬於程序內LB,它只是一個類庫,集成於消費方程序,消費方通過它來獲取到服務提供方的地址。
負載均衡 +RestTemplate 配合使用
> 架構
總結:Ribbon其實就是一個軟負載均衡的客戶端元件,他可以和其他所需請求的客戶端結合使用,和eureka結合只是其中的一個例項.
![image-20200822132451805](https://img2020.cnblogs.com/blog/1557466/202009/1557466-20200904153047847-1993260186.png)
Ribbon在工作時分成兩步
第一步先選擇EurekaServer ,它優先選擇在同一個區域內負載較少的server.
第二步再根據使用者指定的策略,在從server取到的服務註冊列表中選擇一個地址。
其中Ribbon提供了多種策略:比如輪詢、隨機和根據響應時間加權。
```
pom 依賴
spring-cloud-starter-netflix-eureka-client
自身 就集成了 ribbon 。
```
RestTemplate說明:
![image-20200822133134902](https://img2020.cnblogs.com/blog/1557466/202009/1557466-20200904153047598-1476550294.png)
> Ribbon負載均衡規則
繼承結構
![image-20200822134205708](https://img2020.cnblogs.com/blog/1557466/202009/1557466-20200904153047403-1220822072.png)
自帶7種:
![image-20200822134245453](https://img2020.cnblogs.com/blog/1557466/202009/1557466-20200904153047194-2122039660.png)
如何使用?負載均衡策略替換。
官方文件明確給出了**警告**:
這個自定義配置類不能放在@ComponentScan所掃描的當前包下以及子包下,
否則我們自定義的這個配置類就會被所有的Ribbon客戶端所共享,達不到特殊化定製的目的了。
增加rule配置類
```java
包路徑: com.fage.rules
@Configuration
public class MyRibbonRule {
@Bean
public IRule randomRule() {
return new RandomRule();
}
}
```
boot啟動類增加註解
```
@RibbonClient(name = "cloud-payment-service", configuration = {MyRibbonRule.class})
```
> 負載均衡輪詢演算法原理
負載均衡演算法: rest介面第幾次請求數%伺服器叢集總數量=實際呼叫伺服器位置下標,每次服務重啟動後rest介面計數從1開始。
List instances = discoveryClient.getlnstances(CLOUD-PAYMENT-SERVICE");
如:List [o] instances = 127.0.0.1:8002
List [1] instances = 127.0.0.1:8001
8001+8002組合成為叢集,它們共計2臺機器,叢集總數為2,按照輪詢演算法原理:
當總請求數為1時:1%2=1對應下標位置為1,則獲得服務地址為127.0.0.1:8001
當總請求數位2時: 2%2=O對應下標位置為0,則獲得服務地址為127.0.0.1:8002
當總請求數位3時:3%2=1對應下標位置為1,則獲得服務地址為127.0.0.1:8001
當總請求數位4時:4%2=0對應下標位置為0,則獲得服務地址為127.0.0.1:8002
如此類推......
原始碼:
從0開始取餘獲取提供者服務。
**內部使用cas+自旋鎖。**
> 手寫一個負載均衡演算法,實現輪詢
1、服務提供者增加介面
```java
@GetMapping("/payment/loadBalanced")
public CommonResult