Dubbo的面試題有哪些

本篇內(nèi)容介紹了“Dubbo的面試題有哪些”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠?qū)W有所成！

成都創(chuàng)新互聯(lián)堅持“要么做到，要么別承諾”的工作理念，服務領域包括：成都網(wǎng)站設計、做網(wǎng)站、企業(yè)官網(wǎng)、英文網(wǎng)站、手機端網(wǎng)站、網(wǎng)站推廣等服務，滿足客戶于互聯(lián)網(wǎng)時代的福安網(wǎng)站設計、移動媒體設計的需求，幫助企業(yè)找到有效的互聯(lián)網(wǎng)解決方案。努力成為您成熟可靠的網(wǎng)絡建設合作伙伴！

dubbo是什么

dubbo是一個分布式框架，遠程服務調(diào)用的分布式框架，其核心部分包含：集群容錯：提供基于接口方法的透明遠程過程調(diào)用，包括多協(xié)議支持，以及軟負載均衡，失敗容錯，地址路由，動態(tài)配置等集群支持。遠程通訊：提供對多種基于長連接的NIO框架抽象封裝，包括多種線程模型，序列化，以及“請求-響應”模式的信息交換方式。自動發(fā)現(xiàn)：基于注冊中心目錄服務，使服務消費方能動態(tài)的查找服務提供方，使地址透明，使服務提供方可以平滑增加或減少機器。

dubbo能做什么

透明化的遠程方法調(diào)用，就像調(diào)用本地方法一樣調(diào)用遠程方法，只需簡單配置，沒有任何API侵入。軟負載均衡及容錯機制，可在內(nèi)網(wǎng)替代F5等硬件負載均衡器，降低成本，減少單點。服務自動注冊與發(fā)現(xiàn)，不再需要寫死服務提供方地址，注冊中心基于接口名查詢服務提供者的IP地址，并且能夠平滑添加或刪除服務提供者。

1、默認使用的是什么通信框架，還有別的選擇嗎?

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

2、服務調(diào)用是阻塞的嗎？

答：默認是阻塞的，可以異步調(diào)用，沒有返回值的可以這么做。

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

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

ZooKeeper的節(jié)點是通過像樹一樣的結構來進行維護的，并且每一個節(jié)點通過路徑來標示以及訪問。除此之外，每一個節(jié)點還擁有自身的一些信息，包括：數(shù)據(jù)、數(shù)據(jù)長度、創(chuàng)建時間、修改時間等等。

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

答：默認使用 Hessian 序列化，還有 Duddo、FastJson、Java 自帶序列化。hessian是一個采用二進制格式傳輸?shù)姆湛蚣?，相對傳統(tǒng)soap web service，更輕量，更快速。

Hessian原理與協(xié)議簡析：

http的協(xié)議約定了數(shù)據(jù)傳輸?shù)姆绞?，hessian也無法改變太多：

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

2) hessian將輔助信息，封裝在http header中，比如“授權token”等，我們可以基于http-header來封裝關于“安全校驗”“meta數(shù)據(jù)”等。hessian提供了簡單的”校驗”機制。

3) 對于hessian的交互核心數(shù)據(jù)，比如“調(diào)用的方法”和參數(shù)列表信息，將通過post請求的body體直接發(fā)送，格式為字節(jié)流。

4) 對于hessian的server端響應數(shù)據(jù)，將在response中通過字節(jié)流的方式直接輸出。

hessian的協(xié)議本身并不復雜，在此不再贅言；所謂協(xié)議(protocol)就是約束數(shù)據(jù)的格式，client按照協(xié)議將請求信息序列化成字節(jié)序列發(fā)送給server端，server端根據(jù)協(xié)議，將數(shù)據(jù)反序列化成“對象”，然后執(zhí)行指定的方法，并將方法的返回值再次按照協(xié)議序列化成字節(jié)流，響應給client，client按照協(xié)議將字節(jié)流反序列話成”對象”。

5、服務提供者能實現(xiàn)失效踢出是什么原理？

答：服務失效踢出基于 zookeeper 的臨時節(jié)點原理。

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

答：采用多版本開發(fā)，不影響舊版本。在配置中添加version來作為版本區(qū)分

7、如何解決服務調(diào)用鏈過長的問題？

答：可以結合 zipkin 實現(xiàn)分布式服務追蹤。

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 推薦用什么協(xié)議？

答：默認使用 dubbo 協(xié)議。

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

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

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

dubbo 通過 token 令牌防止用戶繞過注冊中心直連，然后在注冊中心管理授權，dubbo 提供了黑白名單，控制服務所允許的調(diào)用方。

12、集群容錯怎么做？

答：讀操作建議使用 Failover 失敗自動切換，默認重試兩次其他服務器。寫操作建議使用 Failfast 快速失敗，發(fā)一次調(diào)用失敗就立即報錯。

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

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

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

2) dubbo 缺省會在啟動時檢查依賴是否可用，不可用就拋出異常，阻止 spring 初始化完成，check 屬性默認為 true。

測試時有些服務不關心或者出現(xiàn)了循環(huán)依賴，將 check 設置為 false

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

