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

1、什么是Dubbo？

Dubbo是阿里巴巴公司開源的一個高性能分布式服務框架。其核心部分包含：

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

• 遠程通訊：提供對多種基于長連接的NIO框架抽象封裝，包括多種線程模型，序列化，以及“請求-響應”模式的信息交換方式。

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

2、Dubbo核心組件是？

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

• 消費者（Consumer）：調(diào)用遠程服務的服務消費方；

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

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

• 服務容器（Container）：服務運行的容器，負責啟動、加載，運行服務；

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

3、Dubbo的工作原理是？

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

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

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

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

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

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

劃分到更細的層面，就是10層模式，整個分層依賴由上至下，除開business業(yè)務邏輯之外，其他的幾層都是SPI機制。10層模式如下：

• 服務接口層（Service）：與實際業(yè)務邏輯相關的，根據(jù)服務提供方和服務消費方的業(yè)務設計對應的接口和實現(xiàn)。

• 配置層（Config）：對外配置接口，以ServiceConfig和ReferenceConfig為中心，可以直接new配置類，也可以通過Spring解析配置生成配置類。

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

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

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

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

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

• 信息交換層（Exchange）：封裝請求響應模式，同步轉異步，以Request和Response為中心，擴展接口為Exchanger、ExchangeChannel、ExchangeClient和ExchangeServer。

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

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

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

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

• 單一 TCP 長連接，Hessian 二進制序列化和 NIO 異步通訊；

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

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

2.rmi協(xié)議：

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

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

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

• 對傳輸數(shù)據(jù)包不限，消費者和傳輸者個數(shù)相當；

3.hessian協(xié)議：

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

• 可與原生 Hessian 服務互操作；

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

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

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

4.http協(xié)議：

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

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

• 適用于同時給應用程序和瀏覽器 JS 使用的服務；

5.webservice協(xié)議：

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

• 可與原生WebService服務互操作；

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

6.thrift協(xié)議：

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

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

7.redis協(xié)議:

• redis在TCP端口6379上監(jiān)聽到來的連接，客戶端連接到來時，Redis服務器為此創(chuàng)建一個TCP連接 ;

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

8.memcached協(xié)議:

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

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

6、Dubbo核心配置有哪些？

核心配置有：

7、Dubbo有哪幾種集群容錯方案、哪幾種負載均衡策略？

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

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

8、Dubbo用到哪些設計模式，簡要介紹？

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

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

• 觀察者模式：Dubbo的Provider啟動時，需要與注冊中心交互，先注冊自己的服務，再訂閱自己的服務，訂閱時，采用了觀察者模式；

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

9、Dubbo有哪些注冊中心？

• Multicast 注冊中心：Multicast 注冊中心不需要任何中心節(jié)點，只要廣播地址，就能進行服務注冊和發(fā)現(xiàn),基于網(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ù)變更。

• Simple 注冊中心：Simple 注冊中心本身就是一個普通的 Dubbo 服務，可以減少第三方依賴，使整體通訊方式一致。

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

• Spring Container；

• Jetty Container；

• Log4j Container；

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

• XML 配置文件方式；

• properties 配置文件方式；

• annotation 配置方式；

• API 配置方式；

到此這篇關于Java分布式服務框架Dubbo的文章就介紹到這了。希望對大家的學習有所幫助，也希望大家多多支持腳本之家。

最新評論