Dubbo相關(guān)面試題附答案

【面試題1】Dubbo支持的協(xié)議

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é)議

傳入傳出參數(shù)數(shù)據(jù)包較小(建議小于100K)，消費者比提供者個數(shù)多，單一消費者無法壓滿提供者，盡量不要用dubbo協(xié)議傳輸大文件或超大字符串。

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

【面試題2】Dubbo推薦用什么協(xié)議?使用該協(xié)議有哪些優(yōu)缺點?

傳入傳出參數(shù)數(shù)據(jù)包較小(建議小于100K)，消費者比提供者個數(shù)多，單一消費者無法壓滿提供者，盡量不要用dubbo協(xié)議傳輸大文件或超大字符串。

【面試題3】Dubbo超時時間的設置

通過timeout屬性配置超時時間,服務的提供者和消費者都可以配置，盡量在服務提供者中配置，因為服務的提供者會對自己提供的服務情況更清楚超時時間不要設置太大(1~5S),會影響并發(fā)性能問題。

【面試題4】Dubbo自動重試機

Dubbo在調(diào)用服務不成功時，默認會重試2次。Dubbo的路由機制，會把超時的請求路由到其他機器上，而不是本機嘗試，所以 dubbo的重試機制也能一定程度的保證服務的質(zhì)量。

【面試題5】Dubbo支持的注冊中心

Multicast 注冊中心

Multicast 注冊中心不需要任何中心節(jié)點，只要廣播地址，就能進行服務注冊和發(fā)現(xiàn)?；诰W(wǎng)絡中組播傳輸實現(xiàn)

Zookeeper 注冊中心

基于分布式協(xié)調(diào)系統(tǒng) Zookeeper 實現(xiàn)，采用Zookeeper 的 watch 機制實現(xiàn)數(shù)據(jù)變更

redis 注冊中心

基于redis實現(xiàn)，采用key/Map存儲，住key存儲服務名和類型，Map中key存儲服務URL，value 服務過期時間。基于redis 的發(fā)布/訂閱模式通知數(shù)據(jù)變更;

【面試題6】Dubbo集群的負載均衡策略

隨機

按權(quán)重設置隨機概率。在一個截面上碰撞的概率高，但調(diào)用量越大分布越均勻，而且按概率使用權(quán)重后也比較均勻，有利于動態(tài)調(diào)整提供者權(quán)重。(權(quán)重可以在dubbo管控臺配置)

輪循

按公約后的權(quán)重設置輪循比率。存在慢的提供者累積請求問題，比如：第二臺機器很慢，但沒掛，當請求調(diào)到第二臺時就卡在那，久而久之，所有請求都卡在調(diào)到第二臺上。

最少活躍調(diào)用數(shù)

相同活躍數(shù)的隨機，活躍數(shù)指調(diào)用前后計數(shù)差。使慢的提供者收到更少請求，因為越慢的提供者的調(diào)用前后計數(shù)差會越大。

一致性Hash

相同參數(shù)的請求總是發(fā)到同一提供者。當某一臺提供者掛時，原本發(fā)往該提供者的請求，基于虛擬節(jié)點，平攤到其它提供者，不會引起劇烈變動。

【面試題7】Dubbo支持哪些序列化方式?

dubbo序列化：阿里尚未開發(fā)成熟的高效java序列化實現(xiàn)，阿里不建議在生產(chǎn)環(huán)境使用它

hessian2序列化(默認推薦)：hessian是一種跨語言的高效二進制序列化方式。但這里實際不是原生的hessian2序列化，而是阿里修改過的hessian lite，它是dubbo RPC默認啟用的序列化方式

json序列化：目前有兩種實現(xiàn)，一種是采用的阿里的fastjson庫，另一種是采用dubbo中自己實現(xiàn)的簡單json庫，但其實現(xiàn)都不是特別成熟，而且json這種文本序列化性能一般不如上面兩種二進制序列化。

java序列化：主要是采用JDK自帶的Java序列化實現(xiàn)，性能很不理想。

【面試題8】注冊中心宕機，服務間是否可以繼續(xù)通信

可以通信的，啟動dubbo時，消費者會從zk拉取注冊的生產(chǎn)者的地址接口等數(shù)據(jù)，緩存在本地。每次調(diào)用時，按照本地存儲的地址進行調(diào)用;

但前提是你沒有增加新的服務，如果你要調(diào)用新的服務，則是不能辦到的。

另外如果服務的提供者全部宕機，服務消費者會無法使用，并無限次重連等待服務者恢復;

【面試題9】Dubbo與spring的關(guān)系

Dubbo采用全Spring 配置方式，透明化接入應用，對應用沒有任何API 侵入，只需用Spring加載Dubbo的配置即可。

【面試題10】Dubbo使用的是什么通信框架?

NIO Netty框架

【面試題11】Dubbo的集群容錯方案

Failover Cluster(默認):

失敗自動切換，當出現(xiàn)失敗，重試其它服務器。通常用于讀操作，但重試會帶來更長延遲。

Failfast Cluster

快速失敗，只發(fā)起一次調(diào)用，失敗立即報錯。通常用于非冪等性的寫操作，比如新增記錄。

Failsafe Cluster

失敗安全，出現(xiàn)異常時，直接忽略。通常用于寫入審計日志等操作。

Failback Cluster

失敗自動恢復，后臺記錄失敗請求，定時重發(fā)。通常用于消息通知操作。

Forking Cluster

并行調(diào)用多個服務器，只要一個成功即返回。通常用于實時性要求較高的讀操作，但需要浪費更多服務資源。可通過 forks="2" 來設置最大并行數(shù)。

Broadcast Cluster

廣播調(diào)用所有提供者，逐個調(diào)用，任意一臺報錯則報錯 。通常用于通知所有提供者更新緩存或日志等本地資源信息。

【面試題12】Dubbo 和 Spring Cloud 的關(guān)系?

Dubbo 是 SOA 時代的產(chǎn)物，它的關(guān)注點主要在于服務的調(diào)用，流量分發(fā)、流量監(jiān)控和熔斷。而 Spring Cloud 誕生于微服務架構(gòu)時代，考慮的是微服務治理的方方面面，另外由于依托了 Spirng、Spirng Boot 的優(yōu)勢之上，兩個框架在開始目標就不一致，Dubbo定位服務治理、Spirng Cloud 是一個生態(tài)。最大的區(qū)別：Dubbo 底層是使用 Netty 這樣的 NIO 框架，是基于TCP 協(xié)議傳輸?shù)模浜弦?Hession 序列化完成 RPC 通信。而 SpringCloud 是基于 Http 協(xié)議+Rest 接口調(diào)用遠程過程的通信，相對來說，Http 請求會有更大的報文，占的帶寬也會更多。但是REST相比RPC更為靈活，服務提供方和調(diào)用方的依賴只依靠一紙契約，不存在代碼級別的強依賴。


猜你喜歡：

Spring Cloud和Dubbo的區(qū)別是什么?

Zookeeper+dubbo視頻教程

Java高級軟件工程師課程