Dubbo作為國(guó)內(nèi)最出名的分布式服務(wù)框架，是Java程序員必備必會(huì)的框架之一，更是中高級(jí)測(cè)試面試過(guò)程中經(jīng)常會(huì)問(wèn)的技術(shù)，無(wú)論你是否用過(guò)，你都必須熟悉。以下總結(jié)一些 Dubbo常見(jiàn)的的面試題，希望對(duì)大家能有所幫助。

1、什么是Dubbo？

Dubbo是阿里巴巴公司開(kāi)源的一個(gè)高性能分布式服務(wù)框架。其核心部分包含：

• 集群容錯(cuò)：提供基于接口方法的透明遠(yuǎn)程過(guò)程調(diào)用，包括多協(xié)議支持，以及軟負(fù)載均衡，失敗容錯(cuò)，地址路由，動(dòng)態(tài)配置等集群支持。

• 遠(yuǎn)程通訊：提供對(duì)多種基于長(zhǎng)連接的NIO框架抽象封裝，包括多種線程模型，序列化，以及“請(qǐng)求-響應(yīng)”模式的信息交換方式。

• 自動(dòng)發(fā)現(xiàn)：基于注冊(cè)中心目錄服務(wù)，使服務(wù)消費(fèi)方能動(dòng)態(tài)的查找服務(wù)提供方，使地址透明，使服務(wù)提供方可以平滑增加或減少機(jī)器。

2、Dubbo核心組件是？

• 生產(chǎn)者（Provider）：暴露服務(wù)的提供方，可以通過(guò)jar或者容器的方式啟動(dòng)服務(wù)；

• 消費(fèi)者（Consumer）：調(diào)用遠(yuǎn)程服務(wù)的服務(wù)消費(fèi)方；

• 注冊(cè)中心（Registry）：服務(wù)注冊(cè)中心和發(fā)現(xiàn)中心；

• 監(jiān)控中心（Monitor）：統(tǒng)計(jì)服務(wù)和調(diào)用次數(shù)，調(diào)用時(shí)間監(jiān)控中心；

• 服務(wù)容器（Container）：服務(wù)運(yùn)行的容器，負(fù)責(zé)啟動(dòng)、加載，運(yùn)行服務(wù)；

流程：首先生產(chǎn)者將服務(wù)注冊(cè)到注冊(cè)中心（zk），使用zk持久節(jié)點(diǎn)進(jìn)行存儲(chǔ)，消費(fèi)訂閱zk節(jié)點(diǎn)，一旦有節(jié)點(diǎn)變更，zk通過(guò)事件通知傳遞給消費(fèi)者，消費(fèi)可以調(diào)用生產(chǎn)者服務(wù)。服務(wù)與服務(wù)之間進(jìn)行調(diào)用，都會(huì)在監(jiān)控中心中，存儲(chǔ)一個(gè)記錄。

3、Dubbo的工作原理是？

• 服務(wù)啟動(dòng)的時(shí)候，Provider和Consumer根據(jù)配置信息，連接到注冊(cè)中心Register，分別向注冊(cè)中心注冊(cè)和訂閱服務(wù)；

• register根據(jù)服務(wù)訂閱關(guān)系，返回Provider信息到Consumer，同時(shí)Consumer會(huì)把Provider信息緩存到本地。如果信息有變更，Consumer會(huì)收到來(lái)自Register的推送；

• Consumer生成代理對(duì)象，同時(shí)根據(jù)負(fù)載均衡策略，選擇一臺(tái)Provider，同時(shí)定時(shí)向Monitor記錄接口的調(diào)用次數(shù)和時(shí)間信息，拿到代理對(duì)象之后，Consumer通過(guò)代理對(duì)象發(fā)起接口調(diào)用；

• Provider收到請(qǐng)求后對(duì)數(shù)據(jù)進(jìn)行反序列化，然后通過(guò)代理調(diào)用具體的接口實(shí)現(xiàn)；

4、介紹一下Dubbo框架分層？

從大的范圍來(lái)說(shuō)，Dubbo分為3層：Business業(yè)務(wù)邏輯層由我們自己來(lái)提供接口和實(shí)現(xiàn)還有一些配置信息，RPC層就是真正的RPC調(diào)用的核心層，封裝整個(gè)RPC的調(diào)用過(guò)程、負(fù)載均衡、集群容錯(cuò)、代理，Remoting層則是對(duì)網(wǎng)絡(luò)傳輸協(xié)議和數(shù)據(jù)轉(zhuǎn)換的封裝。

劃分到更細(xì)的層面，就是10層模式，整個(gè)分層依賴(lài)由上至下，除開(kāi)business業(yè)務(wù)邏輯之外，其他的幾層都是SPI機(jī)制。10層模式如下：

• 服務(wù)接口層（Service）：與實(shí)際業(yè)務(wù)邏輯相關(guān)的，根據(jù)服務(wù)提供方和服務(wù)消費(fèi)方的業(yè)務(wù)設(shè)計(jì)對(duì)應(yīng)的接口和實(shí)現(xiàn)。

