面試阿里掛在Dubbo上，夙夜匪懈整理了這份Dubbo面試題，致本身！

前言：

月初，以前的一個同事去面了阿里，結果掛在了Dubbo；回來以後就和我分享了一些阿里的面試真題；因而我趁機把他整理的這個Dubbo面試專題也要了過來；加下答案，一塊兒分享給你們！

Dubbo面試專題

1. Dubbo與DubboX區別

Dubbox 和Dubbo本質上沒有區別，名字的含義擴展了Dubbo而已，如下擴展出來的功能，也是選擇Dubbox很重要的考察點。

• 支持REST風格遠程調用（HTTP + JSON/XML)；
• 支持基於Kryo和FST的Java高效序列化實現；
• 支持基於Jackson的JSON序列化；
• 支持基於嵌入式Tomcat的HTTP remoting體系；
• 升級Spring至3.x；
• 升級ZooKeeper客戶端；
• 支持徹底基於Java代碼的Dubbo配置；

2. Dubbo中Zookeeper作註冊中心，若是註冊中心集羣都掛掉，發佈者和訂閱者之間還能通訊麼？

能夠的，啓動Dubbo時，消費者會從zk拉取註冊的生產者的地址接口等數據，緩存在本地。每次調用時，按照本地存儲的地址進行調用

• 註冊中心對等集羣，任意一臺宕掉後，會自動切換到另外一臺
• 註冊中心所有宕掉，服務提供者和消費者仍能夠經過本地緩存通信
• 服務提供者無狀態，任一臺 宕機後，不影響使用
• 服務提供者所有宕機，服務消費者會沒法使用，並沒有限次重連等待服務者恢復

3. Dubbo中有哪些角色？

①. Registry

註冊中心. 是用於發佈和訂閱服務的一個平臺.用於替代SOA結構體系框架中的ESB服務總線的。

• 發佈：開發服務端代碼完畢後, 將服務信息發佈出去. 實現一個服務的公開.
• 訂閱：客戶端程序,從註冊中心下載服務內容 這個過程是訂閱.

訂閱服務的時候, 會將發佈的服務全部信息,一次性下載到客戶端.

客戶端也能夠自定義, 修改部分服務配置信息. 如: 超時的時長, 調用的重試次數等.

②. Consumer

服務的消費者, 就是服務的客戶端.

消費者必須使用Dubbo技術開發部分代碼. 基本上都是配置文件定義.

③. Provider

服務的提供者, 就是服務端.

服務端必須使用Dubbo技術開發部分代碼. 以配置文件爲主.

④. Container

容器. Dubbo技術的服務端(Provider), 在啓動執行的時候, 必須依賴容器才能正常啓動.

默認依賴的就是spring容器. 且Dubbo技術不能脫離 Spring框架.

在2.5.3版本的Dubbo中, 默認依賴的是Spring2.5版本技術. 能夠選用Spring4.5如下版本.

在2.5.7版本的Dubbo中, 默認依賴的是Spring4.3.10版本技術. 能夠選擇任意的Spring版本.

⑤. Monitor

監控中心. 是Dubbo提供的一個jar工程。

主要功能是監控服務端(Provider)和消費端(Consumer)的使用數據的. 如: 服務端是什麼,有多少接口,多少方法, 調用次數, 壓力信息等. 客戶端有多少, 調用過哪些服務端, 調用了多少次等。

4. Dubbo在安全機制方面是如何解決的

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

5. Dubbo執行流程？

1. Start: 啓動Spring容器時,自動啓動Dubbo的Provider
2. Register: Dubbo的Provider在啓動後自動會去註冊中心註冊內容.註冊的內容包括:

2.1 Provider的 IP
2.2 Provider 的端口.
2.3 Provider 對外提供的接口列表.哪些方法.哪些接口類
2.4 Dubbo 的版本.
2.5 訪問Provider的協議.

1. Subscribe: 訂閱.當Consumer啓動時,自動去Registry獲取到所已註冊的服務的信息.
2. Notify: 通知.當Provider的信息發生變化時, 自動由Registry向Consumer推送通知.
3. Invoke: 調用. Consumer 調用Provider中方法

5.1 同步請求.消耗必定性能.可是必須是同步請求,由於須要接收調用方法後的結果.

1. Count:次數. 每隔2分鐘,Provoider和Consumer自動向Monitor發送訪問次數.Monitor進行統計.

6. Dubbo支持的協議有哪些？

①. Dubbo協議(官方推薦協議)

