前言

前情回顧

上一講深入的講解了Ribbon的初始化過程及Ribbon與Eureka的整合程式碼，與Eureka整合的類就是DiscoveryEnableNIWSServerList，同時在DynamicServerListLoadBalancer中會呼叫PollingServerListUpdater 進行定時更新Eureka登錄檔資訊到BaseLoadBalancer中，預設30s排程一次。

本講目錄

我們知道Ribbon主要是由3個元件組成的：

1. ILoadBalancer
2. IRule
3. IPing

其中ILoadBalancer前面我們已經分析過了，接下來我們一起看看IRule和IPing

中的具體實現。

目錄如下：

1. 負載均衡預設Server選擇邏輯
2. Ribbon實際執行http請求邏輯
3. Ribbon中ping機制原理
4. Ribbon中其他IRule負載演算法初探

說明

原創不易，如若轉載 請標明來源！

部落格地址：一枝花算不算浪漫
微信公眾號：壹枝花算不算浪漫

原始碼分析

負載均衡預設Server選擇邏輯

還記得我們上一講說過，在Ribbon初始化過程中，預設的IRule為ZoneAvoidanceRule，這裡我們可以通過debug看看，從RibbonLoadBalancerClient.getServer() 一路往下跟，這裡直接看debug結果：

然後我們繼續跟ZoneAvoidanceRule.choose()

方法：

public abstract class PredicateBasedRule extends ClientConfigEnabledRoundRobinRule {
   
    /**
     * Method that provides an instance of {@link AbstractServerPredicate} to be used by this class.
     * 
     */
    public abstract AbstractServerPredicate getPredicate();
        
    /**
     * Get a server by calling {@link AbstractServerPredicate#chooseRandomlyAfterFiltering(java.util.List, Object)}.
     * The performance for this method is O(n) where n is number of servers to be filtered.
     */
    @Override
    public Server choose(Object key) {
        ILoadBalancer lb = getLoadBalancer();
        Optional<Server> server = getPredicate().chooseRoundRobinAfterFiltering(lb.getAllServers(), key);
        if (server.isPresent()) {
            return server.get();
        } else {
            return null;
        }       
    }
}
 

這裡是呼叫的ZoneAvoidanceRule的父類中的choose()方法，首先是拿到對應的ILoadBalancer,然後拿到對應的serverList資料，接著呼叫chooseRoundRobinAfterFiltering()方法，繼續往後跟：

public abstract class AbstractServerPredicate implements Predicate<PredicateKey> {

    public Optional<Server> chooseRoundRobinAfterFiltering(List<Server> servers, Object loadBalancerKey) {
        List<Server> eligible = getEligibleServers(servers, loadBalancerKey);
        if (eligible.size() == 0) {
            return Optional.absent();
        }
        return Optional.of(eligible.get(incrementAndGetModulo(eligible.size())));
    }

    private int incrementAndGetModulo(int modulo) {
        for (;;) {
            int current = nextIndex.get();
            int next = (current + 1) % modulo;
            if (nextIndex.compareAndSet(current, next) && current < modulo)
                return current;
        }
    }
}

到了這裡可以看到incrementAndGetModulo()方法就是處理serverList輪詢的演算法，這個和RoudRobinRule中採用的是一樣的演算法，這個演算法大家可以品一品，我這裡也會畫個圖來說明下：

看了圖=中的例子估計大家都會明白了，這個演算法就是依次輪詢。這個演算法寫的很精簡。

Ribbon實際執行http請求邏輯

我們上面知道，我們按照輪詢的方式從serverList取到一個server後，那麼怎麼把之前原有的類似於：http://ServerA/sayHello/wangmeng中的ServerA給替換成請求的ip資料呢？

接著我們繼續看RibbonLoadBalancerClient.execute()方法，這個裡面request.apply()會做一個serverName的替換邏輯。

最後可以一步步跟到RibbonLoadBalancerClient.reconstructURI()，這個方法是把請求自帶的getURI方法給替換了，我們最後檢視context.reconstructURIWithServer() 方法，debug結果如圖，這個裡面會一步步把對應的請求url給拼接起來：

Ribbon中ping機制原理

我們知道 Ribbon還有一個重要的元件就是ping機制，通過上一講Ribbon的初始化我們知道，預設的IPing實現類為：NIWSDiscoveryPing，我們可以檢視其中的isAlive()方法：

