D‘E‘LET　　Spring Cloud Ribbon 是一個基於HTTP 和 TCP的客戶端負載均衡工具，它基於Netflix Ribbon實現。通過 SpringCloud的封裝，可以讓我們輕松的將面向服務的REST模板請求自動轉換成客戶端負載均衡的服務調用。Spring CLoud Ribbon雖然只是一個工具類框架，它不像服務註冊中國心，配置中心，API網關那樣需要獨立部署，但是它幾乎存在每一個SpringCloud構建的微服務和基礎設施中，因為為服務間的調用，API網關的請求轉發等內容，實際上都是通過Ribbon來實現的，包括後續我們介紹的Feign。

客戶端負載均衡

　　負載均衡在系統架構中是一個非常重要，並且是不得不去實施的內容。因為負載均衡對系統的高可用，網絡壓力的緩解和處理能力的擴容的重要手段之一。我們通常所說的負載均衡都是服務端負載均衡，其中分為硬件負載均衡和軟件負載均衡。硬件負載均衡主要通過在服務器節點之間安裝專門用於負載均衡的設備，比如F5等；而軟件負載均衡則是通過在服務器上安裝一些具有負載均衡功能或模塊的軟件來完成請求分發工作。只要是服務端負載均衡都能以類似的下圖架構方式搭建起來：

　　硬件負載均衡的設備或是軟件負載均衡的軟件模塊都會維護一個下掛可用的服務端清單，通過心跳檢測來剔除故障的服務端節點以保障清單中都是可以正常訪問的服務端節點。當客戶端發送請求道負載均衡設備時，該設備按某種算法，比如線性輪詢，按權重負載，按流量負載從維護的可用服務清單中取出一天服務端的地址，然後進行轉發。

　　而客戶端負載均衡和服務端負載均衡最大的不同點在於上面所提到的服務清單所出存儲的位置。在客戶端負載均衡中，所有客戶端節點都維護著自己想要訪問的服務端清單，而這些服務端的清單來自於服務註冊中心，。

　　通過Spring Cloud Ribbon的封裝，我們在微服務架構中使用客戶端負載均衡調用非常簡單，只需要如下兩步：

1.服務提供者只需要啟動多個服務實例並註冊到一個註冊中心或是多個相關聯的服務註冊中心。

2.服務消費者直接通過調用被@LoadBalanced註解修飾過的RestTemplate來實現面向服務的接口調用。

這樣，我們就可以將服務提供者的高可用及消費者的負載均衡條用在一起實現了。

RestTemplate詳解

　　RestTemplate，該對象會使用Ribbon的自動化配置，同時通過配置@LoadBalanced還能夠開啟客戶端負載均衡。

GET請求

　　在RestTemplate中，對GET請求可以通過如下兩個方法進行調用實現。

POST請求

　　在RestTemplate中，對POST請求時可以通過如下三個方法進行調用實現。

PUT請求

DELETE請求

負載均衡策略

1. ILoadBalancer：是負載均衡的入口類。
2. ServerList：存儲遠程服務所有可用節點
3. ServerListFilter：用於過濾非法的遠程節點（如：不可用等）
4. IRule：負載算法（策略），用於從可用節點選擇一個合適的節點。
5. RestClient：遠程調用

<dependency>
       <groupId>org.springframework.cloud</groupId>
       <artifactId>spring-cloud-starter-ribbon</artifactId>
   </dependency>

Ribbon的負載均衡策略

1、RoundRobinRule(輪詢模式) public class RoundRobinRule extends AbstractLoadBalancerRule roundRobin方式輪詢選擇server 輪詢index，選擇index對應位置的server 該策略也是ribbon的默認策略

2、RandomRule(隨機策略) public class RandomRule extends AbstractLoadBalancerRule 隨機選擇一個server 在index上隨機，選擇index對應位置的server。

3、BestAvailableRule（並發量） public class BestAvailableRule extends ClientConfigEnabledRoundRobinRule 選擇一個最小的並發請求的server 逐個考察Server，如果Server被tripped了，則忽略，在選擇其中ActiveRequestsCount最小的server

4、AvailabilityFilteringRule(服務器狀態) public class AvailabilityFilteringRule extends PredicateBasedRule 過濾掉那些因為一直連接失敗的被標記為circuit tripped的後端server，並過濾掉那些高並發的的後端server（active connections 超過配置的閾值） 使用一個AvailabilityPredicate來包含過濾server的邏輯，其實就就是檢查status裏記錄的各個server的運行狀態

5、WeightedResponseTimeRule（根據響應時間） public class WeightedResponseTimeRule extends RoundRobinRule 根據響應時間分配一個weight，相應時間越長，weight越小，被選中的可能性越低。 一個後臺線程定期的從status裏面讀取評價響應時間，為每個server計算一個weight。Weight的計算也比較簡單responsetime 減去每個server自己平均的responsetime是server的權重。當剛開始運行，沒有形成statas時，使用roubine策略選擇server。

6、RetryRule(根據策略+重試) public class RetryRule extends AbstractLoadBalancerRule 對選定的負載均衡策略機上重試機制。 在一個配置時間段內當選擇server不成功，則一直嘗試使用subRule的方式選擇一個可用的server

7、ZoneAvoidanceRule（Zone狀態+服務狀態） public class ZoneAvoidanceRule extends PredicateBasedRule 復合判斷server所在區域的性能和server的可用性選擇server 使用ZoneAvoidancePredicate和AvailabilityPredicate來判斷是否選擇某個server，前一個判斷判定一個zone的運行性能是否可用，剔除不可用的zone（的所有server），AvailabilityPredicate用於過濾掉連接數過多的Server。

自動化配置

由於Ribbon中定義的每一個接口都有多種不同的策略實現，同時這些接口之間又有一定的依賴關系，這使得第一次使用Ribbon的開發者很難上手，不知道如何選擇具體的實現策略和以及如何組織他們的關系。Spring Cloud Ribbon中的自動化配置恰恰能夠解決這樣的痛點，在引入SpringCloudRibbon以來之後，就能夠自動化構建下面這些接口的實現。

通過自動化配置的實現，我們可以輕松實現客戶端負載均衡，同時，針對一些個性化需求，我們也可以方便的替換上面的這些默認實現。

只需要在SpringBoot應用中創建對應的應用實例就可以覆蓋這些默認的配置實現。

重試機制

Spring Cloud Ribbon