作者：Dean Wang

連結：https://deanwang1943.github.io/bugs/2018/10/05/面試/餓了麼/dubbo%20面試題/

 

dubbo是什麼

 

dubbo是一個分散式框架，遠端服務呼叫的分散式框架，其核心部分包含： 叢集容錯：提供基於介面方法的透明遠端過程呼叫，包括多協議支援，以及軟負載均衡，失敗容錯，地址路由，動態配置等叢集支援。 遠端通訊： 提供對多種基於長連線的NIO框架抽象封裝，包括多種執行緒模型，序列化，以及“請求-響應”樣式的資訊交換方式。 自動發現：基於註冊中心目錄服務，使服務消費方能動態的查詢服務提供方，使地址透明，使服務提供方可以平滑增加或減少機器。

dubbo能做什麼

透明化的遠端方法呼叫，就像呼叫本地方法一樣呼叫遠端方法，只需簡單配置，沒有任何API侵入。 軟負載均衡及容錯機制，可在內網替代F5等硬體負載均衡器，降低成本，減少單點。 服務自動註冊與發現，不再需要寫死服務提供方地址，註冊中心基於介面名查詢服務提供者的IP地址，並且能夠平滑新增或刪除服務提供者。

1、預設使用的是什麼通訊框架，還有別的選擇嗎?

答：預設也推薦使用 netty 框架，還有 mina。

 

2、服務呼叫是阻塞的嗎？

答：預設是阻塞的，可以非同步呼叫，沒有傳回值的可以這麼做。

 

3、一般使用什麼註冊中心？還有別的選擇嗎？

答：推薦使用 zookeeper 註冊中心，還有 Multicast註冊中心, Redis註冊中心, Simple註冊中心.

ZooKeeper的節點是透過像樹一樣的結構來進行維護的，並且每一個節點透過路徑來標示以及訪問。除此之外，每一個節點還擁有自身的一些資訊，包括：資料、資料長度、建立時間、修改時間等等。

 

4、預設使用什麼序列化框架，你知道的還有哪些？

答：預設使用 Hessian 序列化，還有 Duddo、FastJson、Java 自帶序列化。 hessian是一個採用二進位制格式傳輸的服務框架，相對傳統soap web service，更輕量，更快速。

Hessian原理與協議簡析：

http的協議約定了資料傳輸的方式，hessian也無法改變太多：

1) hessian中client與server的互動，基於http-post方式。

2) hessian將輔助資訊，封裝在http essay-header中，比如“授權token”等，我們可以基於http-essay-header來封裝關於“安全校驗”“meta資料”等。hessian提供了簡單的”校驗”機制。

3) 對於hessian的互動核心資料，比如“呼叫的方法”和引數串列資訊，將透過post請求的body體直接傳送，格式為位元組流。

4) 對於hessian的server端響應資料，將在response中透過位元組流的方式直接輸出。

hessian的協議本身並不複雜，在此不再贅言；所謂協議(protocol)就是約束資料的格式，client按照協議將請求資訊序列化成位元組序列傳送給server端，server端根據協議，將資料反序列化成“物件”，然後執行指定的方法，並將方法的傳回值再次按照協議序列化成位元組流，響應給client，client按照協議將位元組流反序列話成”物件”。

 

5、服務提供者能實現失效踢出是什麼原理？

答：服務失效踢出基於 zookeeper 的臨時節點原理。

 

6、服務上線怎麼不影響舊版本？

答：採用多版本開發，不影響舊版本。在配置中新增version來作為版本區分

 

7、如何解決服務呼叫鏈過長的問題？

答：可以結合 zipkin 實現分散式服務追蹤。

 

8、說說核心的配置有哪些？

核心配置有：

1) dubbo:service/

2) dubbo:reference/

3) dubbo:protocol/

4) dubbo:registry/

5) dubbo:application/

6) dubbo:provider/

7) dubbo:consumer/

8) dubbo:method/

 

9、dubbo 推薦用什麼協議？

答：預設使用 dubbo 協議。

 

10、同一個服務多個註冊的情況下可以直連某一個服務嗎？

答：可以直連，修改配置即可，也可以透過 telnet 直接某個服務。

 

11、dubbo 在安全機制方面如何解決的？

