測驗面試題集-Dubbo常見面試題

VOL 175

13

2020-11

今天距2021年48天

這是ITester軟體測驗小堆疊第175次推文

點擊上方藍字“ITester軟體測驗小堆疊“關注我，每周一、三、五早上 08:30準時推送，每月不定期贈送技術書籍，

微信公眾號后臺回復“資源”、“測驗工具包”領取測驗資源，回復“微信群”一起進群打怪，

本文5289字，閱讀約需15分鐘

水往低處流，人想往高處走，怎么能不懂 Dubbo？

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

1

什么是Dubbo？

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

• 集群容錯：提供基于介面方法的透明遠程程序呼叫，包括多協議支持，以及軟負載均衡，失敗容錯，地址路由，動態配置等集群支持，

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

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

2

Dubbo核心組件是？

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

• 消費者（Consumer）：呼叫遠程服務的服務消費方；

• 注冊中心（Registry）：服務注冊中心和發現中心；

• 監控中心（Monitor）：統計服務和呼叫次數，呼叫時間監控中心；

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

流程：首先生產者將服務注冊到注冊中心（zk），使用zk持久節點進行存盤，消費訂閱zk節點，一旦有節點變更，zk通過事件通知傳遞給消費者，消費可以呼叫生產者服務，服務與服務之間進行呼叫，都會在監控中心中，存盤一個記錄，

3

Dubbo的作業原理是？

• 服務啟動的時候，Provider和Consumer根據配置資訊，連接到注冊中心Register，分別向注冊中心注冊和訂閱服務；

• register根據服務訂閱關系，回傳Provider資訊到Consumer，同時Consumer會把Provider資訊快取到本地，如果資訊有變更，Consumer會收到來自Register的推送；

• Consumer生成代理物件，同時根據負載均衡策略，選擇一臺Provider，同時定時向Monitor記錄介面的呼叫次數和時間資訊，拿到代理物件之后，Consumer通過代理物件發起介面呼叫；

• Provider收到請求后對資料進行反序列化，然后通過代理呼叫具體的介面實作；

  

4

介紹一下Dubbo框架分層？

從大的范圍來說，Dubbo分為3層：Business業務邏輯層由我們自己來提供介面和實作還有一些配置資訊，RPC層就是真正的RPC呼叫的核心層，封裝整個RPC的呼叫程序、負載均衡、集群容錯、代理，Remoting層則是對網路傳輸協議和資料轉換的封裝，

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

• 服務介面層（Service）：與實際業務邏輯相關的，根據服務提供方和服務消費方的業務設計對應的介面和實作，
  

• 配置層（Config）：對外配置介面，以ServiceConfig和ReferenceConfig為中心，可以直接new配置類，也可以通過Spring決議配置生成配置類，

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

• 服務注冊層（Registry）：封裝服務地址的注冊與發現，以服務URL為中心，擴展介面為RegistryFactory、Registry和RegistryService，可能沒有服務注冊中心，此時服務提供方直接暴露服務，

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

• 監控層（Monitor）：RPC呼叫次數和呼叫時間監控，以Statistics為中心，擴展介面為MonitorFactory、Monitor和MonitorService，

• 遠程呼叫層（Protocol）：封將RPC呼叫，以Invocation和Result為中心，擴展介面為Protocol、Invoker和Exporter，Protocol是服務域，它是Invoker暴露和參考的主功能入口，它負責Invoker的生命周期管理，Invoker是物體域，它是Dubbo的核心模型，其它模型都向它靠擾，或轉換成它，它代表一個可執行體，可向它發起invoke呼叫，它有可能是一個本地的實作，也可能是一個遠程的實作，也可能一個集群實作，

• 資訊交換層（Exchange）：封裝請求回應模式，同步轉異步，以Request和Response為中心，擴展介面為Exchanger、ExchangeChannel、ExchangeClient和ExchangeServer，

• 網路傳輸層（Transport）：抽象mina和netty為統一介面，以Message為中心，擴展介面為Channel、Transporter、Client、Server和Codec，

• 資料序列化層（Serialize）：可復用的一些工具，擴展介面為Serialization、 ObjectInput、ObjectOutput和ThreadPool，

5

Dubbo支持哪些協議？

1.dubbo默認協議：

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