• 配置層（Config）：對(duì)外配置接口，以ServiceConfig和ReferenceConfig為中心，可以直接new配置類(lèi)，也可以通過(guò)Spring解析配置生成配置類(lèi)。

• 服務(wù)代理層（Proxy）：服務(wù)接口透明代理，生成服務(wù)的客戶(hù)端Stub和服務(wù)器端Skeleton，以ServiceProxy為中心，擴(kuò)展接口為ProxyFactory。

• 服務(wù)注冊(cè)層（Registry）：封裝服務(wù)地址的注冊(cè)與發(fā)現(xiàn)，以服務(wù)URL為中心，擴(kuò)展接口為RegistryFactory、Registry和RegistryService?？赡軟](méi)有服務(wù)注冊(cè)中心，此時(shí)服務(wù)提供方直接暴露服務(wù)。

• 集群層（Cluster）：封裝多個(gè)提供者的路由及負(fù)載均衡，并橋接注冊(cè)中心，以Invoker為中心，擴(kuò)展接口為Cluster、Directory、Router和LoadBalance。將多個(gè)服務(wù)提供方組合為一個(gè)服務(wù)提供方，實(shí)現(xiàn)對(duì)服務(wù)消費(fèi)方來(lái)透明，只需要與一個(gè)服務(wù)提供方進(jìn)行交互。

• 監(jiān)控層（Monitor）：RPC調(diào)用次數(shù)和調(diào)用時(shí)間監(jiān)控，以Statistics為中心，擴(kuò)展接口為MonitorFactory、Monitor和MonitorService。

• 遠(yuǎn)程調(diào)用層（Protocol）：封將RPC調(diào)用，以Invocation和Result為中心，擴(kuò)展接口為Protocol、Invoker和Exporter。Protocol是服務(wù)域，它是Invoker暴露和引用的主功能入口，它負(fù)責(zé)Invoker的生命周期管理。Invoker是實(shí)體域，它是Dubbo的核心模型，其它模型都向它靠擾，或轉(zhuǎn)換成它，它代表一個(gè)可執(zhí)行體，可向它發(fā)起invoke調(diào)用，它有可能是一個(gè)本地的實(shí)現(xiàn)，也可能是一個(gè)遠(yuǎn)程的實(shí)現(xiàn)，也可能一個(gè)集群實(shí)現(xiàn)。

• 信息交換層（Exchange）：封裝請(qǐng)求響應(yīng)模式，同步轉(zhuǎn)異步，以Request和Response為中心，擴(kuò)展接口為Exchanger、ExchangeChannel、ExchangeClient和ExchangeServer。

• 網(wǎng)絡(luò)傳輸層（Transport）：抽象mina和netty為統(tǒng)一接口，以Message為中心，擴(kuò)展接口為Channel、Transporter、Client、Server和Codec。

• 數(shù)據(jù)序列化層（Serialize）：可復(fù)用的一些工具，擴(kuò)展接口為Serialization、 ObjectInput、ObjectOutput和ThreadPool。

5、Dubbo支持哪些協(xié)議？

1.dubbo默認(rèn)協(xié)議：

• 單一 TCP 長(zhǎng)連接，Hessian 二進(jìn)制序列化和 NIO 異步通訊；

• 適合于小數(shù)據(jù)包大并發(fā)的服務(wù)調(diào)用和服務(wù)消費(fèi)者數(shù)遠(yuǎn)大于服務(wù)提供者數(shù)的情況；

• 不適合傳送大數(shù)據(jù)包的服務(wù)；

2.rmi協(xié)議：

• 采用 JDK 標(biāo)準(zhǔn)的 java.rmi.* 實(shí)現(xiàn)，阻塞式短連接和 JDK 標(biāo)準(zhǔn)序列化方式；

• 如果服務(wù)接口繼承了 java.rmi.Remote 接口，可以和原生 RMI 互操作；

• 因反序列化漏洞，需升級(jí) commons-collections3 到 3.2.2版本或 commons-collections4 到 4.1 版本；

• 對(duì)傳輸數(shù)據(jù)包不限，消費(fèi)者和傳輸者個(gè)數(shù)相當(dāng)；

3.hessian協(xié)議：

• 底層 Http 通訊，Servlet 暴露服務(wù)，Dubbo 缺省內(nèi)嵌 Jetty 作為服務(wù)器實(shí)現(xiàn)；

• 可與原生 Hessian 服務(wù)互操作；

• 通訊效率高于 WebService 和 Java 自帶的序列化；

• 參數(shù)及返回值需實(shí)現(xiàn) Serializable 接口，自定義實(shí)現(xiàn) List、Map、Number、Date、Calendar 等接口；

• 適用于傳輸數(shù)據(jù)包較大，提供者比消費(fèi)者個(gè)數(shù)多，提供者壓力較大；

