ribbon如何配置重拾

『壹』 ribbon負載均衡詳解

服務端負載均衡：在客戶端和服務端中間使用代理，lvs  和 nginx。

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

客戶端負載均衡：根據自己的情況做負載。Ribbon。

客戶端負載均衡和服務端負載均衡最大的區別在於 服務端地址列表的存儲位置，以及負載演算法在哪裡。

2、Spring Cloud的負載均衡機制的實現

Spring Cloud Ribbon是一個基於HTTP和TCP的客戶端負載均衡工具，它基於Netflix Ribbon實現。通過Spring Cloud的封裝，可以讓我們輕松地將面向服務的REST模版請求自動轉換成客戶端負載均衡的服務調用。Ribbon實現客戶端的負載均衡，負載均衡器提供很多對http和tcp的行為控制。Spring cloud Feign已經集成Ribbon，所以註解@FeignClient的類，默認實現了ribbon的功能。

Ribbon主要包括如下功能

1.支持通過DNS和IP和服務端通信

2.可以根據演算法從多個服務中選取一個服務進行訪問

3.通過將客戶端和伺服器分成幾個區域（zone）來建立客戶端和伺服器之間的關系。客戶端盡量訪問和自己在相同區域(zone)的服務，減少服務的延遲

4.保留伺服器的統計信息，ribbon可以實現用於避免高延遲或頻繁訪問故障的伺服器

5.保留區域(zone)的統計數據，ribbon可以實現避免可能訪問失效的區域(zone)

Ribbon負載均衡主要是通過LoadBalancerClient類實現的，而LoadBalancerClient又將具體處理委託給ILoadBalancer處理；

每個服務都有一個ILoadBalancer，ILoadBalancer裡面有該服務列表。

每個服務 Map<服務名，ILoadBalancer>

ILoadBalancer通過配置IRule、IPing等信息，並通過ServerList獲取伺服器注冊列表的信息，默認以每10s的頻率想服務列表中每個服務實例發送ping請求，檢測服務實例是否存活，最後使用負責均衡策略對ServerListFilter過濾得到最終可用的服務實例列表進行處理，然後交給服務調用器進行調用；

ILoadBalance也是一個介面，提供了3個具體實現，分別是DynamicServerListLoadBalancer、ZoneAwareLoadBalancer和NoOpLoadBalancer；

DynamicServerListLoadBalancer繼承自ILoadBalancer基礎實現BaseLoadBalancer，在基礎的負載均衡功能上增加了運行期間對服務實例動態更新和過濾的功能；

NoOpLoadBalancer沒有操作的實現；

ZoneAwareLoadBalancer（ILoadBalancer的默認的實現類是：ZoneAwareLoadBalancer。）則是繼承DynamicServerListLoadBalancer，在此基礎上增加防止跨區域訪問的問題；

首先它會剔除符合這些規則的Zone區域：所屬實例數位零的Zone區域；Zone區域內實例等平均負載小於零，或者實例故障率（斷路器斷開次數／實例數）大於等於閥值（默認為0.99999）。

然後根據Zone區域等實例平均負載計算出最差的Zone區域，這里的最差指的是實例平均負載最高的Zone區域。

如果在上面的過程中沒有符合剔除要求的區域，同時實例最大平均負載小於閥值（默認為20%），就直接返回所有Zone區域為可用區域。否則，從最壞Zone區域集合中隨機選擇一個，將它從可用Zone區域集合中剔除。

 ▪️當獲得的可用Zone區域集合不為空，並且個數小於Zone區域總數，就隨機選擇一個Zone區域。

▪️在確定了某個Zone區域後，則獲取了對應Zone區域的服務均衡器，並調用chooseServer來選擇具體的服務實例，而在chooseServer中將使用IRule介面的choose函數來選擇具體的服務實例。在這里，IRule介面的實現會使用ZoneAvoidanceRule來挑選出具體的服務實例。

服務列表就是客戶端負載均衡所使用的(同一注冊中心集群)各服務的服務實例列表。Ribbon在實現上支持以下幾種服務列表方式

靜態伺服器列表：通過Ribbon的BaseLoadBalancer所提供的setServerList()方法，初始化時直接進行動態設置指定；

基於配置的伺服器列表：需要在項目配置文件中通過<服務名稱>.ribbon.listOfServers進行設置。（如user-service.ribbon.listOfServers=http://127.0.0.1:8082,http://127.0.0.1:8083）

基於服務發現的伺服器列表：同時使用Ribbon和Eureka時，默認使用該方式，在應用啟動時Ribbon就會從Eureka伺服器中獲取所有注冊服務的列表數據，並保持同步。