• 適合于小資料包大并發的服務呼叫和服務消費者數遠大于服務提供者數的情況；

• 不適合傳送大資料包的服務；

2.rmi協議：

• 采用 JDK 標準的 java.rmi.* 實作，阻塞式短連接和 JDK 標準序列化方式；

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

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

• 對傳輸資料包不限，消費者和傳輸者個數相當；

3.hessian協議：

• 底層 Http 通訊，Servlet 暴露服務，Dubbo 預設內嵌 Jetty 作為服務器實作；

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

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

• 引數及回傳值需實作 Serializable 介面，自定義實作 List、Map、Number、Date、Calendar 等介面；

• 適用于傳輸資料包較大，提供者比消費者個數多，提供者壓力較大；

4.http協議：

• 基于 http 表單的遠程呼叫協議，短連接，json 序列化；

• 對傳輸資料包不限，不支持傳檔案；

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

5.webservice協議：

• 基于Apache CXF 的frontend-simple和transports-http 實作，短連接，SOAP文本序列化；

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

• 適用于系統集成、跨語言呼叫；

6.thrift協議：

• 對 thrift 原生協議的擴展添加了額外的頭資訊；

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

7.redis協議:

• redis在TCP埠6379上監聽到來的連接，客戶端連接到來時，Redis服務器為此創建一個TCP連接 ;

• redis接收由不同引陣列成的命令，一旦收到命令，將會立刻被處理，并回復給客戶端;

8.memcached協議:

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

• memcached協議中發送的資料分為文本行和自由資料兩種；

6

Dubbo核心配置有哪些？

核心配置有：

7

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

在集群呼叫失敗時，Dubbo 提供了多種容錯方案，預設為 failover 重試，具體的集群容錯方案有：

Dubbo內置了4種負載均衡策略：

8

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

• 工廠模式：Provider在export服務時，會呼叫ServiceConfig的export方法，實作類的獲取采用了JDK SPI的機制，想要擴展實作，只需要在classpath下增加檔案即可，代碼零侵入；

• 裝飾器模式：Dubbo在啟動和呼叫階段都大量使用了裝飾器模式，如ClassLoaderFilter在主功能上添加功能，更改當前執行緒的ClassLoader是典型的裝飾器模式；

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

• 動態代理模式：Dubbo擴展JDK SPI的類ExtensionLoader的Adaptive實作是典型的動態代理實作，Dubbo需要靈活地控制實作類，即在呼叫階段動態地根據引數決定呼叫哪個實作類，所以采用先生成代理類的方法，做到靈活的呼叫，

9

Dubbo有哪些注冊中心？

• Multicast 注冊中心：Multicast 注冊中心不需要任何中心節點，只要廣播地址，就能進行服務注冊和發現,基于網路中組播傳輸實作，

• Zookeeper 注冊中心：基于分布式協調系統 Zookeeper 實作，采用 Zookeeper 的 watch 機制實作資料變更，

• Redis 注冊中心：基于 Redis 實作，采用 key/map 存盤，key 存盤服務名和型別，map 中 key 存盤服務 url，value 服務過期時間，基于 Redis 的發布/訂閱模式通知資料變更，

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

10

Dubbo內置了哪幾種服務容器？

• Spring Container；

• Jetty Container；

• Log4j Container；

11

Dubbo有哪幾種配置方式？

• XML 組態檔方式；

• properties 組態檔方式；

• annotation 配置方式；

• API 配置方式；

以上

That‘s all

更多系列文章

敬請期待

ITester軟體測驗小堆疊

往期內容寵幸

1.Python介面自動化-介面基礎(一)

2.Python介面自動化-介面基礎(二)

3.Python介面自動化-requests模塊之get請求

4.Python介面自動化-requests模塊之post請求

5.Python介面自動化之cookie、session應用

6.Python介面自動化之Token詳解及應用

7.Python介面自動化之requests請求封裝

8.Python介面自動化之pymysql資料庫操作

9.Python介面自動化之logging日志

10.Python介面自動化之logging封裝及實戰

想獲取更多最新干貨內容

快來星標 置頂 關注我

每周一、三、五 08:30見

<< 滑動查看下一張圖片 >>

后臺 回復"資源"取干貨

回復"微信群"一起打怪升級

個人微信：Cc2015123

添加請注明來意 :)

真愛三連，助力友誼的小船~