dubbo面試題(Dubbo的面試題有哪些)

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 header中,比如“授權token”等,我們可以基于http-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的重試機制其實是非常好的QOS保證,它的路由機制,是會幫你把超時的請求路由到其他機器上,而不是本機嘗試,所以 dubbo的重試機器也能一定程度的保證服務的質量。但是請一定要綜合線上的訪問情況,給出綜合的評估。

“Dubbo的面試題有哪些”的內容就介紹到這里了,感謝大家的閱讀。如果想了解更多行業相關的知識可以關注本站網站,小編將為大家輸出更多高質量的實用文章!