• 優勢：採用NIO複用單一長鏈接，並使用線程池併發處理請求，減小握手和加大併發效率，性能較好（推薦使用）
• 缺點：大文件上傳時,可能出現問題(不使用Dubbo文件上傳)

②. RMI(Remote Method Invocation)協議

• 優勢:JDK自帶的能力。可與原生RMI互操做，基於TCP協議
• 缺點:偶爾鏈接失敗.

③. Hessian協議

• 優勢:可與原生Hessian互操做，基於HTTP協議
• 缺點:需Hessian.jar支持，Http短鏈接的開銷大

7. Dubbo支持的註冊中心有哪些？

①. Zookeeper(官方推薦)

• 優勢:支持分佈式.不少周邊產品.
• 缺點: 受限於Zookeeper軟件的穩定性.Zookeeper專門分佈式輔助軟件,穩定較優

②. Multicast

• 優勢:去中心化,不須要單獨安裝軟件.
• 缺點:Provider和Consumer和Registry不能跨機房(路由)

③. Redis

• 優勢:支持集羣,性能高
• 缺點:要求服務器時間同步.不然可能出現集羣失敗問題.

④. Simple

• 優勢: 標準RPC服務.沒有兼容問題
• 缺點: 不支持集羣.

8. Dubbo服務負載均衡策略？

①. l Random LoadBalance

隨機，按權重設置隨機機率。在一個截面上碰撞的機率高，但調用量越大分佈越均勻，並且按機率使用權重後也比較均勻，有利於動態調整提供者權重。(權重能夠在Dubbo管控臺配置)

②. l RoundRobin LoadBalance

輪循，按公約後的權重設置輪循比率。存在慢的提供者累積請求問題，好比：第二臺機器很慢，但沒掛，當請求調到第二臺時就卡在那，長此以往，全部請求都卡在調到第二臺上。

③. l LeastActive LoadBalance

最少活躍調用數，相同活躍數的隨機，活躍數指調用先後計數差。使慢的提供者收到更少請求，由於越慢的提供者的調用先後計數差會越大。

④. l ConsistentHash LoadBalance

一致性Hash，相同參數的請求老是發到同一提供者。當某一臺提供者掛時，本來發往該提供者的請求，基於虛擬節點，平攤到其它提供者，不會引發劇烈變更。缺省只對第一個參數Hash，若是要修改，請配置

9. Dubbo核心的配置有哪些？Dubbo推薦用什麼協議？

核心配置有 dubbo:service/ dubbo:reference/ dubbo:protocol/ dubbo:registry/ dubbo:application/ dubbo:provider/ dubbo:consumer/ dubbo:method/

默認使用Dubbo協議。

10. dubbo鏈接註冊中心和直連的區別

在開發及測試環境下，常常須要繞過註冊中心，只測試指定服務提供者，這時候可能須要點對點直連， 點對點直聯方式，將以服務接口爲單位，忽略註冊中心的提供者列表，服務註冊中心，動態的註冊和發現服務，使服務的位置透明，並經過在消費方獲取服務提供方地址列表，實現軟負載均衡和Failover， 註冊中心返回服務提供者地址列表給消費者，若是有變動，註冊中心將基於長鏈接推送變動數據給消費者。 服務消費者，從提供者地址列表中，基於軟負載均衡算法，選一臺提供者進行調用，若是調用失敗，再選另外一臺調用。註冊中心負責服務地址的註冊與查找，至關於目錄服務，服務提供者和消費者只在啓動時與註冊中心交互，註冊中心不轉發請求，服務消費者向註冊中心獲取服務提供者地址列表，並根據負載算法直接調用提供者，註冊中心，服務提供者，服務消費者三者之間均爲長鏈接，監控中心除外，註冊中心經過長鏈接感知服務提供者的存在，服務提供者宕機，註冊中心將當即推送事件通知消費者註冊中心和監控中心所有宕機，不影響已運行的提供者和消費者，消費者在本地緩存了提供者列表註冊中心和監控中心都是可選的，服務消費者能夠直連服務提供者。

11. Dubbo通訊協議Dubbo協議爲何不能傳大包

因Dubbo協議採用單一長鏈接，若是每次請求的數據包大小爲500KByte，假設網絡爲千兆網卡(1024Mbit=128MByte)，每條鏈接最大7MByte(不一樣的環境可能不同，供參考)，

• 單個服務提供者的TPS(每秒處理事務數)最大爲：128MByte / 500KByte = 262。
• 單個消費者調用單個服務提供者的TPS(每秒處理事務數)最大爲：7MByte / 500KByte = 14。

