測試面試題集-Dubbo常見面試題
13
2020-11
今天距2021年48天
這是ITester軟件測試小棧第175次推文
點擊上方藍(lán)字“ITester軟件測試小棧“關(guān)注我，每周一、三、五早上?08:30準(zhǔn)時推送，每月不定期贈送技術(shù)書籍。
微信公眾號后臺回復(fù)“資源”、“測試工具包”領(lǐng)取測試資源，回復(fù)“微信群”一起進(jìn)群打怪。
本文5289字，閱讀約需15分鐘
水往低處流，人想往高處走，怎么能不懂 Dubbo？
Dubbo作為國內(nèi)最出名的分布式服務(wù)框架，是Java程序員必備必會的框架之一，更是中高級測試面試過程中經(jīng)常會問的技術(shù)，無論你是否用過，你都必須熟悉。以下總結(jié)一些 Dubbo常見的的面試題，希望對大家能有所幫助。
Dubbo是阿里巴巴公司開源的一個高性能分布式服務(wù)框架。其核心部分包含：
集群容錯：提供基于接口方法的透明遠(yuǎn)程過程調(diào)用，包括多協(xié)議支持，以及軟負(fù)載均衡，失敗容錯，地址路由，動態(tài)配置等集群支持。
遠(yuǎn)程通訊：提供對多種基于長連接的NIO框架抽象封裝，包括多種線程模型，序列化，以及“請求-響應(yīng)”模式的信息交換方式。
自動發(fā)現(xiàn)：基于注冊中心目錄服務(wù)，使服務(wù)消費(fèi)方能動態(tài)的查找服務(wù)提供方，使地址透明，使服務(wù)提供方可以平滑增加或減少機(jī)器。
生產(chǎn)者（Provider）：暴露服務(wù)的提供方，可以通過jar或者容器的方式啟動服務(wù)；
消費(fèi)者（Consumer）：調(diào)用遠(yuǎn)程服務(wù)的服務(wù)消費(fèi)方；
注冊中心（Registry）：服務(wù)注冊中心和發(fā)現(xiàn)中心；
監(jiān)控中心（Monitor）：統(tǒng)計服務(wù)和調(diào)用次數(shù)，調(diào)用時間監(jiān)控中心；
服務(wù)容器（Container）：服務(wù)運(yùn)行的容器，負(fù)責(zé)啟動、加載，運(yùn)行服務(wù)；
流程：首先生產(chǎn)者將服務(wù)注冊到注冊中心（zk），使用zk持久節(jié)點進(jìn)行存儲，消費(fèi)訂閱zk節(jié)點，一旦有節(jié)點變更，zk通過事件通知傳遞給消費(fèi)者，消費(fèi)可以調(diào)用生產(chǎn)者服務(wù)。服務(wù)與服務(wù)之間進(jìn)行調(diào)用，都會在監(jiān)控中心中，存儲一個記錄。
服務(wù)啟動的時候，Provider和Consumer根據(jù)配置信息，連接到注冊中心Register，分別向注冊中心注冊和訂閱服務(wù)；
register根據(jù)服務(wù)訂閱關(guān)系，返回Provider信息到Consumer，同時Consumer會把Provider信息緩存到本地。如果信息有變更，Consumer會收到來自Register的推送；
Consumer生成代理對象，同時根據(jù)負(fù)載均衡策略，選擇一臺Provider，同時定時向Monitor記錄接口的調(diào)用次數(shù)和時間信息，拿到代理對象之后，Consumer通過代理對象發(fā)起接口調(diào)用；
Provider收到請求后對數(shù)據(jù)進(jìn)行反序列化，然后通過代理調(diào)用具體的接口實現(xiàn)；
從大的范圍來說，Dubbo分為3層：Business業(yè)務(wù)邏輯層由我們自己來提供接口和實現(xiàn)還有一些配置信息，RPC層就是真正的RPC調(diào)用的核心層，封裝整個RPC的調(diào)用過程、負(fù)載均衡、集群容錯、代理，Remoting層則是對網(wǎng)絡(luò)傳輸協(xié)議和數(shù)據(jù)轉(zhuǎn)換的封裝。
劃分到更細(xì)的層面，就是10層模式，整個分層依賴由上至下，除開business業(yè)務(wù)邏輯之外，其他的幾層都是SPI機(jī)制。10層模式如下：
服務(wù)接口層（Service）：與實際業(yè)務(wù)邏輯相關(guān)的，根據(jù)服務(wù)提供方和服務(wù)消費(fèi)方的業(yè)務(wù)設(shè)計對應(yīng)的接口和實現(xiàn)。配置層（Config）：對外配置接口，以ServiceConfig和ReferenceConfig為中心，可以直接new配置類，也可以通過Spring解析配置生成配置類。服務(wù)代理層（Proxy）：服務(wù)接口透明代理，生成服務(wù)的客戶端Stub和服務(wù)器端Skeleton，以ServiceProxy為中心，擴(kuò)展接口為ProxyFactory。服務(wù)注冊層（Registry）：封裝服務(wù)地址的注冊與發(fā)現(xiàn)，以服務(wù)URL為中心，擴(kuò)展接口為RegistryFactory、Registry和RegistryService。可能沒有服務(wù)注冊中心，此時服務(wù)提供方直接暴露服務(wù)。集群層（Cluster）：封裝多個提供者的路由及負(fù)載均衡，并橋接注冊中心，以Invoker為中心，擴(kuò)展接口為Cluster、Directory、Router和LoadBalance。將多個服務(wù)提供方組合為一個服務(wù)提供方，實現(xiàn)對服務(wù)消費(fèi)方來透明，只需要與一個服務(wù)提供方進(jìn)行交互。監(jiān)控層（Monitor）：RPC調(diào)用次數(shù)和調(diào)用時間監(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是實體域，它是Dubbo的核心模型，其它模型都向它靠擾，或轉(zhuǎn)換成它，它代表一個可執(zhí)行體，可向它發(fā)起invoke調(diào)用，它有可能是一個本地的實現(xiàn)，也可能是一個遠(yuǎn)程的實現(xiàn)，也可能一個集群實現(xiàn)。信息交換層（Exchange）：封裝請求響應(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。
1.dubbo默認(rèn)協(xié)議：
單一 TCP 長連接，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.* 實現(xiàn)，阻塞式短連接和 JDK 標(biāo)準(zhǔn)序列化方式；
如果服務(wù)接口繼承了 java.rmi.Remote 接口，可以和原生 RMI 互操作；
因反序列化漏洞，需升級 commons-collections3 到 3.2.2版本或 commons-collections4 到 4.1 版本；
對傳輸數(shù)據(jù)包不限，消費(fèi)者和傳輸者個數(shù)相當(dāng)；
?
3.hessian協(xié)議：
底層 Http 通訊，Servlet 暴露服務(wù)，Dubbo 缺省內(nèi)嵌 Jetty 作為服務(wù)器實現(xiàn)；
可與原生 Hessian 服務(wù)互操作；
通訊效率高于 WebService 和 Java 自帶的序列化；
參數(shù)及返回值需實現(xiàn) Serializable 接口，自定義實現(xiàn) List、Map、Number、Date、Calendar 等接口；
適用于傳輸數(shù)據(jù)包較大，提供者比消費(fèi)者個數(shù)多，提供者壓力較大；
?
4.http協(xié)議：
基于 http 表單的遠(yuǎn)程調(diào)用協(xié)議，短連接，json 序列化；
對傳輸數(shù)據(jù)包不限，不支持傳文件；
適用于同時給應(yīng)用程序和瀏覽器 JS 使用的服務(wù)；
?
5.webservice協(xié)議：
基于Apache CXF 的frontend-simple和transports-http 實現(xiàn)，短連接，SOAP文本序列化；
可與原生WebService服務(wù)互操作；
適用于系統(tǒng)集成、跨語言調(diào)用；
?
6.thrift協(xié)議：
對 thrift 原生協(xié)議的擴(kuò)展添加了額外的頭信息；
使用較少，不支持傳 null 值；
?
7.redis協(xié)議:
redis在TCP端口6379上監(jiān)聽到來的連接，客戶端連接到來時，Redis服務(wù)器為此創(chuàng)建一個TCP連接?;
redis接收由不同參數(shù)組成的命令。一旦收到命令，將會立刻被處理，并回復(fù)給客戶端;
8.memcached協(xié)議:
客戶端使用TCP鏈接與服務(wù)器通訊，一個運(yùn)行中的memcached服務(wù)器監(jiān)視一些端口，客戶端連接這些端口，發(fā)送命令到服務(wù)器，讀取回應(yīng)，最后關(guān)閉連接;
memcached協(xié)議中發(fā)送的數(shù)據(jù)分為文本行和自由數(shù)據(jù)兩種；
核心配置有：
| 配置 | 說明 |
| dubbo:service/? | 服務(wù)配置 |
| dubbo:reference/ | 引用配置 |
| dubbo:argument/ | 參數(shù)配置 |
| dubbo:protocol/ | 協(xié)議配置 |
| dubbo:registry/ | 注冊中心配置 |
| dubbo:application/ | 應(yīng)用配置 |
| dubbo:provider/ | 提供方配置 |
| dubbo:consumer/ | 消費(fèi)方配置 |
| dubbo:method/ | 方法配置 |
| dubbo:module/ | 模塊配置 |
| dubbo:monitor/ | 監(jiān)控中心配置 |
在集群調(diào)用失敗時，Dubbo 提供了多種容錯方案，缺省為 failover 重試。具體的集群容錯方案有：
| 集群容錯方案 | 說明 |
| Failover Cluster | 失敗自動切換，自動重試其他服務(wù)器（默認(rèn)） |
| Failfast?Cluster | 快速失敗，立即報錯，只發(fā)起一次調(diào)用 |
| Failsafe Cluster | 失敗安全，出現(xiàn)異常時，直接忽略 |
| Failback Cluster | 失敗自動恢復(fù)，記錄失敗請求，定時重發(fā) |
| Forking Cluster | 并行調(diào)用多個服務(wù)器，只要一個成功即返回 |
| Broadcast Cluster | 廣播逐個調(diào)用所有提供者，任意一個報錯則報錯 |
Dubbo內(nèi)置了4種負(fù)載均衡策略：
| 負(fù)載均衡策略 | 說明 |
| RandomLoadBalance | 隨機(jī)負(fù)載均衡，按權(quán)重設(shè)置隨機(jī)概率（默認(rèn)） |
| RoundRobinLoadBalance | 輪詢負(fù)載均衡，按公約后的權(quán)重設(shè)置輪詢比率 |
| LeastActiveLoadBalance | 最少活躍調(diào)用數(shù)，相同活躍數(shù)的隨機(jī) |
| ConsistentHashLoadBalance | 一致性Hash負(fù)載均衡，相同參數(shù)的請求總是發(fā)到同一個提供者 |
工廠模式：Provider在export服務(wù)時，會調(diào)用ServiceConfig的export方法，實現(xiàn)類的獲取采用了JDK SPI的機(jī)制，想要擴(kuò)展實現(xiàn)，只需要在classpath下增加文件即可，代碼零侵入；
裝飾器模式：Dubbo在啟動和調(diào)用階段都大量使用了裝飾器模式，如ClassLoaderFilter在主功能上添加功能，更改當(dāng)前線程的ClassLoader是典型的裝飾器模式；
觀察者模式：Dubbo的Provider啟動時，需要與注冊中心交互，先注冊自己的服務(wù)，再訂閱自己的服務(wù)，訂閱時，采用了觀察者模式；
動態(tài)代理模式：Dubbo擴(kuò)展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
Multicast 注冊中心：Multicast 注冊中心不需要任何中心節(jié)點，只要廣播地址，就能進(jìn)行服務(wù)注冊和發(fā)現(xiàn),基于網(wǎng)絡(luò)中組播傳輸實現(xiàn)。
Zookeeper 注冊中心：基于分布式協(xié)調(diào)系統(tǒng) Zookeeper 實現(xiàn)，采用 Zookeeper 的 watch 機(jī)制實現(xiàn)數(shù)據(jù)變更。
Redis 注冊中心：基于 Redis 實現(xiàn)，采用 key/map 存儲，key 存儲服務(wù)名和類型，map 中 key 存儲服務(wù) url，value 服務(wù)過期時間。基于 Redis 的發(fā)布/訂閱模式通知數(shù)據(jù)變更。
Simple 注冊中心：Simple 注冊中心本身就是一個普通的 Dubbo 服務(wù)，可以減少第三方依賴，使整體通訊方式一致。
Spring Container；
Jetty Container；
Log4j Container；
XML 配置文件方式；
properties 配置文件方式；
annotation 配置方式；
API 配置方式；
?回復(fù)"資源"取干貨個人微信：Cc2015123
添加請注明來意 :)
