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

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

dubbo(默認(rèn))：?jiǎn)我婚L(zhǎng)連接和NIO異步通訊，適合大并發(fā)小數(shù)據(jù)量的服務(wù)調(diào)用，以及消費(fèi)者遠(yuǎn)大于提供者。傳輸協(xié)議 TCP，異步，Hessian 序列化;

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

webservice：基于 WebService 的遠(yuǎn)程調(diào)用協(xié)議，集成 CXF 實(shí)現(xiàn)，提供和原生 WebService 的互操作。多個(gè)短連接，基于 HTTP 傳輸，同步傳輸，適用系統(tǒng)集成和跨語(yǔ)言調(diào)用;

http：基于 Http 表單提交的遠(yuǎn)程調(diào)用協(xié)議，使用Spring的HttpInvoke 實(shí)現(xiàn)。多個(gè)短連接，傳輸協(xié)議 HTTP，傳入?yún)?shù)大小混合，提供者個(gè)數(shù)多于消費(fèi)者，需要給應(yīng)用程序和瀏覽器 JS 調(diào)用;

hessian：集成Hessian 服務(wù)，基于HTTP通訊，采用Servlet暴露服務(wù)，Dubbo 內(nèi)嵌 Jetty 作為服務(wù)器時(shí)默認(rèn)實(shí)現(xiàn)，提供與Hession服務(wù)互操作。多個(gè)短連接，同步 HTTP 傳輸，Hessian 序列化，傳入?yún)?shù)較大，提供者大于消費(fèi)者，提供者壓力較大，可傳文件;

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

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

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

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

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

【面試題3】Dubbo超時(shí)時(shí)間的設(shè)置

通過(guò)timeout屬性配置超時(shí)時(shí)間,服務(wù)的提供者和消費(fèi)者都可以配置，盡量在服務(wù)提供者中配置，因?yàn)榉?wù)的提供者會(huì)對(duì)自己提供的服務(wù)情況更清楚超時(shí)時(shí)間不要設(shè)置太大(1~5S),會(huì)影響并發(fā)性能問(wèn)題。

【面試題4】Dubbo自動(dòng)重試機(jī)

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

【面試題5】Dubbo支持的注冊(cè)中心

Multicast 注冊(cè)中心

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

Zookeeper 注冊(cè)中心

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

redis 注冊(cè)中心

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

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

隨機(jī)

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

輪循

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

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

相同活躍數(shù)的隨機(jī)，活躍數(shù)指調(diào)用前后計(jì)數(shù)差。使慢的提供者收到更少請(qǐng)求，因?yàn)樵铰奶峁┱叩恼{(diào)用前后計(jì)數(shù)差會(huì)越大。

一致性Hash

相同參數(shù)的請(qǐng)求總是發(fā)到同一提供者。當(dāng)某一臺(tái)提供者掛時(shí)，原本發(fā)往該提供者的請(qǐng)求，基于虛擬節(jié)點(diǎn)，平攤到其它提供者，不會(huì)引起劇烈變動(dòng)。

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

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

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

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

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

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

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

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

另外如果服務(wù)的提供者全部宕機(jī)，服務(wù)消費(fèi)者會(huì)無(wú)法使用，并無(wú)限次重連等待服務(wù)者恢復(fù);

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

Dubbo采用全Spring 配置方式，透明化接入應(yīng)用，對(duì)應(yīng)用沒(méi)有任何API 侵入，只需用Spring加載Dubbo的配置即可。

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

NIO Netty框架

【面試題11】Dubbo的集群容錯(cuò)方案

Failover Cluster(默認(rèn)):

失敗自動(dòng)切換，當(dāng)出現(xiàn)失敗，重試其它服務(wù)器。通常用于讀操作，但重試會(huì)帶來(lái)更長(zhǎng)延遲。

Failfast Cluster

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

Failsafe Cluster

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

Failback Cluster

失敗自動(dòng)恢復(fù)，后臺(tái)記錄失敗請(qǐng)求，定時(shí)重發(fā)。通常用于消息通知操作。

Forking Cluster

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

Broadcast Cluster

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

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

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


猜你喜歡：

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

Zookeeper+dubbo視頻教程

Java高級(jí)軟件工程師課程