該組件會對原始服務列表使用一定策略進行過濾返回有效可用的伺服器列表給客戶端負載均衡器使用。常用服務列表過濾器如下：ZoneAffinityServerListFilter：基於區域感知的方式，實現對服務實例的過濾，僅返回與本身所處區域一直的服務提供者實例列表；ServerListSubsetFilter：該過濾器繼承自ZoneAffinityServerListFilter，在進行區域感知過濾後，僅返回一個固定大小的服務列表。默認將返回20個服務實例，可以通過ribbon.ServerListSubsetFilter.size進行設置；

：使用Eureka和Ribbon時默認的過濾器。實現通過配置或者Eureka所屬區域來過濾出同區域的服務實例列表。

它實現了通過配置或者Eureka實例元數據的所屬區域（Zone）來過濾出同區域的服務實例。如下面的源碼所示，它的實現非常簡單，首先通過父類ZoneAffinityServerListFilter的過濾器來獲得「區域感知」的服務實例列表，然後遍歷這個結果，取出根據消費者配置預設的區域Zone來進行過濾，如果過濾掉結果是空就直接返回父類獲取的結果，如果不為空就返回通過消費者配置的Zone過濾後的結果。

用來檢測一個微服務實例是否存活是否有響應，Ribbon通過該組件來判斷所持有的服務實例列表中各服務可用情況，如果檢測到某服務實例不存在/一定時間未響應，則會從持有服務列表中及時移除。

PingUrl：通過定期訪問指定的URL判斷；

PingConstant：不做任何處理，只返回一個固定值，用來表示該服務是否可用，默認值為true；

NoOpPing：不做任何處理，直接返回true，表示該伺服器可用，默認策略；

DummyPing：直接返回true，但實現了initWithNiwsConfig方法；

NIWSDiscoverPing：根據DiscoveryEnabledServer中InstanceInfo的InstanceStatus屬性判斷，如果該屬性的值為InstanceStatus.UP，則表示伺服器可用；

作用就是選擇一個最終服務實例地址作為負載均衡處理結果。Ribbon提供的選擇策略有隨機 (Random)、輪詢 (RoundRobin)、一致性哈希 (ConsistentHash)、哈希 (Hash)、加權（Weighted）。

IRule負載均衡策略：通過實現該介面定義自己的負載均衡策略。它的choose方法就是從一堆伺服器列表中按規則選出一個伺服器。

默認實現：

ZoneAvoidanceRule（區域權衡策略）：復合判斷Server所在區域的性能和Server的可用性，輪詢選擇伺服器。

其他規則：

BestAvailableRule（最低並發策略）：會先過濾掉由於多次訪問故障而處於斷路器跳閘狀態的服務，然後選擇一個並發量最小的服務。逐個找服務，如果斷路器打開，則忽略。

RoundRobinRule（輪詢策略）：以簡單輪詢選擇一個伺服器。按順序循環選擇一個server。

RandomRule（隨機策略）：隨機選擇一個伺服器。

AvailabilityFilteringRule（可用過濾策略）：會先過濾掉多次訪問故障而處於斷路器跳閘狀態的服務和過濾並發的連接數量超過閥值得服務，然後對剩餘的服務列表安裝輪詢策略進行訪問。

WeightedResponseTimeRule（響應時間加權策略）：據平均響應時間計算所有的服務的權重，響應時間越快服務權重越大，容易被選中的概率就越高。剛啟動時，如果統計信息不中，則使用RoundRobinRule(輪詢)策略，等統計的信息足夠了會自動的切換到WeightedResponseTimeRule。響應時間長，權重低，被選擇的概率低。反之，同樣道理。此策略綜合了各種因素（網路，磁碟，IO等），這些因素直接影響響應時間。

RetryRule（重試策略）：先按照RoundRobinRule(輪詢)的策略獲取服務，如果獲取的服務失敗則在指定的時間會進行重試，進行獲取可用的服務。如多次獲取某個服務失敗，就不會再次獲取該服務。主要是在一個時間段內，如果選擇一個服務不成功，就繼續找可用的服務，直到超時。

1. <clientName>：這是調用ribbon的客戶端名稱，如果此值為沒有配置，則此條屬性會作用到所有的客戶端。

2. <nameSpace>：默認值為 「ribbon」

3. <propertyName>：所有的可用的屬性都在com.netflix.client.conf.CommonClientConfigKey。

<clientName>.<nameSpace>.NFLoadBalancerClassName=xx

<clientName>.<nameSpace>.NFLoadBalancerRuleClassName=xx

