Dubbo面試常見問題

時間 2019-11-10

原文原文鏈接

1、dubbo是什麼？html

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

2、dubbo的核心服務是什麼？redis

Dubbo的做用以及介紹數據庫

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

3、看一下dubbo架構圖api

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

若是你仔細觀察dubbo的啓動日誌你會發現，dubbo的provider啓動主要是如下幾個過程安全

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

2.而後再把服務暴露到遠程。網絡

3.啓動netty服務，創建長鏈接。

4.鏈接到註冊中心zk上。

5.而後監控zk上的消費服務。

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

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

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

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

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

7、什麼狀況下適用dubbo協議，何時適用rmi協議？

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

8、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" />

9、Dubbo有幾種容錯機制

什麼是容錯機制？容錯機制指的是某中系統控制在必定範圍的一種容許或包容犯錯狀況的發生，舉個簡單的例子，咱們在電腦上運行一個程序，有時候會出現無響應的狀況，而後系統回彈出一個提示框讓咱們選擇，是當即結束仍是繼續等待，而後根據咱們的選擇執行對應的操做，這就是「容錯」。

在分佈式架構下，網絡，硬件，應用均可以發生故障，因爲各個服務之間可能存在依賴關係，若是一條鏈路中的某一個節點出現故障，將會致使雪崩效應。爲了減小某一個節點故障的影響範圍，因此咱們才須要去構建容錯服務，來優雅的處理這種中斷的響應結果

1.failsafe 失敗安全，能夠認爲是把錯誤吞掉（記錄日誌）

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

3.failback 失敗後自動恢復

4.forking forks. 設置並行數

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

10、dubbo的服務降級

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

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

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

2.故障降級，好比調用的遠程服務掛了，網絡故障，或者RPC服務返回異常。那麼能夠直接降級，降級的方案好比設置默認值，採用兜底數據（系統推薦的行爲廣告掛了，能夠提早準備靜態頁面作返回）等等

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

Dubbo的降級方式：Mock

實現步驟

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

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

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

11、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