解決：讓服務提供者開發(fā)方，只訂閱服務，而不注冊正在開發(fā)的服務，通過直連測試正在開發(fā)的服務。設置 dubbo:registry 標簽的 register 屬性為 false。

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

在 spring 解析到 dubbo:service 時，就已經(jīng)向外暴露了服務，而 spring 還在接著初始化其他 bean，如果這時有請求進來，并且服務的實現(xiàn)類里有調(diào)用 applicationContext.getBean() 的用法。getBean 線程和 spring 初始化線程的鎖的順序不一樣，導致了線程死鎖，不能提供服務，啟動不了。

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

5) 服務注冊不上

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

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

在服務提供者機器上測試與注冊中心的網(wǎng)絡是否通

6) 出現(xiàn) RpcException: No provider available for remote service 異常

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

a. 檢查連接的注冊中心是否正確

b. 到注冊中心查看相應的服務提供者是否存在

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

7) 出現(xiàn)” 消息發(fā)送失敗” 異常

通常是接口方法的傳入傳出參數(shù)未實現(xiàn) Serializable 接口。

14、dubbo 和 dubbox 之間的區(qū)別？

答：dubbox 是當當網(wǎng)基于 dubbo 上做了一些擴展，如加了服務可 restful 調(diào)用，更新了開源組件等。

15、你還了解別的分布式框架嗎？

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

16、Dubbo 支持哪些協(xié)議，每種協(xié)議的應用場景，優(yōu)缺點？

dubbo：單一長連接和 NIO 異步通訊，適合大并發(fā)小數(shù)據(jù)量的服務調(diào)用，以及消費者遠大于提供者。傳輸協(xié)議 TCP，異步，Hessian 序列化；

rmi：采用 JDK 標準的 rmi 協(xié)議實現(xiàn)，傳輸參數(shù)和返回參數(shù)對象需要實現(xiàn) Serializable 接口，使用 java 標準序列化機制，使用阻塞式短連接，傳輸數(shù)據(jù)包大小混合，消費者和提供者個數(shù)差不多，可傳文件，傳輸協(xié)議 TCP。多個短連接，TCP 協(xié)議傳輸，同步傳輸，適用常規(guī)的遠程服務調(diào)用和 rmi 互操作。在依賴低版本的 Common-Collections 包，java 序列化存在安全漏洞；

webservice:基于 WebService 的遠程調(diào)用協(xié)議，集成 CXF 實現(xiàn)，提供和原生 WebService 的互操作。多個短連接，基于 HTTP 傳輸，同步傳輸，適用系統(tǒng)集成和跨語言調(diào)用；http：基于 Http 表單提交的遠程調(diào)用協(xié)議，使用 Spring 的 HttpInvoke 實現(xiàn)。多個短連接，傳輸協(xié)議 HTTP，傳入?yún)?shù)大小混合，提供者個數(shù)多于消費者，需要給應用程序和瀏覽器 JS 調(diào)用；hessian：集成 Hessian 服務，基于 HTTP 通訊，采用 Servlet 暴露服務，Dubbo 內(nèi)嵌 Jetty 作為服務器時默認實現(xiàn)，提供與 Hession 服務互操作。多個短連接，同步 HTTP 傳輸，Hessian 序列化，傳入?yún)?shù)較大，提供者大于消費者，提供者壓力較大，可傳文件；

memcache：基于 memcached 實現(xiàn)的 RPC 協(xié)議 redis：基于 redis 實現(xiàn)的 RPC 協(xié)議

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

Dubbo 提供了常見的集群策略實現(xiàn)，并預擴展點予以自行實現(xiàn)。

Random LoadBalance: 隨機選取提供者策略，有利于動態(tài)調(diào)整提供者權重。截面碰撞率高，調(diào)用次數(shù)越多，分布越均勻；

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

LeastActive LoadBalance: 最少活躍調(diào)用策略，解決慢提供者接收更少的請求；ConstantHash LoadBalance: 一致性 Hash 策略，使相同參數(shù)請求總是發(fā)到同一提供者，一臺機器宕機，可以基于虛擬節(jié)點，分攤至其他提供者，避免引起提供者的劇烈變動；

18、服務調(diào)用超時問題怎么解決

dubbo在調(diào)用服務不成功時，默認是會重試兩次的。這樣在服務端的處理時間超過了設定的超時時間時，就會有重復請求，比如在發(fā)郵件時，可能就會發(fā)出多份重復郵件，執(zhí)行注冊請求時，就會插入多條重復的注冊數(shù)據(jù)，那么怎么解決超時問題呢？如下

對于核心的服務中心，去除dubbo超時重試機制，并重新評估設置超時時間。業(yè)務處理代碼必須放在服務端，客戶端只做參數(shù)驗證和服務調(diào)用，不涉及業(yè)務流程處理 全局配置實例

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

“Dubbo的面試題有哪些”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關的知識可以關注創(chuàng)新互聯(lián)網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實用文章！

網(wǎng)站標題：Dubbo的面試題有哪些
標題來源：http://muchs.cn/article20/jcjdco.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供面包屑導航、關鍵詞優(yōu)化、外貿(mào)建站、企業(yè)網(wǎng)站制作、標簽優(yōu)化、網(wǎng)站導航

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)