歡迎光臨
每天分享高質量文章

Dubbo 面試 18 問!這些你都會嗎?

作者: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的重試機器也能一定程度的保證服務的質量。但是請一定要綜合線上的訪問情況,給出綜合的評估。

已同步到看一看
赞(0)

分享創造快樂