史上最強Dubbo面試26題和答案：核心組件+服務治理+架構設計等

1.Dubbo是什麼？

Dubbo 是一個分佈式、高性能、透明化的 RPC 服務框架，提供服務自動註冊、自動發現等高效服務治理方案， 能夠和 Spring框架無縫集成。

2.Dubbo的由來？

互聯網的快速發展，Web應用程序的規模不斷擴大，通常會經歷以下四個發展階段。

單一應用架構：當網站流量很小時，只需一個應用，將全部功能都部署在一塊兒便可。

垂直應用架構：當訪問量逐漸增大，單一應用按照有業務線拆成多個應用，以提高效率。

分佈式服務架構

當垂直應用愈來愈多，應用之間交互不可避免，將核心業務抽取出來，做爲獨立的服務，逐漸造成穩定的服務中心，使前端應用能更快速的響應多變的市場需求。

此時，用於提升業務複用及整合的分佈式服務框架(RPC)是關鍵。

流動計算架構

當服務愈來愈多，容量的評估，小服務資源的浪費等問題逐漸顯現，此時需增長一個調度中心基於訪問壓力實時管理集羣容量，提升集羣利用率。

此時，用於提升機器利用率的資源調度和治理中心(SOA)是關鍵。

3.Dubbo的主要應用場景？

透明化的遠程方法調用，就像調用本地方法同樣調用遠程方法，只需簡單配置，沒有任何API侵入。

軟負載均衡及容錯機制，可在內網替代F5等硬件負載均衡器，下降成本，減小單點。

服務自動註冊與發現，再也不須要寫死服務提供方地址，註冊中心基於接口名查詢服務提供者的IP地址，而且可以平滑添加或刪除服務提供者。

4.Dubbo的核心功能？

主要就是以下3個核心功能：

Remoting：網絡通訊框架，提供對多種NIO框架抽象封裝，包括「同步轉異步」和「請求-響應」模式的信息交換方式。

Cluster：服務框架，提供基於接口方法的透明遠程過程調用，包括多協議支持，以及軟負載均衡，失敗容錯，地址路由，動態配置等集羣支持。

Registry：服務註冊，基於註冊中心目錄服務，使服務消費方能動態的查找服務提供方，使地址透明，使服務提供方能夠平滑增長或減小機器。

5.Dubbo的核心組件？

6.Dubbo服務註冊與發現的流程？

流程說明：

Provider(提供者)綁定指定端口並啓動服務

指供者鏈接註冊中心，併發本機IP、端口、應用信息和提供服務信息發送至註冊中心存儲