<clientName>.<nameSpace>.NFLoadBalancerPingClassName=xx

<clientName>.<nameSpace>.NIWSServerListClassName=xx

<clientName>.<nameSpace>.NIWSServerListFilterClassName=xx

com.netflix.client.config.IClientConfig：Ribbon的客戶端配置，默認採用com.netflix.client.config.DefaultClientConfigImpl實現。

com.netflix.loadbalancer.IRule：Ribbon的負載均衡策略，默認採用com.netflix.loadbalancer.ZoneAvoidanceRule實現，該策略能夠在多區域環境下選出最佳區域的實例進行訪問。

com.netflix.loadbalancer.IPing：Ribbon的實例檢查策略，默認採用com.netflix.loadbalancer.NoOpPing實現，該檢查策略是一個特殊的實現，實際上它並不會檢查實例是否可用，而是始終返回true，默認認為所有服務實例都是可用的。

com.netflix.loadbalancer.ServerList：服務實例清單的維護機制，默認採用com.netflix.loadbalancer.ConfigurationBasedServerList實現。

com.netflix.loadbalancer.ServerListFilter：服務實例清單過濾機制，默認采org.springframework.cloud.netflix.ribbon.，該策略能夠優先過濾出與請求方處於同區域的服務實例。

com.netflix.loadbalancer.ILoadBalancer：負載均衡器，默認採用com.netflix.loadbalancer.ZoneAwareLoadBalancer實現，它具備了區域感知的能力。

上面的配置是在項目中沒有引入spring Cloud Eureka，如果引入了Eureka和Ribbon依賴時，自動化配置會有一些不同。

通過自動化配置的實現，可以輕松的實現客戶端的負載均衡。同時，針對一些個性化需求，我們可以方便的替換上面的這些默認實現，只需要在springboot應用中創建對應的實現實例就能覆蓋這些默認的配置實現。

@Configuration

public class MyRibbonConfiguration {

    @Bean

    public IRule ribbonRule(){

        return new RandomRule();

    }

}

這樣就會使用P使用了RandomRule實例替代了默認的com.netflix.loadbalancer.ZoneAvoidanceRule。

也可以使用@RibbonClient註解實現更細粒度的客戶端配置

對於Ribbon的參數通常有二種方式：全局配置以及指定客戶端配置

全局配置的方式很簡單

只需要使用ribbon.<key>=<value>格式進行配置即可。其中，<key>代表了Ribbon客戶端配置的參數名，<value>則代表了對應參數的值。比如，我們可以想下面這樣配置Ribbon的超時時間

ribbon.ConnectTimeout=250

ribbon.ServerListRefreshInterval=2000   ribbon獲取服務定時時間

全局配置可以作為默認值進行設置，當指定客戶端配置了相應的key的值時，將覆蓋全局配置的內容

指定客戶端的配置方式

<client>.ribbon.<key>=<value>的格式進行配置.<client>表示服務名，比如沒有服務治理框架的時候（如Eureka），我們需要指定實例清單，可以指定服務名來做詳細的配置，

user-service.ribbon.listOfServers=localhost:8080,localhost:8081,localhost:8082

對於Ribbon參數的key以及value類型的定義，可以通過查看com.netflix.client.config.CommonClientConfigKey類。

當在spring Cloud的應用同時引入Spring cloud Ribbon和Spring Cloud Eureka依賴時，會觸發Eureka中實現的對Ribbon的自動化配置。這時的serverList的維護機制實現將被com.netflix.niws.loadbalancer.的實例所覆蓋，該實現會講服務清單列表交給Eureka的服務治理機制來進行維護。IPing的實現將被com.netflix.niws.loadbalancer.NIWSDiscoveryPing的實例所覆蓋，該實例也將實例介面的任務交給了服務治理框架來進行維護。默認情況下，用於獲取實例請求的ServerList介面實現將採用Spring Cloud Eureka中封裝的org.springframework.cloud.netflix.ribbon.eureka.DomainExtractingServerList，其目的是為了讓實例維護策略更加通用，所以將使用物理元數據來進行負載均衡，而不是使用原生的AWS AMI元數據。在與Spring cloud Eureka結合使用的時候，不需要再去指定類似的user-service.ribbon.listOfServers的參數來指定具體的服務實例清單，因為Eureka將會為我們維護所有服務的實例清單，而對於Ribbon的參數配置，我們依然可以採用之前的兩種配置方式來實現。

此外，由於spring Cloud Ribbon默認實現了區域親和策略，所以，可以通過Eureka實例的元數據配置來實現區域化的實例配置方案。比如可以將不同機房的實例配置成不同的區域值，作為跨區域的容器機制實現。而實現也非常簡單，只需要服務實例的元數據中增加zone參數來指定自己所在的區域，比如：

