Dubbo面試常見問題

一、dubbo是什么？

dubbo是⼀個分布式服務框架，提供⾼性能和透明化的RPC遠程服務調⽤⽅案，以及SOA服務治理方案。說白了其實dubbo就是一個遠程調用的分布式框架。

二、dubbo的核心服務是什么？

Dubbo的作用以及介紹

特性 描述
透明遠程調用 就像調用本地方法一樣調用遠程方法；只需簡單配置，沒有任何API侵入；
負載均衡機制 Client端LB，可在內網替代F5等硬件負載均衡器；
容錯重試機制 服務Mock數據，重試次數、超時機制等；
自動注冊發現 注冊中心基於接口名查詢服務提 供者的IP地址，並且能夠平滑添加或刪除服務提供者；
性能日志監控 Monitor統計服務的調用次調和調用時間的監控中心；
服務治理中心 路由規則，動態配置，服務降級，訪問控制，權重調整，負載均衡，等手動配置。
自動治理中心 無，比如：熔斷限流機制、自動權重調整等；

三、看一下dubbo架構圖

 

 

四、服務提供者暴露一個服務的詳細過程：

如果你仔細觀察dubbo的啟動日志你會發現，dubbo的provider啟動主要是以下幾個過程

 

1.首先provider啟動時，先把想要提供的服務暴露在本地。

2.然后再把服務暴露到遠程。

3.啟動netty服務，建立長連接。

4.連接到注冊中心zk上。

5.然后監控zk上的消費服務。

 

五、服務消費者消費一個服務的詳細過程

 

 

首先ReferenceConfig類的init方法調用Protocol的refer方法生成Invoker實例。接下來把Invoker轉為客戶端需要的接口。

 

六、下面來看本地暴露於遠程暴露的區別：

本地暴露是暴露在本機JVM中,調用本地服務不需要網絡通信.

遠程暴露是將ip,端口等信息暴露給遠程客戶端,調用遠程服務時需要網絡通信.

 

七、什么情況下適用dubbo協議，什么時候適用rmi協議？

Dubbo支持dubbo、rmi、hessian、http、webservice、thrift、redis等多種協議，但是dubbo協議是官網推薦使用的，dubbo 缺省協議是dubbo協議，采用單一長連接和 NIO 異步通訊，適合於小數據量大並發的服務調用，以及服務消費者機器數遠大於服務提供者機器數的情況。反之，Dubbo 缺省協議不適合傳送大數據量的服務，比如傳文件，傳視頻等，除非請求量很低。RMI協議采用阻塞式(同步)短連接和 JDK 標准序列化方式。適用范圍：傳入傳出參數數據包大小混合，消費者與提供者個數差不多，可傳文件。后面會對其他幾種協議詳細介紹，這里就不贅述了。

 

八、Dubbo主要的配置項有哪些，作用是什么？

provider配置

<!-- 提供方應用信息，用於計算依賴關系 -->
<dubbo:application name="hello-world-app" />

<!-- 使用multicast廣播注冊中心暴露服務地址 -->
<dubbo:registry address="multicast://224.5.6.7:1234" />

<!-- 用dubbo協議在20880端口暴露服務 -->
<dubbo:protocol name="dubbo" port="20880" />

<!-- 聲明需要暴露的服務接口 -->
<dubbo:service interface="com.alibaba.dubbo.demo.DemoService" ref="demoService" />

<!-- 和本地bean一樣實現服務 -->
<bean id="demoService" class="com.alibaba.dubbo.demo.provider.DemoServiceImpl" />

consumer配置

<!-- 消費方應用名，用於計算依賴關系，不是匹配條件，不要與提供方一樣 -->
<dubbo:application name="consumer-of-helloworld-app" />

<!-- 使用multicast廣播注冊中心暴露發現服務地址 -->
<dubbo:registry address="multicast://224.5.6.7:1234" />

<!-- 生成遠程服務代理，可以和本地bean一樣使用demoService -->
<dubbo:reference id="demoService" interface="com.alibaba.dubbo.demo.DemoService" />

九、Dubbo有幾種容錯機制

什么是容錯機制？容錯機制指的是某中系統控制在一定范圍的一種允許或包容犯錯情況的發生，舉個簡單的例子，我們在電腦上運行一個程序，有時候會出現無響應的情況，然后系統回彈出一個提示框讓我們選擇，是立即結束還是繼續等待，然后根據我們的選擇執行對應的操作，這就是“容錯”。

   在分布式架構下，網絡，硬件，應用都可以發生故障，由於各個服務之間可能存在依賴關系，如果一條鏈路中的某一個節點出現故障，將會導致雪崩效應。為了減少某一個節點故障的影響范圍，所以我們才需要去構建容錯服務，來優雅的處理這種中斷的響應結果

1.failsafe 失敗安全，可以認為是把錯誤吞掉（記錄日志）

2.failover(默認)  重試其他服務器；retries(2)重試的次數，默認為2次

3.failback   失敗后自動恢復

4.forking forks. 設置並行數

5.Broadcast 廣播，任意一台報錯，則執行的方法報錯，通過cluster方式，配置制定的容錯方案

 

十、dubbo的服務降級

降級的目的是為了保證核心服務可用

降級可以有幾個層面的分類：自動降級，人工降級；按照功能可以分為：讀服務降級和寫服務降級；

1.對一些非核心服務進行人工降級，在大促之前通過降級開關關閉那些推薦內容，評價等對主流程序沒有影響的功能

2.故障降級，比如調用的遠程服務掛了，網絡故障，或者RPC服務返回異常。那么可以直接降級，降級的方案比如設置默認值，采用兜底數據（系統推薦的行為廣告掛了，可以提前准備靜態頁面做返回）等等

3.限流降級，在秒殺這種流量比較集中並且流量特別大的情況下，因為突發訪問量特別大可能導致系統支撐不了。這個時候可以采用限流來限制訪問量。當達到閾值時，后續的請求被降級，比如進入排隊頁面，比如跳轉到錯誤頁面（活動火爆，請稍后重試）

 

Dubbo的降級方式：Mock

實現步驟

1.在client端創建一個testmock類，實現對應的IGphello的接口（需要對哪個接口進行mock，就實現哪個）名稱必須以mock結尾

2.在client端的xml配置文件中，添加如下配置，增加一個mock屬性指向創建的testmock

3.模擬錯誤（設置timeout）模擬超時異常，運行測試代碼即可訪問到testmock這個類，當服務端故障解除以后，調用過程將恢復正常

 

十一、dubbo的優先級配置

配置優先級別

1.以timeout為例，顯示了配置的查找順序，其他retries，loadbalance等類似。

（1）方法級優先，接口級次之，全局配置在次之

（2）如果級別一樣，則消費方優先，提供方次之

（3）其中，服務提供方配置，通過URL經由注冊中心傳遞給消費方

2.建議由服務提供方設置超時，因為一個方法需要執行多長時間，服務提供方更清楚，如果一個消費方同時引用多個服務，就不需要關心每個服務的超時設置。

dubbo高可用之zookeeper宕機、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

廣播調用所有提供者，逐個調用，任意一台報錯則報錯 [2]。通常用於通知所有提供者更新緩存或日志等本地資源信息。

集群模式配置

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

<dubbo:service cluster="failsafe" />

或

<dubbo:reference cluster="failsafe" />