點選上方“芋道原始碼”，選擇“置頂公眾號”

技術文章第一時間送達！

摘要: 原創出處 https://www.cnkirito.moe/rpc-cluster/ 「老徐」歡迎轉載，保留摘要，謝謝！

• 叢集概述

• 負載均衡

• 負載均衡介面分析

• 幾種負載均衡演演算法

• 高可用策略

• 高可用介面分析

• 其他叢集相關的知識點

• 參考資料

上一篇文章分析了服務的註冊與發現，這一篇文章著重分析下 RPC 框架都會用到的叢集的相關知識。

叢集(Cluster)本身並不具備太多知識點，在分散式系統中，叢集一般涵蓋了負載均衡（LoadBalance），高可用（HA），路由（Route）等等概念，每個 RPC 框架對叢集支援的程度不同，本文著重分析前兩者–負載均衡和高可用。

叢集概述

在此之前的《深入理解 RPC》系列文章，對 RPC 的分析著重還是放在服務之間的點對點呼叫，而分散式服務中每個服務必然不止一個實體，不同服務的實體和相同服務的多個實體構成了一個錯綜複雜的分散式環境，在服務治理框架中正是藉助了 Cluster 這一層來應對這一難題。還是以博主較為熟悉的 motan 這個框架來介紹 Cluster 的作用。

先來看看 Cluster 的頂層介面：

@Spi(scope = Scope.PROTOTYPE)
public interface Cluster<T> extends Caller<T> {
    @Override
    void init();
    void setUrl(URL url);
    void setLoadBalance(LoadBalance loadBalance);//<1>
    void setHaStrategy(HaStrategy haStrategy);//<2>
    void onRefresh(List> referers);
    List> getReferers();
    LoadBalance getLoadBalance();
}

在概述中，我們只關心 Cluster 介面中的兩個方法，它揭示了 Cluster 在服務治理中的地位

<1> 指定負載均衡演演算法

<2> 指定高可用策略（容錯機制）

http://ov0zuistv.bkt.clouddn.com/TIM%E5%9B%BE%E7%89%8720180227151838.png

我們需要對所謂的負載均衡策略和高可用策略有一定的理解，才能夠搞清楚叢集是如何運作的。

負載均衡

說到負載均衡，大多數人可能立刻聯想到了 nginx。負載均衡可以分為服務端負載均衡和客戶端負載均衡，而服務端負載均衡又按照實現方式的不同可以劃分為軟體負載均衡和硬體負載均衡，nginx 便是典型的軟體負載均衡。而我們今天所要介紹的 RPC 中的負載均衡則主要是客戶端負載均衡。如何區分也很簡單，用筆者自己的話來描述下

在 RPC 呼叫中，客戶端持有所有的服務端節點取用，自行透過負載均衡演演算法選擇一個節點進行訪問，這便是客戶端負載均衡。

客戶端如何獲取到所有的服務端節點取用呢？一般是透過配置的方式，或者是從上一篇文章介紹的服務註冊與發現元件中獲取。

負載均衡介面分析

motan 中的負載均衡抽象：

@Spi(scope = Scope.PROTOTYPE)
public interface LoadBalance<T> {
    void onRefresh(List> referers);
    Referer select(Request request);//<1>
    void selectToHolder(Request request, List> refersHolder);
    void setWeightString(String weightString);
}

ribbon 中的負載均衡抽象：

public interface IRule{
    public Server choose(Object key);//<1>
    public void setLoadBalancer(ILoadBalancer lb);
    public ILoadBalancer getLoadBalancer();
}

<1> 對比下兩個 RPC 框架對負載均衡的抽象可以發現，其實負載均衡策略乾的事很簡單，就是根據請求傳回一個服務節點。在 motan 中對服務端的點對點呼叫抽象成了 Referer，而在 ribbon 中則是 Server。

幾種負載均衡演演算法

負載均衡演演算法有幾種經典實現，已經是老生常談了，總結後主要有如下幾個：

1. 輪詢（Round Robin）