eureka.instance.metadataMap.zone=shanghai

在Spring Cloud Ribbon與Spring Cloud Eureka結合的工程中，我們可以通過參數禁用Eureka對Ribbon服務實例的維護實現。這時又需要自己去維護服務實例列表了。

ribbon.eureka.enabled=false.

由於Spring Cloud Eureka實現的服務治理機制強調了cap原理的ap機制（即可用性和可靠性），與zookeeper這類強調cp（一致性，可靠性）服務質量框架最大的區別就是，Eureka為了實現更高的服務可用性，犧牲了一定的一致性，在極端情況下寧願接受故障實例也不要丟棄"健康"實例。

比如說，當服務注冊中心的網路發生故障斷開時候，由於所有的服務實例無法維護續約心跳，在強調ap的服務治理中將會把所有服務實例剔除掉，而Eureka則會因為超過85%的實例丟失心跳而觸發保護機制，注冊中心將會保留此時的所有節點，以實現服務間依然可以進行互相調用的場景，即使其中有部分故障節點，但這樣做可以繼續保障大多數服務的正常消費。

在Camden版本，整合了spring retry來增強RestTemplate的重試能力，對於我們開發者來說，只需要簡單配置，即可完成重試策略。

spring.cloud.loadbalancer.retry.enabled=true

hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds=10000

user-service.ribbon.ConnectTimeout=250

user-service.ribbon.ReadTimeout=1000

user-service.ribbon.OkToRetryOnAllOperations=true

user-service.ribbon.MaxAutoRetriesNextServer=2

user-service.ribbon.maxAutoRetries=1

spring.cloud.loadbalancer.retry.enabled:該參數用來開啟重試機制，它默認是關閉的。

hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds：斷路器的超時時間需要大於Ribbon的超時時間，不然不會觸發重試。

user-service.ribbon.ConnectTimeout：請求連接超時時間。

user-service.ribbon.ReadTimeout：請求處理的超時時間

user-service.ribbon.OkToRetryOnAllOperations：對所有操作請求都進行重試。

user-service.ribbon.MaxAutoRetriesNextServer：切換實例的重試次數。

user-service.ribbon.maxAutoRetries：對當前實例的重試次數。

根據以上配置，當訪問到故障請求的時候，它會再嘗試訪問一次當前實例（次數由maxAutoRetries配置），如果不行，就換一個實例進行訪問，如果還是不行，再換一個實例訪問（更換次數由MaxAutoRetriesNextServer配置），如果依然不行，返回失敗

項目啟動的時候會自動的為我們載入LoadBalancerAutoConfiguration自動配置類，該自動配置類初始化條件是要求classpath必須要有RestTemplate這個類，必須要有LoadBalancerClient實現類。

LoadBalancerAutoConfiguration為我們幹了二件事，第一件是創建了LoadBalancerInterceptor攔截器bean，用於實現對客戶端發起請求時進行攔截，以實現客戶端負載均衡。創建了一個

RestTemplateCustomizer的bean，用於給RestTemplate增加LoadBalancerInterceptor攔截器。

每次請求的時候都會執行org.springframework.cloud.client.loadbalancer.LoadBalancerInterceptor的intercept方法，而LoadBalancerInterceptor具有LoadBalancerClient（客戶端負載客戶端）實例的一個引用，

在攔截器中通過方法獲取服務名的請求url（比如http://user-service/user），及服務名（比如user-service），然後調用負載均衡客戶端的execute方法。

執行負載客戶端RibbonLoadBalancerClient（LoadBalancerClient的實現）的execute方法，得到ILoadBalancer（負載均衡器）的實現ZoneAwareLoadBalancer，並且通過調用其chooseServer方法獲得服務列表中的一個實例，比如說user-service列表注冊到eureka中一個實例。然後向其中的一個具體實例發起請求，得到結果。

Ribbon詳解 

https://www.jianshu.com/p/1bd66db5dc46

Spring cloud系列六 Ribbon的功能概述、主要組件和屬性文件配置  

https://blog.csdn.net/hry2015/article/details/78357990

Ribbon的ZoneAwareLoadBalancer  

https://blog.csdn.net/chengqiuming/article/details/81209131

Ribbon的實際使用

https://www.jianshu.com/p/f86af82fa782

本人有道雲筆記中記錄的參考文章

文檔：04_ribbon 負載均衡.note

鏈接：http://note.you.com/noteshare?id=&sub=