public class NIWSDiscoveryPing extends AbstractLoadBalancerPing {
            
        BaseLoadBalancer lb = null; 
        

        public NIWSDiscoveryPing() {
        }
        
        public BaseLoadBalancer getLb() {
            return lb;
        }

        /**
         * Non IPing interface method - only set this if you care about the "newServers Feature"
         * @param lb
         */
        public void setLb(BaseLoadBalancer lb) {
            this.lb = lb;
        }

        public boolean isAlive(Server server) {
            boolean isAlive = true;
            if (server!=null && server instanceof DiscoveryEnabledServer){
                DiscoveryEnabledServer dServer = (DiscoveryEnabledServer)server;                
                InstanceInfo instanceInfo = dServer.getInstanceInfo();
                if (instanceInfo!=null){                    
                    InstanceStatus status = instanceInfo.getStatus();
                    if (status!=null){
                        isAlive = status.equals(InstanceStatus.UP);
                    }
                }
            }
            return isAlive;
        }

        @Override
        public void initWithNiwsConfig(
                IClientConfig clientConfig) {
        }
        
}

這裡就是獲取到DiscoveryEnabledServer對應的註冊資訊是否為UP狀態。那麼 既然有個ping的方法，肯定會有方法進行排程的。

我們可以檢視isAlive()呼叫即可以找到排程的地方。
在BaseLoadBalancer建構函式中會呼叫setupPingTask()方法，進行排程：

protected int pingIntervalSeconds = 10;

void setupPingTask() {
    if (canSkipPing()) {
        return;
    }
    if (lbTimer != null) {
        lbTimer.cancel();
    }
    lbTimer = new ShutdownEnabledTimer("NFLoadBalancer-PingTimer-" + name,
            true);
    lbTimer.schedule(new PingTask(), 0, pingIntervalSeconds * 1000);
    forceQuickPing();
}

這裡pingIntervalSeconds在BaseLoadBalancer中定義的是10s，但是在initWithConfig()方法中，通過傳入的時間覆蓋了原本的10s，這裡實際的預設時間是30s。如下程式碼：

我們也可以通過debug來看看：

可能大家好奇為什麼要單獨截圖來說這個事，其實是因為網上好多部落格講解都是錯的，都寫的是ping預設排程時間為10s，想必他們都是沒有真正debug過吧。

還是那句話，原始碼出真知。

Ribbon中其他IRule負載演算法初探

1. RoundRobinRule：系統內建的預設負載均衡規範，直接round robin輪詢，從一堆server list中，不斷的輪詢選擇出來一個server，每個server平攤到的這個請求，基本上是平均的

   這個演算法，說白了是輪詢，就是一臺接著一臺去請求，是按照順序來的

2. AvailabilityFilteringRule：這個rule就是會考察伺服器的可用性

   如果3次連線失敗，就會等待30秒後再次訪問；如果不斷失敗，那麼等待時間會不斷變長
   如果某個伺服器的併發請求太高了，那麼會繞過去，不再訪問

   這裡先用round robin演算法，輪詢依次選擇一臺server，如果判斷這個server是存活的可用的，如果這臺server是不可以訪問的，那麼就用round robin演算法再次選擇下一臺server，依次迴圈往復，10次。

3. WeightedResponseTimeRule：帶著權重的，每個伺服器可以有權重，權重越高優先訪問，如果某個伺服器響應時間比較長，那麼權重就會降低，減少訪問

4. ZoneAvoidanceRule：根據機房和伺服器來進行負載均衡，說白了，就是機房的意思，看了原始碼就是知道了，這個就是所謂的spring cloud ribbon環境中的預設的Rule

5. BestAvailableRule：忽略那些請求失敗的伺服器，然後儘量找併發比較低的伺服器來請求

總結

到了這裡 Ribbon相關的就結束了，對於Ribbon登錄檔拉取及更新邏輯這裡也梳理下，這裡如果Ribbon儲存的登錄檔資訊有宕機的情況，這裡最多4分鐘才能感知到，所以spring cloud還有一個服務熔斷的機制，這個後面也會講到。

申明

本文章首發自本人部落格：https://www.cnblogs.com/wang-meng 和公眾號：壹枝花算不算浪漫，如若轉載請標明來源!

感興趣的小夥伴可關注個人公眾號：壹枝花算不算浪漫

相關推薦