Consumer(消費者），鏈接註冊中心 ，併發送應用信息、所求服務信息至註冊中心

註冊中心根據 消費 者所求服務信息匹配對應的提供者列表發送至Consumer 應用緩存。

Consumer 在發起遠程調用時基於緩存的消費者列表擇其一發起調用。

Provider 狀態變動會實時通知註冊中心、在由註冊中心實時推送至Consumer

設計的緣由：

Consumer 與Provider 解偶，雙方均可以橫向增減節點數。

註冊中心對自己可作對等集羣，可動態增減節點，而且任意一臺宕掉後，將自動切換到另外一臺

去中心化，雙方不直接依懶註冊中心，即便註冊中心所有宕機短期內也不會影響服務的調用

服務提供者無狀態，任意一臺宕掉後，不影響使用

7.Dubbo的架構設計？

Dubbo框架設計一共劃分了10個層：

服務接口層（Service）：該層是與實際業務邏輯相關的，根據服務提供方和服務消費方的業務設計對應的接口和實現。

配置層（Config）：對外配置接口，以ServiceConfig和ReferenceConfig爲中心。

服務代理層（Proxy）：服務接口透明代理，生成服務的客戶端Stub和服務器端Skeleton。

服務註冊層（Registry）：封裝服務地址的註冊與發現，以服務URL爲中心。

集羣層（Cluster）：封裝多個提供者的路由及負載均衡，並橋接註冊中心，以Invoker爲中心。

監控層（Monitor）：RPC調用次數和調用時間監控。

遠程調用層（Protocol）：封將RPC調用，以Invocation和Result爲中心，擴展接口爲Protocol、Invoker和Exporter。

信息交換層（Exchange）：封裝請求響應模式，同步轉異步，以Request和Response爲中心。

網絡傳輸層（Transport）：抽象mina和netty爲統一接口，以Message爲中心。

8.Dubbo的服務調用流程？

9.Dubbo支持哪些協議，每種協議的應用場景，優缺點？

dubbo：單一長鏈接和NIO異步通信，適合大併發小數據量的服務調用，以及消費者遠大於提供者。傳輸協議TCP，異步，Hessian序列化；

rmi：採用JDK標準的rmi協議實現，傳輸參數和返回參數對象須要實現Serializable接口，使用java標準序列化機制，使用阻塞式短鏈接，傳輸數據包大小混合，消費者和提供者個數差很少，可傳文件，傳輸協議TCP。 多個短鏈接，TCP協議傳輸，同步傳輸，適用常規的遠程服務調用和rmi互操做。在依賴低版本的Common-Collections包，java序列化存在安全漏洞；

webservice：基於WebService的遠程調用協議，集成CXF實現，提供和原生WebService的互操做。多個短鏈接，基於HTTP傳輸，同步傳輸，適用系統集成和跨語言調用；

http：基於Http表單提交的遠程調用協議，使用Spring的HttpInvoke實現。多個短鏈接，傳輸協議HTTP，傳入參數大小混合，提供者個數多於消費者，須要給應用程序和瀏覽器JS調用；

hessian：集成Hessian服務，基於HTTP通信，採用Servlet暴露服務，Dubbo內嵌Jetty做爲服務器時默認實現，提供與Hession服務互操做。多個短鏈接，同步HTTP傳輸，Hessian序列化，傳入參數較大，提供者大於消費者，提供者壓力較大，可傳文件；

memcache：基於memcached實現的RPC協議

redis：基於redis實現的RPC協議

10.dubbo推薦用什麼協議？

默認使用dubbo協議

11.Dubbo有些哪些註冊中心？

Multicast註冊中心：Multicast註冊中心不須要任何中心節點，只要廣播地址，就能進行服務註冊和發現。基於網絡中組播傳輸實現；

Zookeeper註冊中心：基於分佈式協調系統Zookeeper實現，採用Zookeeper的watch機制實現數據變動；

redis註冊中心：基於redis實現，採用key/Map存儲，住key存儲服務名和類型，Map中key存儲服務URL，value服務過時時間。基於redis的發佈/訂閱模式通知數據變動；

Simple註冊中心

12.Dubbo默認採用註冊中心？

採用Zookeeper

13.爲何須要服務治理？

過多的服務URL配置困難

負載均衡分配節點壓力過大的狀況下也須要部署集羣

服務依賴混亂，啓動順序不清晰

過多服務致使性能指標分析難度較大，須要監控

15.Dubbo的註冊中心集羣掛掉，發佈者和訂閱者之間還能通訊麼？

能夠的，啓動dubbo時，消費者會從zookeeper拉取註冊的生產者的地址接口等數據，緩存在本地。

每次調用時，按照本地存儲的地址進行調用。

15.Dubbo與Spring的關係？

Dubbo採用全Spring配置方式，透明化接入應用，對應用沒有任何API侵入，只需用Spring加載Dubbo的配置便可，Dubbo基於Spring的Schema擴展進行加載。

16.Dubbo使用的是什麼通訊框架?

默認使用NIO Netty框架

17.Dubbo集羣提供了哪些負載均衡策略？

Random LoadBalance:隨機選取提供者策略，有利於動態調整提供者權重。截面碰撞率高，調用次數越多，分佈越均勻；

RoundRobin LoadBalance:輪循選取提供者策略，平均分佈，可是存在請求累積的問題；

LeastActive LoadBalance:最少活躍調用策略，解決慢提供者接收更少的請求；

ConstantHash LoadBalance:一致性Hash策略，使相同參數請求老是發到同一提供者，一臺機器宕機，能夠基於虛擬節點，分攤至其餘提供者，避免引發提供者的劇烈變更；

缺省時爲Random隨機調用

18.Dubbo的集羣容錯方案有哪些？

Failover Cluster

失敗自動切換，當出現失敗，重試其它服務器。一般用於讀操做，但重試會帶來更長延遲。

Failfast Cluster

快速失敗，只發起一次調用，失敗當即報錯。一般用於非冪等性的寫操做，好比新增記錄。

Failsafe Cluster

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

Failback Cluster

失敗自動恢復，後臺記錄失敗請求，定時重發。一般用於消息通知操做。

Forking Cluster

並行調用多個服務器，只要一個成功即返回。一般用於實時性要求較高的讀操做，但須要浪費更多服務資源。可經過 forks="2" 來設置最大並行數。

Broadcast Cluster

廣播調用全部提供者，逐個調用，任意一臺報錯則報錯 。一般用於通知全部提供者更新緩存或日誌等本地資源信息。

19.Dubbo的默認集羣容錯方案？

Failover Cluster

20.Dubbo支持哪些序列化方式？

默認使用Hessian序列化，還有Duddo、FastJson、Java自帶序列化。

21.Dubbo超時時間怎樣設置？

Dubbo超時時間設置有兩種方式：

服務提供者端設置超時時間，在Dubbo的用戶文檔中，推薦若是能在服務端多配置就儘可能多配置，由於服務提供者比消費者更清楚本身提供的服務特性。

服務消費者端設置超時時間，若是在消費者端設置了超時時間，以消費者端爲主，即優先級更高。由於服務調用方設置超時時間控制性更靈活。若是消費方超時，服務端線程不會定製，會產生警告。

22.服務調用超時問題怎麼解決？

dubbo在調用服務不成功時，默認是會重試兩次的。

23.Dubbo在安全機制方面是如何解決？

Dubbo經過Token令牌防止用戶繞過註冊中心直連，而後在註冊中心上管理受權。Dubbo還提供服務黑白名單，來控制服務所容許的調用方。

24.Dubbo 和 Dubbox 之間的區別？

dubbox 基於 dubbo 上作了一些擴展，如加了服務可 restful 調用，更新了開源組件等。

25.Dubbo和Spring Cloud的關係？

Dubbo

是 SOA 時代的產物，它的關注點主要在於服務的調用，流量分發、流量監控和熔斷。而 Spring Cloud

誕生於微服務架構時代，考慮的是微服務治理的方方面面，另外因爲依託了 Spirng、Spirng Boot

的優點之上，兩個框架在開始目標就不一致，Dubbo 定位服務治理、Spirng Cloud 是一個生態。

26.Dubbo和Spring Cloud的區別？

最大的區別：Dubbo底層是使用Netty這樣的NIO框架，是基於TCP協議傳輸的，配合以Hession序列化完成RPC通訊。

而SpringCloud是基於Http協議+Rest接口調用遠程過程的通訊，相對來講，Http請求會有更大的報文，佔的帶寬也會更多。可是REST相比RPC更爲靈活，服務提供方和調用方的依賴只依靠一紙契約，不存在代碼級別的強依賴。

以上就是最強Dubbo面試題答案的詳解。

以爲不錯請點贊支持，歡迎留言或進個人我的羣171662117領取【架構資料專題目合集】、【BATJTMD大廠JAVA面試真題】，本羣專用於學習交流技術、分享面試機會，拒絕廣告，我也會在羣內不按期答題、探討。