若是能接受，能夠考慮使用，不然網絡將成爲瓶頸。

12. Dubbo通訊協議Dubbo協議爲何要消費者比提供者個數多

因Dubbo協議採用單一長鏈接，假設網絡爲千兆網卡(1024Mbit=128MByte)，根據測試經驗數據每條鏈接最多隻能壓滿7MByte(不一樣的環境可能不同，供參考)，理論上1個服務提供者須要20個服務消費者才能壓滿網卡。

13. Dubbo通訊協議Dubbo協議爲何採用異步單一長鏈接

由於服務的現狀大都是服務提供者少，一般只有幾臺機器，而服務的消費者多，可能整個網站都在訪問該服務，好比Morgan的提供者只有6臺提供者，卻有上百臺消費者，天天有1.5億次調用，若是採用常規的hessian服務，服務提供者很容易就被壓跨，經過單一鏈接，保證單一消費者不會壓死提供者，長鏈接，減小鏈接握手驗證等，並使用異步IO，複用線程池，防止C10K問題。

14. Dubbo通訊協議Dubbo協議適用範圍和適用場景

①. Dubbo協議

• 適用範圍：傳入傳出參數數據包較小（建議小於100K），消費者比提供者個數多，單一消費者沒法壓滿提供者，儘可能不要用dubbo協議傳輸大文件或超大字符串。
• 適用場景：常規遠程服務方法調用

dubbo協議補充：

• 鏈接個數：單鏈接
• 鏈接方式：長鏈接
• 傳輸協議：TCP
• 傳輸方式：NIO異步傳輸
• 序列化：Hessian二進制序列化

②. RMI協議

RMI協議採用JDK標準的Java.rmi.*實現，採用阻塞式短鏈接和JDK標準序列化方式，Java標準的遠程調用協議。

• 鏈接個數：多鏈接
• 鏈接方式：短鏈接
• 傳輸協議：TCP
• 傳輸方式：同步傳輸
• 序列化：Java標準二進制序列化
• 適用範圍：傳入傳出參數數據包大小混合，消費者與提供者個數差很少，可傳文件。
• 適用場景：常規遠程服務方法調用，與原生RMI服務互操做

③. Hessian協議

Hessian協議用於集成Hessian的服務，Hessian底層採用Http通信，採用Servlet暴露服務，Dubbo缺省內嵌Jetty做爲服務器實現；基於Hessian的遠程調用協議。

• 鏈接個數：多鏈接
• 鏈接方式：短鏈接
• 傳輸協議：HTTP
• 傳輸方式：同步傳輸
• 序列化：Hessian二進制序列化
• 適用範圍：傳入傳出參數數據包較大，提供者比消費者個數多，提供者壓力較大，可傳文件。
• 適用場景：頁面傳輸，文件傳輸，或與原生hessian服務互操做

④. http

採用Spring的HttpInvoker實現；基於Http表單的遠程調用協議。

• 鏈接個數：多鏈接
• 鏈接方式：短鏈接
• 傳輸協議：HTTP
• 傳輸方式：同步傳輸
• 序列化：表單序列化（JSON）
• 適用範圍：傳入傳出參數數據包大小混合，提供者比消費者個數多，可用瀏覽器查看，可用表單或URL傳入參數，暫不支持傳文件。
• 適用場景：需同時給應用程序和瀏覽器JS使用的服務。

⑤. Webservice

基於CXF的Frontend-simple和Transports-http實現；基於WebService的遠程調用協議。

• 鏈接個數：多鏈接
• 鏈接方式：短鏈接
• 傳輸協議：HTTP
• 傳輸方式：同步傳輸
• 序列化：SOAP文本序列化
• 適用場景：系統集成，跨語言調用。

⑥. Thrif

Thrift是Facebook捐給Apache的一個RPC框架，當前 dubbo 支持的 thrift 協議是對 thrift 原生協議的擴展，在原生協議的基礎上添加了一些額外的頭信息，好比service name，magic number等

寫在最後

想進BAT阿里一線互聯網公司，只靠Dubbo不可行呀，因而又厚着臉皮問朋友把他的面試資料所有要了過來，算是比較完整的一份面試題了；包含了Kafka、Mysql、Tomcat、Docker、Spring、MyBatis、Nginx、Netty、Dubbo、Redis、Netty、Spring cloud、分佈式、高併發、性能調優、微服務等架構技術。

須要的朋友點擊下方 傳送門；便可免費領取整理整理的Java面試題

傳送門

如下是部分面試題截圖