一：Ribbon簡介
Ribbon是Netflix公司開源的一個負載均衡的項目，是一個客戶端負載均衡器，運行在客戶端上。它是一個經過了云端測試的IPC庫，可以很好地控制HTTP和TCP客戶端的一些行為。Feign已經默認使用了Ribbon。
二：Ribbon的工作流程
1：user微服務1、user微服務2、user微服務3是一個服務集群，它們都會向注冊中心注冊服務（它們的應用名都是USER-SERVICE）
2：注冊中心記錄集群元數據信息，即USER-SERVICE下有3個服務節點
3：Ribbon攔截所有的請求，從請求信息中獲取應用名
4：ribbon根據應用名從eureka注冊中心獲取服務列表
5：ribbon從服務列表中通過相關均衡策略獲取具體某個服務
6：請求遠程服務
三：Ribbon源碼解析
第一步：Ribbon攔截請求，獲取應用名LoadBalancerAutoConfiguration是Ribbon的自動配置類，在這個配置類里面配置了一個攔截器，該攔截器會攔截所有請求，這就是Ribbon的入口
LoadBalancerInterceptor的intercept方法（當遠程調用的時候都會被攔截器攔截）
@Overridepublic ClientHttpResponse intercept(final HttpRequest request, final byte[] body, final ClientHttpRequestExecution execution) throws IOException { final URI originalUri = request.getURI(); String serviceName = originalUri.getHost();//這里就是獲取應用名可以打斷點測試 Assert.state(serviceName != null, "Request URI does not contain a valid hostname: " + originalUri); return this.loadBalancer.execute(serviceName, requestFactory.createRequest(request, body, execution));}
第二步：通過應用名獲取服務列表負載均衡器ZoneAwareLoadBalancer是獲取服務列表的重要組件
@Overridepublic <T> T execute(String serviceId, LoadBalancerRequest<T> request) throws IOException { ILoadBalancer loadBalancer = getLoadBalancer(serviceId);//獲取負載均衡器 Server server = getServer(loadBalancer); if (server == null) { throw new IllegalStateException("No instances available for " + serviceId); } RibbonServer ribbonServer = new RibbonServer(serviceId, server, isSecure(server, serviceId), serverIntrospector(serviceId).getMetadata(server)); return execute(serviceId, ribbonServer, request);}
ILoadBalancer是一個接口，具體的實現類是ZoneAwareLoadBalancer
// Source code recreated from a .class file by IntelliJ IDEA// (powered by Fernflower decompiler)//package com.netflix.loadbalancer;import JAVA.util.List;public interface ILoadBalancer { void addServers(List<Server> var1); //從列表中獲取具體某個服務 Server chooseServer(Object var1); void markServerDown(Server var1); /** @deprecated */ @Deprecated List<Server> getServerList(boolean var1); List<Server> getReachableServers(); //獲取服務列表 List<Server> getAllServers();}
ZoneAwareLoadBalancer負載均衡器是在RibbonClientConfiguration中提前定義的
@Bean@ConditionalOnMissingBeanpublic ILoadBalancer ribbonLoadBalancer(IClientConfig config, ServerList<Server> serverList, ServerListFilter<Server> serverListFilter, IRule rule, IPing ping, ServerListUpdater serverListUpdater) { return (ILoadBalancer)(this.propertiesFactory.isSet(ILoadBalancer.class, this.name) ? (ILoadBalancer)this.propertiesFactory.get(ILoadBalancer.class, config, this.name) : new ZoneAwareLoadBalancer(config, rule, ping, serverList, serverListFilter, serverListUpdater));}
ZoneAwareLoadBalancer的繼承關系圖如下：
getAllServers獲取服務列表，ZoneAwareLoadBalancer沒有定義getAllServers方法，但是父類BaseLoadBalancer定義了該方法
第三步：從列表中獲取具體服務ZoneAwareLoadBalancer定義了獲取服務的方法，但是該方法最終調用的是父類BaseLoadBalancer chooseServer方法
public Server chooseServer(Object key) { if (counter == null) { counter = createCounter(); } counter.increment(); if (rule == null) { return null; } else { try { return rule.choose(key); } catch (Exception e) { logger.warn("LoadBalancer [{}]: Error choosing server for key {}", name, key, e); return null; } }}
默認均衡策略ZoneAvoidanceRule，在RibbonClientConfiguration配置類中配置了IRule bean
均衡策略的接口是IRule，具體實現類有10個：
IRule
這是所有負載均衡策略的父接口，里邊的核心方法就是choose方法，用來選擇一個服務實例。
AbstractLoadBalancerRule
AbstractLoadBalancerRule是一個抽象類，里邊主要定義了一個ILoadBalancer，就是我們上文所說的負載均衡器，負載均衡器的功能我們在上文已經說的很詳細了，這里就不再贅述，這里定義它的目的主要是輔助負責均衡策略選取合適的服務端實例。
RandomRule
看名字就知道，這種負載均衡策略就是隨機選擇一個服務實例，看源碼我們知道，在RandomRule的無參構造方法中初始化了一個Random對象，然后在它重寫的choose方法又調用了choose(ILoadBalancer lb, Object key)這個重載的choose方法，在這個重載的choose方法中，每次利用random對象生成一個不大于服務實例總數的隨機數，并將該數作為下標所以獲取一個服務實例。
RoundRobinRule
RoundRobinRule這種負載均衡策略叫做輪詢負載均衡策略，也就是我們在上文所說的BaseLoadBalancer負載均衡器中默認采用的負載均衡策略。這個類的choose(ILoadBalancer lb, Object key)函數整體邏輯是這樣的：開啟一個計數器count，在while循環中遍歷服務清單，獲取清單之前先通過incrementAndGetModulo方法獲取一個下標，這個下標是一個不斷自增長的數先加1然后和服務清單總數取模之后獲取到的（所以這個下標從來不會越界），拿著下標再去服務清單列表中取服務，每次循環計數器都會加1，如果連續10次都沒有取到服務，則會報一個警告No available alive servers after 10 tries from load balancer: XXXX。
RetryRule
看名字就知道這種負載均衡策略帶有重試功能。首先RetryRule中又定義了一個subRule，它的實現類是RoundRobinRule，然后在RetryRule的choose(ILoadBalancer lb, Object key)方法中，每次還是采用RoundRobinRule中的choose規則來選擇一個服務實例，如果選到的實例正常就返回，如果選擇的服務實例為null或者已經失效，則在失效時間deadline之前不斷的進行重試（重試時獲取服務的策略還是RoundRobinRule中定義的策略），如果超過了deadline還是沒取到則會返回一個null。
WeightedResponseTimeRule
WeightedResponseTimeRule是RoundRobinRule的一個子類，在WeightedResponseTimeRule中對RoundRobinRule的功能進行了擴展，WeightedResponseTimeRule中會根據每一個實例的運行情況來給計算出該實例的一個權重，然后在挑選實例的時候則根據權重進行挑選，這樣能夠實現更優的實例調用。WeightedResponseTimeRule中有一個名叫DynamicServerWeightTask的定時任務，默認情況下每隔30秒會計算一次各個服務實例的權重，權重的計算規則也很簡單，如果一個服務的平均響應時間越短則權重越大，那么該服務實例被選中執行任務的概率也就越大。
ClientConfigEnabledRoundRobinRule
ClientConfigEnabledRoundRobinRule選擇策略的實現很簡單，內部定義了RoundRobinRule，choose方法還是采用了RoundRobinRule的choose方法，所以它的選擇策略和RoundRobinRule的選擇策略一致，不贅述。
BestAvailableRule
BestAvailableRule繼承自ClientConfigEnabledRoundRobinRule，它在ClientConfigEnabledRoundRobinRule的基礎上主要增加了根據loadBalancerStats中保存的服務實例的狀態信息來過濾掉失效的服務實例的功能，然后順便找出并發請求最小的服務實例來使用。然而loadBalancerStats有可能為null，如果loadBalancerStats為null，則BestAvailableRule將采用它的父類即ClientConfigEnabledRoundRobinRule的服務選取策略（線性輪詢）。
PredicateBasedRule
PredicateBasedRule是ClientConfigEnabledRoundRobinRule的一個子類，它先通過內部定義的一個過濾器過濾出一部分服務實例清單，然后再采用線性輪詢的方式從過濾出來的結果中選取一個服務實例。
ZoneAvoidanceRule(Finchley.SR1版本中默認均衡策略)
ZoneAvoidanceRule是PredicateBasedRule的一個實現類，只不過這里多一個過濾條件，ZoneAvoidanceRule中的過濾條件是以ZoneAvoidancePredicate為主過濾條件和以AvailabilityPredicate為次過濾條件組成的一個叫做CompositePredicate的組合過濾條件，過濾成功之后，繼續采用線性輪詢的方式從過濾結果中選擇一個出來。
四：自定義均衡策略
在引導類中配置負載均衡策略
@Beanpublic IRule myRule(){ //return new RoundRobinRule();//輪詢 // return new RetryRule();//重試 return new BestAvailableRule();}