4.http協(xié)議：

• 基于 http 表單的遠(yuǎn)程調(diào)用協(xié)議，短連接，json 序列化；

• 對(duì)傳輸數(shù)據(jù)包不限，不支持傳文件；

• 適用于同時(shí)給應(yīng)用程序和瀏覽器 JS 使用的服務(wù)；

5.webservice協(xié)議：

• 基于Apache CXF 的frontend-simple和transports-http 實(shí)現(xiàn)，短連接，SOAP文本序列化；

• 可與原生WebService服務(wù)互操作；

• 適用于系統(tǒng)集成、跨語(yǔ)言調(diào)用；

6.thrift協(xié)議：

• 對(duì) thrift 原生協(xié)議的擴(kuò)展添加了額外的頭信息；

• 使用較少，不支持傳 null 值； 

7.redis協(xié)議:

• redis在TCP端口6379上監(jiān)聽(tīng)到來(lái)的連接，客戶(hù)端連接到來(lái)時(shí)，Redis服務(wù)器為此創(chuàng)建一個(gè)TCP連接 ;

• redis接收由不同參數(shù)組成的命令。一旦收到命令，將會(huì)立刻被處理，并回復(fù)給客戶(hù)端;

8.memcached協(xié)議:

• 客戶(hù)端使用TCP鏈接與服務(wù)器通訊，一個(gè)運(yùn)行中的memcached服務(wù)器監(jiān)視一些端口，客戶(hù)端連接這些端口，發(fā)送命令到服務(wù)器，讀取回應(yīng)，最后關(guān)閉連接;

• memcached協(xié)議中發(fā)送的數(shù)據(jù)分為文本行和自由數(shù)據(jù)兩種；

6、Dubbo核心配置有哪些？

核心配置有：

7、Dubbo有哪幾種集群容錯(cuò)方案、哪幾種負(fù)載均衡策略？

在集群調(diào)用失敗時(shí)，Dubbo 提供了多種容錯(cuò)方案，缺省為 failover 重試。具體的集群容錯(cuò)方案有：

Dubbo內(nèi)置了4種負(fù)載均衡策略：

8、Dubbo用到哪些設(shè)計(jì)模式，簡(jiǎn)要介紹？

• 工廠模式：Provider在export服務(wù)時(shí)，會(huì)調(diào)用ServiceConfig的export方法，實(shí)現(xiàn)類(lèi)的獲取采用了JDK SPI的機(jī)制，想要擴(kuò)展實(shí)現(xiàn)，只需要在classpath下增加文件即可，代碼零侵入；

• 裝飾器模式：Dubbo在啟動(dòng)和調(diào)用階段都大量使用了裝飾器模式，如ClassLoaderFilter在主功能上添加功能，更改當(dāng)前線程的ClassLoader是典型的裝飾器模式；

• 觀察者模式：Dubbo的Provider啟動(dòng)時(shí)，需要與注冊(cè)中心交互，先注冊(cè)自己的服務(wù)，再訂閱自己的服務(wù)，訂閱時(shí)，采用了觀察者模式；

• 動(dòng)態(tài)代理模式：Dubbo擴(kuò)展JDK SPI的類(lèi)ExtensionLoader的Adaptive實(shí)現(xiàn)是典型的動(dòng)態(tài)代理實(shí)現(xiàn)，Dubbo需要靈活地控制實(shí)現(xiàn)類(lèi)，即在調(diào)用階段動(dòng)態(tài)地根據(jù)參數(shù)決定調(diào)用哪個(gè)實(shí)現(xiàn)類(lèi)，所以采用先生成代理類(lèi)的方法，做到靈活的調(diào)用。

9、Dubbo有哪些注冊(cè)中心？

• Multicast 注冊(cè)中心：Multicast 注冊(cè)中心不需要任何中心節(jié)點(diǎn)，只要廣播地址，就能進(jìn)行服務(wù)注冊(cè)和發(fā)現(xiàn),基于網(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ù)名和類(lèi)型，map 中 key 存儲(chǔ)服務(wù) url，value 服務(wù)過(guò)期時(shí)間?；?Redis 的發(fā)布/訂閱模式通知數(shù)據(jù)變更。

• Simple 注冊(cè)中心：Simple 注冊(cè)中心本身就是一個(gè)普通的 Dubbo 服務(wù)，可以減少第三方依賴(lài)，使整體通訊方式一致。

10、Dubbo內(nèi)置了哪幾種服務(wù)容器？

• Spring Container；

• Jetty Container；

• Log4j Container；

11、Dubbo有哪幾種配置方式？

• XML 配置文件方式；

• properties 配置文件方式；

• annotation 配置方式；

• API 配置方式；

到此這篇關(guān)于Java分布式服務(wù)框架Dubbo的文章就介紹到這了。希望對(duì)大家的學(xué)習(xí)有所幫助，也希望大家多多支持腳本之家。

最新評(píng)論