2. 加權輪詢（Weight Round Robin）

3. 隨機（Random）

4. 加權隨機（Weight Random）

5. 源地址雜湊（Hash）

6. 一致性雜湊（ConsistentHash）

7. 最小連線數（Least Connections）

8. 低併發優先（Active Weight）

每個框架支援的實現都不太一樣，如 ribbon 支援的負載均衡策略：

motan 支援的負載均衡策略：

演演算法很多，有些負載均衡演演算法的實現複雜度也很高，請教了一些朋友，發現用的最多還是 RoundRobin，Random 這兩種。可能和他們實現起來很簡單有關，很多運用到 RPC 框架的專案也都是保持了預設配置。

而這兩種經典複雜均衡演演算法實現起來是很簡單的，在此給出網上的簡易實現，方便大家更直觀的瞭解。

服務串列

public class IpMap
{
    // 待路由的Ip串列，Key代表Ip，Value代表該Ip的權重
    public static HashMap serverWeightMap =
            new HashMap();
    static
    {
        serverWeightMap.put("192.168.1.100", 1);
        serverWeightMap.put("192.168.1.101", 1);
        // 權重為4
        serverWeightMap.put("192.168.1.102", 4);
        serverWeightMap.put("192.168.1.103", 1);
        serverWeightMap.put("192.168.1.104", 1);
        // 權重為3
        serverWeightMap.put("192.168.1.105", 3);
        serverWeightMap.put("192.168.1.106", 1);
        // 權重為2
        serverWeightMap.put("192.168.1.107", 2);
        serverWeightMap.put("192.168.1.108", 1);
        serverWeightMap.put("192.168.1.109", 1);
        serverWeightMap.put("192.168.1.110", 1);
    }
}

輪詢（Round Robin）

public class RoundRobin
{
    private static Integer pos = 0;

    public static String getServer()
    {
        // 重建一個Map，避免伺服器的上下線導致的併發問題
        Map serverMap =
                new HashMap();
        serverMap.putAll(IpMap.serverWeightMap);

        // 取得Ip地址List
        Set keySet = serverMap.keySet();
        ArrayList keyList = new ArrayList();
        keyList.addAll(keySet);

        String server = null;
        synchronized (pos)
        {
            if (pos > keySet.size())
                pos = 0;
            server = keyList.get(pos);
            pos ++;
        }

        return server;
    }
}

隨機（Random）

public class Random
{
    public static String getServer()
    {
        // 重建一個Map，避免伺服器的上下線導致的併發問題
        Map serverMap =
                new HashMap();
        serverMap.putAll(IpMap.serverWeightMap);

        // 取得Ip地址List
        Set keySet = serverMap.keySet();
        ArrayList keyList = new ArrayList();
        keyList.addAll(keySet);

        java.util.Random random = new java.util.Random();
        int randomPos = random.nextInt(keyList.size());

        return keyList.get(randomPos);
    }
}

高可用策略

高可用（HA）策略一般也被稱作容錯機制，分散式系統中出錯是常態，但服務卻不能停止響應，6個9一直是各個公司的努力方向。當一次請求失敗之後，是重試呢？還是繼續請求其他機器？抑或是記錄下這次失敗？下麵是叢集中的幾種常用高可用策略：

1. 失效轉移（failover）

   當出現失敗，重試其他伺服器，通常用於讀操作等冪等行為，重試會帶來更長延遲。該高可用策略會受到負載均衡演演算法的限制，比如失效轉移強調需要重試其他機器，但一致性 Hash 這類負載均衡演演算法便會與其存在衝突（個人認為一致性 Hash 在 RPC 的客戶端負載均衡中意義不是很大）

2. 快速失敗（failfast）

   只發起一次呼叫，失敗立即報錯，通常用於非冪等性的寫操作。

   如果在 motan，dubbo 等配置中設定了重試次數>0，又配置了該高可用策略，則重試效果也不會生效，由此可見叢集中的各個配置可能是會相互影響的。

