之前我們說了dubbo超時重試啟動檢查等配置,接下來我們說一下dubbo高可用的一些配置

1. zookeeper宕機

我們接下來討論一下如果zookeeper宕機對我們的服務提供者消費者有什麼影響

現象：zookeeper註冊中心宕機，還可以消費dubbo暴露的服務。

原因：

• 監控中心宕掉不影響使用，只是丟失部分取樣資料
• 資料庫宕掉後，註冊中心仍能通過快取提供服務列表查詢，但不能註冊新服務
• 註冊中心對等叢集，任意一臺宕掉後，將自動切換到另一臺
• 註冊中心全部宕掉後，服務提供者和服務消費者仍能通過本地快取通訊
• 服務提供者無狀態，任意一臺宕掉後，不影響使用
• 服務提供者全部宕掉後，服務消費者應用將無法使用，並無限次重連等待服務提供者恢復

高可用：通過設計，減少系統不能提供服務的時間

例子：

我們在消費者中睡眠20秒,然後我們在這20秒時間內停掉註冊中心,看看第二次消費能否成功

public class App 
    {
    
        public static void main( String[] args ) throws Exception
        {
            ClassPathXmlApplicationContext context = new ClassPathXmlApplicationContext
 
(
                    new String[] { "classpath:customer.xml" });
            final IUserService demoService = (IUserService) context.getBean("userService");
            System.out.println(demoService.getUser());
            System.out.println("程式執行第一次......");
            Thread.sleep(1000*20);
            System.
 
out.println(demoService.getUser());
            System.out.println("程式執行第二次......");
            System.in.read();
    
        }
    }

接下來我們一次啟動服務提供者 消費者 然後停掉服務註冊中心

可以看到

我們的服務消費者在註冊中心宕機後讓然可以呼叫服務提供者提供的服務。但是註冊中心宕機後我們不能再註冊新的服務。

2. Dubbo直連

在開發及測試環境下，經常需要繞過註冊中心，只測試指定服務提供者，這時候可能需要點對點直連，點對點直連方式，將以服務介面為單位，忽略註冊中心的提供者列表，A 介面配置點對點，不影響 B 介面從註冊中心獲取列表。

注意 為了避免複雜化線上環境，不要在線上使用這個功能，只應在測試階段使用。我們可以在開發的時候使用此方式進行除錯

    <dubbo:reference id="userService" interface="com.yz.dubbo.api.IUserService" check="false" version="1.0.0" url="dubbo://127.0.0.1:20882"></dubbo:reference>

我們啟動我們的服務註冊中心與服務提供者消費

發現我們的消費者並沒有註冊到服務註冊中心,但是我們仍然可以呼叫服務提供者提供的服務

我們實現了跨註冊中心 直連服務提供者

3. 負載均衡

在叢集負載均衡時，Dubbo 提供了多種均衡策略，預設為 random 隨機呼叫。

負載均衡策略

• Random LoadBalance

  隨機，按權重設定隨機概率。

• RoundRobin LoadBalance

  輪詢，按公約後的權重設定輪詢比率。

• LeastActive LoadBalance

  最少活躍呼叫數，相同活躍數的隨機，活躍數指呼叫前後計數差。

• ConsistentHash LoadBalance

  一致性 Hash，相同引數的請求總是發到同一提供者。

接下來我們測試一下預設的隨機方式

  <dubbo:service interface="com.yz.dubbo.api.IUserService" ref="userService1" version="1.0.0" loadbalance="random"></dubbo:service>

我們啟動多個服務提供者,並指定不同的埠號,在實現中通過來區分不同的提供者

    System.out.println("被呼叫了1............");
    System.out.println("被呼叫了2............");

接下來我們啟動多個服務提供者來模擬,並通過Admin控制檯中的 倍權 半權 來調節權重 ,結果如下

接下來我們啟動服務消費者模擬消費者多次消費

我們模擬了六次可以看到控制檯輸出

    被呼叫了0............
    被呼叫了0............
    被呼叫了1............
    被呼叫了0............
    被呼叫了0............
    被呼叫了0............

實現了呼叫多個服務提供者,並實現了負載均衡

4. 服務降級

當我伺服器的壓力比較大的時候,我們可以通過服務降級功能 臨時遮蔽某個出錯的非關鍵服務，並定義降級後的返回策略,遮蔽掉不重要的服務如廣告服務等,來降低核心業務的壓力

• mock=force:return+null 表示消費方對該服務的方法呼叫都直接返回 null 值，不發起遠端呼叫。用來遮蔽不重要服務不可用時對呼叫方的影響。
• 還可以改為 mock=fail:return+null 表示消費方對該服務的方法呼叫在失敗後，再返回 null 值，不拋異常。用來容忍不重要服務不穩定時對呼叫方的影響。

我們可以直接在Admin控制檯來操作服務降級,服務消費者中的遮蔽相當於不發起遠端呼叫,

容錯相當於對該服務的方法呼叫在失敗後，再返回 null 值

遮蔽

我們遮蔽我們的應用yzcustomer

發現提供者並沒有呼叫且返回null

容錯

我們容錯我們的應用yzcustomer,並手動使我們的提供者出錯,啟動服務提供者和消費者

發現在呼叫服務提供者出錯時,返回null

5. 叢集容錯

在叢集呼叫失敗時，Dubbo 提供了多種容錯方案，預設為 failover 重試。

Failover Cluster

失敗自動切換，當出現失敗，重試其它伺服器 。通常用於讀操作，但重試會帶來更長延遲。可通過 retries="2" 來設定重試次數(不含第一次)。

Failfast Cluster

快速失敗，只發起一次呼叫，失敗立即報錯。通常用於非冪等性的寫操作，比如新增記錄。

Failsafe Cluster

失敗安全，出現異常時，直接忽略。通常用於寫入審計日誌等操作。

Failback Cluster

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

Forking Cluster

並行呼叫多個伺服器，只要一個成功即返回。通常用於實時性要求較高的讀操作，但需要浪費更多服務資源。可通過 forks="2" 來設定最大並行數。

Broadcast Cluster

廣播呼叫所有提供者，逐個呼叫，任意一臺報錯則報錯 。通常用於通知所有提供者更新快取或日誌等本地資源資訊。

叢集模式配置

按照以下示例在服務提供方和消費方配置叢集模式

  <dubbo:service cluster="failsafe" />

或

    <dubbo:reference cluster="failsafe" />

dubbo的配置我們就先介紹這麼多,還有很多像本地存根以及整合Hystrix都沒有介紹,等我有了更深刻的認識我再繼續記錄

文章連結