dubbo 面試18問 JAVA葵花寶典 今天

 

dubbo 面試18問 

 

dubbo是什麼

dubbo是一個分佈式框架，遠程服務調用的分佈式框架，其核心部分包含： 集羣容錯：提供基於接口方法的透明遠程過程調用，包括多協議支持，以及軟負載均衡，失敗容錯，地址路由，動態配置等集羣支持。 遠程通信： 提供對多種基於長鏈接的NIO框架抽象封裝，包括多種線程模型，序列化，以及「請求-響應」模式的信息交換方式。 自動發現：基於註冊中心目錄服務，使服務消費方能動態的查找服務提供方，使地址透明，使服務提供方能夠平滑增長或減小機器。

dubbo能作什麼

透明化的遠程方法調用，就像調用本地方法同樣調用遠程方法，只需簡單配置，沒有任何API侵入。 軟負載均衡及容錯機制，可在內網替代F5等硬件負載均衡器，下降成本，減小單點。 服務自動註冊與發現，再也不須要寫死服務提供方地址，註冊中心基於接口名查詢服務提供者的IP地址，而且可以平滑添加或刪除服務提供者。

一、默認使用的是什麼通訊框架，還有別的選擇嗎?

答：默認也推薦使用 netty 框架，還有 mina。

二、服務調用是阻塞的嗎？

答：默認是阻塞的，能夠異步調用，沒有返回值的能夠這麼作。

三、通常使用什麼註冊中心？還有別的選擇嗎？

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

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

四、默認使用什麼序列化框架，你知道的還有哪些？

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

Hessian原理與協議簡析：

http的協議約定了數據傳輸的方式，hessian也沒法改變太多：

•  

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

   

•  

  2) hessian將輔助信息，封裝在http header中，好比「受權token」等，咱們能夠基於http-header來封裝關於「安全校驗」「meta數據」等。hessian提供了簡單的」校驗」機制。

   

•  

  3) 對於hessian的交互核心數據，好比「調用的方法」和參數列表信息，將經過post請求的body體直接發送，格式爲字節流。

   

•  

  4) 對於hessian的server端響應數據，將在response中經過字節流的方式直接輸出。

   

hessian的協議自己並不複雜，在此再也不贅言；所謂協議(protocol)就是約束數據的格式，client按照協議將請求信息序列化成字節序列發送給server端，server端根據協議，將數據反序列化成「對象」，而後執行指定的方法，並將方法的返回值再次按照協議序列化成字節流，響應給client，client按照協議將字節流反序列話成」對象」。

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

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

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

答：採用多版本開發，不影響舊版本。在配置中添加version來做爲版本區分

七、如何解決服務調用鏈過長的問題？

答：能夠結合 zipkin 實現分佈式服務追蹤。

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

核心配置有

• dubbo:service/

• dubbo:reference/

• dubbo:protocol/

• dubbo:registry/

• dubbo:application/

• dubbo:provider/

• dubbo:consumer/

• dubbo:method/

九、dubbo 推薦用什麼協議？

答：默認使用 dubbo 協議。

十、同一個服務多個註冊的狀況下能夠直連某一個服務嗎？

答：能夠直連，修改配置便可，也能夠經過 telnet 直接某個服務。

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

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

十二、集羣容錯怎麼作？

答：讀操做建議使用 Failover 失敗自動切換，默認重試兩次其餘服務器。寫操做建議使用 Failfast 快速失敗，發一次調用失敗就當即報錯。

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

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 異常

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

1). 檢查鏈接的註冊中心是否正確

2). 到註冊中心查看相應的服務提供者是否存在

3). 檢查服務提供者是否正常運行

7. 出現」 消息發送失敗」 異常

一般是接口方法的傳入傳出參數未實現 Serializable 接口。

1四、dubbo 和 dubbox 之間的區別？

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

1五、你還了解別的分佈式框架嗎？

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

1六、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 協議

1七、Dubbo 集羣的負載均衡有哪些策略　　

Dubbo 提供了常見的集羣策略實現，並預擴展點予以自行實現。

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

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

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

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

dubbo在調用服務不成功時，默認是會重試兩次的。這樣在服務端的處理時間超過了設定的超時時間時，就會有重複請求，好比在發郵件時，可能就會發出多份重複郵件，執行註冊請求時，就會插入多條重複的註冊數據，那麼怎麼解決超時問題呢？以下

對於核心的服務中心，去除dubbo超時重試機制，並從新評估設置超時時間。 業務處理代碼必須放在服務端，客戶端只作參數驗證和服務調用，不涉及業務流程處理 全局配置實例

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

固然Dubbo的重試機制實際上是很是好的QOS保證，它的路由機制，是會幫你把超時的請求路由到其餘機器上，而不是本機嘗試，因此 dubbo的重試機器也能必定程度的保證服務的質量。可是請必定要綜合線上的訪問狀況，給出綜合的評估。