3. 失效安全（failsafe）

   出現異常時忽略，但記錄這一次失敗，存入日誌中。

4. 失效自動恢復（failback）

   後臺記錄失敗請求，定時重發。通常用於訊息通知操作。

5. 並行呼叫（forking）

   只要一個成功即傳回，通常用於實時性要求較高的讀操作。需要犧牲一定的服務資源。

6. 廣播（broadcast）

   廣播呼叫，所有提供逐個呼叫，任意一臺報錯則報錯。通常用於更新提供方本地狀態，速度慢，任意一臺報錯則報錯。

高可用介面分析

以 motan 的 HaStrategy 為例來介紹高可用在叢集中的實現細節

@Spi(scope = Scope.PROTOTYPE)
public interface HaStrategy<T> {
    void setUrl(URL url);
    Response call(Request request, LoadBalance loadBalance);//<1>
}

<1> 如我之前所述，高可用策略依賴於請求和一個特定的負載均衡演演算法，傳回一個響應。

快速失敗（failfast）

@SpiMeta(name = "failfast")
public class FailfastHaStrategy<T> extends AbstractHaStrategy<T> {

    @Override
    public Response call(Request request, LoadBalance loadBalance) {
        Referer refer = loadBalance.select(request);
        return refer.call(request);
    }
}

motan 實現了兩個高可用策略，其一便是 failfast，非常簡單，只進行一次負載均衡節點的選取，接著發起點對點的呼叫。

失效轉移（failover）

@SpiMeta(name = "failover")
public class FailoverHaStrategy<T> extends AbstractHaStrategy<T> {

    protected ThreadLocal>> referersHolder = new ThreadLocal>>() {
        @Override
        protected java.util.List> initialValue() {
            return new ArrayList>();
        }
    };

    @Override
    public Response call(Request request, LoadBalance loadBalance) {

        List> referers = selectReferers(request, loadBalance);
        if (referers.isEmpty()) {
            throw new MotanServiceException(String.format("FailoverHaStrategy No referers for request:%s, loadbalance:%s", request,
                    loadBalance));
        }
        URL refUrl = referers.get(0).getUrl();
        // 先使用method的配置
        int tryCount =
                refUrl.getMethodParameter(request.getMethodName(), request.getParamtersDesc(), URLParamType.retries.getName(),
                        URLParamType.retries.getIntValue());
        // 如果有問題，則設定為不重試
        if (tryCount 0) {
            tryCount = 0;
        }
       // 只有 failover 策略才會有重試
        for (int i = 0; i <= tryCount; i++) {
            Referer refer = referers.get(i % referers.size());
            try {
                request.setRetries(i);
                return refer.call(request);
            } catch (RuntimeException e) {
                // 對於業務異常，直接丟擲
                if (ExceptionUtil.isBizException(e)) {
                    throw e;
                } else if (i >= tryCount) {
                    throw e;
                }
                LoggerUtil.warn(String.format("FailoverHaStrategy Call false for request:%s error=%s", request, e.getMessage()));
            }
        }

        throw new MotanFrameworkException("FailoverHaStrategy.call should not come here!");
    }

    protected List> selectReferers(Request request, LoadBalance loadBalance) {
        List> referers = referersHolder.get();
        referers.clear();
        loadBalance.selectToHolder(request, referers);
        return referers;
    }

}

其二的高可用策略是 failover，實現相對複雜一些，容忍在重試次數內的失敗呼叫。這也是 motan 提供的預設策略。

其他叢集相關的知識點

在 Dubbo 中也有 cluster 這一分層，除了 loadbalance 和 ha 這兩層之外還包含了路由（Router）用來做讀寫分離，應用隔離；合併結果（Merger）用來做響應結果的分組聚合。

在 SpringCloud-Netflix 中整合了 Zuul 來做服務端的負載均衡

參考資料

1. 幾種簡單的負載均衡演演算法及其Java程式碼實現

2. 搜尋業務和技術介紹及容錯機制

666. 彩蛋