dubbo 透過 token 令牌防止使用者繞過註冊中心直連，然後在註冊中心管理授權，dubbo 提供了黑白名單，控制服務所允許的呼叫方。

 

12、叢集容錯怎麼做？

答：讀操作建議使用 Failover 失敗自動切換，預設重試兩次其他伺服器。寫操作建議使用 Failfast 快速失敗，發一次呼叫失敗就立即報錯。

 

13、在使用過程中都遇到了些什麼問題？ 如何解決的？

1) 同時配置了 XML 和 properties 檔案，則 properties 中的配置無效

只有 XML 沒有配置時，properties 才生效。

2) dubbo 預設會在啟動時檢查依賴是否可用，不可用就丟擲異常，阻止 spring 初始化完成，check 屬性預設為 true。

測試時有些服務不關心或者出現了迴圈依賴，將 check 設定為 false

3) 為了方便開發測試，線下有一個所有服務可用的註冊中心，這時，如果有一個正在開發中的服務提供者註冊，可能會影響消費者不能正常執行。

解決：讓服務提供者開發方，只訂閱服務，而不註冊正在開發的服務，透過直連測試正在開發的服務。設定 dubbo:registry 標簽的 register 屬性為 false。

4) spring 2.x 初始化死鎖問題。

在 spring 解析到 dubbo:service 時，就已經向外暴露了服務，而 spring 還在接著初始化其他 bean，如果這時有請求進來，並且服務的實現類裡有呼叫 applicationContext.getBean() 的用法。getBean 執行緒和 spring 初始化執行緒的鎖的順序不一樣，導致了執行緒死鎖，不能提供服務，啟動不了。

解決：不要在服務的實現類中使用 applicationContext.getBean(); 如果不想依賴配置順序，可以將 dubbo:provider 的 deplay 屬性設定為 – 1，使 dubbo 在容器初始化完成後再暴露服務。

5) 服務註冊不上

檢查 dubbo 的 jar 包有沒有在 classpath 中，以及有沒有重覆的 jar 包

檢查暴露服務的 spring 配置有沒有載入

在服務提供者機器上測試與註冊中心的網路是否通

6) 出現 RpcException: No provider available for remote service 異常

表示沒有可用的服務提供者，

a. 檢查連線的註冊中心是否正確

b. 到註冊中心檢視相應的服務提供者是否存在

c. 檢查服務提供者是否正常執行

7) 出現” 訊息傳送失敗” 異常

通常是介面方法的傳入傳出引數未實現 Serializable 介面。

 

14、dubbo 和 dubbox 之間的區別？

答：dubbox 是噹噹網基於 dubbo 上做了一些擴充套件，如加了服務可 restful 呼叫，更新了開源元件等。

 

15、你還瞭解別的分散式框架嗎？

答：別的還有 spring 的 spring cloud，facebook 的 thrift，twitter 的 finagle 等。

 

16、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 協議

 

17、Dubbo 叢集的負載均衡有哪些策略

Dubbo 提供了常見的叢集策略實現，並預擴充套件點予以自行實現。

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

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

LeastActive LoadBalance: 最少活躍呼叫策略，解決慢提供者接收更少的請求； ConstantHash LoadBalance: 一致性 Hash 策略，使相同引數請求總是發到同一提供者，一臺機器宕機，可以基於虛擬節點，分攤至其他提供者，避免引起提供者的劇烈變動；

 

18、服務呼叫超時問題怎麼解決

dubbo在呼叫服務不成功時，預設是會重試兩次的。這樣在服務端的處理時間超過了設定的超時時間時，就會有重覆請求，比如在發郵件時，可能就會發出多份重覆郵件，執行註冊請求時，就會插入多條重覆的註冊資料，那麼怎麼解決超時問題呢？如下

對於核心的服務中心，去除dubbo超時重試機制，並重新評估設定超時時間。 業務處理程式碼必須放在服務端，客戶端只做引數驗證和服務呼叫，不涉及業務流程處理 全域性配置實體

<dubbo:provider delay="-1" timeout="6000" retries="0"/>

當然Dubbo的重試機制其實是非常好的QOS保證，它的路由機制，是會幫你把超時的請求路由到其他機器上，而不是本機嘗試，所以 dubbo的重試機器也能一定程度的保證服務的質量。但是請一定要綜合線上的訪問情況，給出綜合的評估。