微信公眾號：moon聊技術(shù)
關(guān)注選擇“ 星標(biāo) ”， 重磅干貨，第一 時間送達！
[如果你覺得文章對你有幫助，歡迎關(guān)注，在看，點贊，轉(zhuǎn)發(fā)]

前言

雖然金三銀四過了，但是金九銀十馬上就要到了，還不快快準(zhǔn)備起來？

今天就開啟《面試八股文》系列的第一版-RPC王者Dubbo，moon 在后續(xù)的《面試八股文》系列還將繼續(xù)推出mysql，spring，并發(fā)，redis，kafka，zookeeper等一系列文章。

當(dāng)然大家有什么好的建議也可以通過公眾號或者個人微信和我交流。

每天一個知識點

• 不要背，要理解，大家不要夸我內(nèi)卷了

目錄

• 1.Dubbo是什么？RPC又是什么？

• 2. Dubbo能做什么？

• 3.能說下Dubbo的總體的調(diào)用過程嗎？

• 4.說說Dubbo 支持哪些協(xié)議，每種協(xié)議的應(yīng)用場景和優(yōu)缺點

• 5.Dubbo中都用到哪些設(shè)計模式？

• 6.如果Dubbo中provider提供的服務(wù)由多個版本怎么辦？

• 7.服務(wù)暴露的流程是怎么樣的？

• 8.服務(wù)引用的流程是怎么樣的？

• 9.Dubbo的注冊中心有哪些？

• 10.聊聊Dubbo SPI機制？

• 11.Dubbo的SPi和JAVA的SPI有什么區(qū)別？

• 12.有哪些負載均衡策略？

• 13.集群容錯方式有哪些？

• 14.說說Dubbo的分層？

• 15.服務(wù)提供者能實現(xiàn)失效踢出是什么原理？

• 16.為什么要通過代理對象通信？？

• 17.怎么設(shè)計一個RPC框架？

1.Dubbo是什么？RPC又是什么？

Dubbo是一個分布式服務(wù)框架，致力于提供高性能和透明化的RPC遠程服務(wù)調(diào)用方案，以及SOA服務(wù)治理方案。

RPC（Remote Procedure Call）—遠程過程調(diào)用，它是一種通過網(wǎng)絡(luò)從遠程計算機程序上請求服務(wù)，而不需要了解底>層網(wǎng)絡(luò)技術(shù)的協(xié)議。RPC協(xié)議假定某些傳輸協(xié)議的存在，如TCP或UDP，為通信程序之間攜帶信息數(shù)據(jù)。在OSI網(wǎng)絡(luò)>通信模型中，RPC跨越了傳輸層和應(yīng)用層。RPC使得開發(fā)包括網(wǎng)絡(luò)分布式多程序在內(nèi)的應(yīng)用程序更加容易。RPC采用客戶機/服務(wù)器模式。請求程序就是一個客戶機，而服務(wù)提供程序就是一個服務(wù)器。首先，客戶機調(diào)用進程發(fā)>送一個有進程參數(shù)的調(diào)用信息到服務(wù)進程，然后等待應(yīng)答信息。在服務(wù)器端，進程保持睡眠狀態(tài)直到調(diào)用信息到達為>止。當(dāng)一個調(diào)用信息到達，服務(wù)器獲得進程參數(shù)，計算結(jié)果，發(fā)送答復(fù)信息，然后等待下一個調(diào)用信息，最后，客戶>端調(diào)用進程接收答復(fù)信息，獲得進程結(jié)果，然后調(diào)用執(zhí)行繼續(xù)進行。有多種 RPC模式和執(zhí)行。

我們用一種通俗易懂的語言解釋它，遠程調(diào)用就是本地機器調(diào)用遠程機器的一個方法，遠程機器返回結(jié)果的過程。

為什么要這么做？

主要原因是由于單臺服務(wù)的性能已經(jīng)無法滿足我們了，在這個流量劇增的時代，只有多臺服務(wù)器才能支撐起來現(xiàn)有的用戶體系，

而在這種體系下，服務(wù)越來越多，逐漸演化出了現(xiàn)在這種微服務(wù)化的RPC框架。

2. Dubbo能做什么？

Dubbo的核心功能主要包含:

• 
  
1. 遠程通訊:dubbo-remoting模塊， 提供對多種基于長連接的NIO框架抽象封裝，包括多種線程模型，序列化，以及“請求-響應(yīng)”模式的信息交換方式。
• 
  
2. 集群容錯: 提供基于接口方法的透明遠程過程調(diào)用，包括多協(xié)議支持，以及軟負載均衡，失敗容錯，地址路由，動態(tài)配置等集群支持。
• 
  
3. 自動發(fā)現(xiàn): 基于注冊中心目錄服務(wù)，使服務(wù)消費方能動態(tài)的查找服務(wù)提供方，使地址透明，使服務(wù)提供方可以平滑增加或減少機器。

3.能說下Dubbo的總體的調(diào)用過程嗎？

調(diào)用過程圖：

• 1.Proxy持有一個Invoker對象，使用Invoker調(diào)用
• 2.之后通過Cluster進行負載容錯，失敗重試
• 3.調(diào)用Directory獲取遠程服務(wù)的Invoker列表
• 4.負載均衡
• 用戶配置了路由規(guī)則，則根據(jù)路由規(guī)則過濾獲取到的Invoker列表
• 用戶沒有配置路由規(guī)則或配置路由后還有很多節(jié)點，則使用LoadBalance方法做負載均衡，選用一個可以調(diào)用的Invoker
• 5.經(jīng)過一個一個過濾器鏈，通常是處理上下文、限流、計數(shù)等。
• 6.會使用Client做數(shù)據(jù)傳輸
• 7.私有化協(xié)議的構(gòu)造(Codec)
• 8.進行序列化
• 9.服務(wù)端收到這個Request請求，將其分配到ThreadPool中進行處理
• 10.Server來處理這些Request
• 11.根據(jù)請求查找對應(yīng)的Exporter
• 12.之后經(jīng)過一個服務(wù)提供者端的過濾器鏈
• 13.然后找到接口實現(xiàn)并真正的調(diào)用，將請求結(jié)果返回

4.說說Dubbo 支持哪些協(xié)議，每種協(xié)議的應(yīng)用場景和優(yōu)缺點

• 1.dubbo 單一長連接和 NIO 異步通訊，適合大并發(fā)小數(shù)據(jù)量的服務(wù)調(diào)用，以及消費者遠大于提供者。傳輸協(xié)議 TCP，異步，Hessian 序列化

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

• 3.webservice 基于 WebService 的遠程調(diào)用協(xié)議，集成 CXF 實現(xiàn)，提供和原生 WebService 的互操作。多個短連接，基于 HTTP 傳輸，同步傳輸，適用系統(tǒng)集成和跨語言調(diào)用；

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

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

• 6.memcache ?基于 memcached 實現(xiàn)的 RPC 協(xié)議

• 7.redis 基于 redis 實現(xiàn)的 RPC 協(xié)議

5.Dubbo中都用到哪些設(shè)計模式？

責(zé)任鏈模式:
責(zé)任鏈模式在Dubbo中發(fā)揮的作用舉足輕重，就像是Dubbo框架的骨架。Dubbo的調(diào)用鏈組織是用責(zé)任鏈模式串連起來的。責(zé)任鏈中的每個節(jié)點實現(xiàn)Filter接口，然后由ProtocolFilterWrapper，將所有Filter串連起來。Dubbo的許多功能都是通過Filter擴展實現(xiàn)的，比如監(jiān)控、日志、緩存、安全、telnet以及RPC本身都是。

觀察者模式:
Dubbo中使用觀察者模式最典型的例子是RegistryService。消費者在初始化的時候回調(diào)用subscribe方法，注冊一個觀察者，如果觀察者引用的服務(wù)地址列表發(fā)生改變，就會通過NotifyListener通知消費者。此外，Dubbo的InvokerListener、ExporterListener 也實現(xiàn)了觀察者模式，只要實現(xiàn)該接口，并注冊，就可以接收到consumer端調(diào)用refer和provider端調(diào)用export的通知。

修飾器模式:
Dubbo中還大量用到了修飾器模式。比如ProtocolFilterWrapper類是對Protocol類的修飾。在export和refer方法中，配合責(zé)任鏈模式，把Filter組裝成責(zé)任鏈，實現(xiàn)對Protocol功能的修飾。其他還有ProtocolListenerWrapper、 ListenerInvokerWrapper、InvokerWrapper等。

工廠方法模式:
CacheFactory的實現(xiàn)采用的是工廠方法模式。CacheFactory接口定義getCache方法，然后定義一個AbstractCacheFactory抽象類實現(xiàn)CacheFactory，并將實際創(chuàng)建cache的createCache方法分離出來，并設(shè)置為抽象方法。這樣具體cache的創(chuàng)建工作就留給具體的子類去完成。

抽象工廠模式:
ProxyFactory及其子類是Dubbo中使用抽象工廠模式的典型例子。ProxyFactory提供兩個方法，分別用來生產(chǎn)Proxy和Invoker（這兩個方法簽名看起來有些矛盾，因為getProxy方法需要傳入一個Invoker對象，而getInvoker方法需要傳入一個Proxy對象，看起來會形成循環(huán)依賴，但其實兩個方式使用的場景不一樣）。AbstractProxyFactory實現(xiàn)了ProxyFactory接口，作為具體實現(xiàn)類的抽象父類。然后定義了JdkProxyFactory和JavassistProxyFactory兩個具體類，分別用來生產(chǎn)基于jdk代理機制和基于javassist代理機制的Proxy和Invoker。

適配器模式:
為了讓用戶根據(jù)自己的需求選擇日志組件，Dubbo自定義了自己的Logger接口，并為常見的日志組件（包括jcl, jdk, log4j, slf4j）提供相應(yīng)的適配器。并且利用簡單工廠模式提供一個LoggerFactory，客戶可以創(chuàng)建抽象的Dubbo自定義Logger，而無需關(guān)心實際使用的日志組件類型。在LoggerFactory初始化時，客戶通過設(shè)置系統(tǒng)變量的方式選擇自己所用的日志組件，這樣提供了很大的靈活性。

代理模式:
Dubbo consumer使用Proxy類創(chuàng)建遠程服務(wù)的本地代理，本地代理實現(xiàn)和遠程服務(wù)一樣的接口，并且屏蔽了網(wǎng)絡(luò)通信的細節(jié)，使得用戶在使用本地代理的時候，感覺和使用本地服務(wù)一樣。

6.如果Dubbo中provider提供的服務(wù)由多個版本怎么辦？

可以直接通過Dubbo配置中的version版本來控制多個版本即可。

比如：

"com.xxxx.rent.service.IDemoService"?ref="iDemoServiceFirst"?version="1.0.0"/>
"com.xxxx.rent.service.IDemoService"?ref="iDemoServiceSecond"?version="1.0.1"/>

老版本 version=1.0.0, 新版本version=1.0.1

7.服務(wù)暴露的流程是怎么樣的？

1.通過ServiceConfig解析標(biāo)簽，創(chuàng)建dubbo標(biāo)簽解析器來解析dubbo的標(biāo)簽，容器創(chuàng)建完成之后，觸發(fā)ContextRefreshEvent事件回調(diào)開始暴露服務(wù)

2.通過proxyFactory.getInvoker方法，并利用javassist或DdkProxyFactory來進行動態(tài)代理，將服務(wù)暴露接口封裝成invoker對象，里面包含了需要執(zhí)行的方法的對象信息和具體的URL地址。

3.再通過DubboProtocol的實現(xiàn)把包裝后的invoker轉(zhuǎn)換成exporter，

4.然后啟動服務(wù)器server，監(jiān)聽端口

5.最后RegistryProtocol保存URL地址和invoker的映射關(guān)系，同時注冊到服務(wù)中心

8.服務(wù)引用的流程是怎么樣的？

1.首先客戶端根據(jù)config文件信息從注冊中心訂閱服務(wù)，首次會全量緩存到本地，后續(xù)的更新會監(jiān)聽動態(tài)更新到本地。

2.之后DubboProtocol根據(jù)provider的地址和接口信息連接到服務(wù)端server，開啟客戶端client，然后創(chuàng)建invoker

3.之后通過invoker為服務(wù)接口生成代理對象，這個代理對象用于遠程調(diào)用provider，至此完成了服務(wù)引用

9.Dubbo的注冊中心有哪些？

Zookeeper、Redis、Multicast、Simple 等都可以作為Dubbo的注冊中心

10.聊聊Dubbo SPI機制？

SPI(Service Provider Interface)，是一種服務(wù)發(fā)現(xiàn)機制，其實就是將結(jié)構(gòu)的實現(xiàn)類寫入配置當(dāng)中，在服務(wù)加載的時候?qū)⑴渲梦募毺?，加載實現(xiàn)類，這樣就可以在運行的時候，動態(tài)的幫助接口替換實現(xiàn)類。

Dubbo的SPI其實是對java的SPI進行了一種增強,可以按需加載實現(xiàn)類之外，增加了 IOC 和 AOP 的特性，還有自適應(yīng)擴展機制。

SPI在dubbo應(yīng)用很多，包括協(xié)議擴展、集群擴展、路由擴展、序列化擴展等等。

Dubbo對于文件目錄的配置分為了三類。

• 1.META-INF/services/ 目錄：該目錄下的 SPI 配置文件是為了用來兼容 Java SPI 。
• 2.META-INF/dubbo/ 目錄：該目錄存放用戶自定義的 SPI 配置文件。

key=com.xxx.xxx

• 3.META-INF/dubbo/internal/ 目錄：該目錄存放 Dubbo 內(nèi)部使用的 SPI 配置文件。

11.Dubbo的SPi和JAVA的SPI有什么區(qū)別？

Java Spi

• Java SPI 在查找擴展實現(xiàn)類的時候遍歷 SPI 的配置文件并且將實現(xiàn)類全部實例化

Dubbo Spi

• 1，對 Dubbo 進行擴展，不需要改動 Dubbo 的源碼
• 2，延遲加載，可以一次只加載自己想要加載的擴展實現(xiàn)。
• 3，增加了對擴展點 IOC 和 AOP 的支持，一個擴展點可以直接 setter 注入其它擴展點。
• 4，Dubbo 的擴展機制能很好的支持第三方 IoC 容器，默認支持 Spring Bean。

12.有哪些負載均衡策略？

1.加權(quán)隨機：比如我們有三臺服務(wù)器[A, B, C]，給他們設(shè)置權(quán)重為[4, 5, 6]，然后講這三個數(shù)平鋪在水平線上,和為15。

然后在15以內(nèi)生成一個隨機數(shù)，0～4是服務(wù)器A，4～9是服務(wù)器B，9～15是服務(wù)器C

2.最小活躍數(shù)：每個服務(wù)提供者對應(yīng)一個活躍數(shù) active，初始情況下，所有服務(wù)提供者活躍數(shù)均為0。每收到一個請求，活躍數(shù)加1，完成請求后則將活躍數(shù)減1。在服務(wù)運行一段時間后，性能好的服務(wù)提供者處理請求的速度更快，因此活躍數(shù)下降的也越快，此時這樣的服務(wù)提供者能夠優(yōu)先獲取到新的服務(wù)請求。

3.一致性hash：

• 首先求出memcached服務(wù)器（節(jié)點）的哈希值，并將其配置到0～2的32次方的圓（continuum）上。
• 然后采用同樣的方法求出存儲數(shù)據(jù)的鍵的哈希值，并映射到相同的圓上。
• 然后從數(shù)據(jù)映射到的位置開始順時針查找，將數(shù)據(jù)保存到找到的第一個服務(wù)器上。如果超過2的32次方仍然找不到服務(wù)器，就會保存到第一臺memcached服務(wù)器上。

4.加權(quán)輪詢：比如我們有三臺服務(wù)器[A, B, C]，給他們設(shè)置權(quán)重為[4, 5, 6]，那么假如總共有15次請求，那么會有4次落在A服務(wù)器，5次落在B服務(wù)器，6次落在C服務(wù)器。

13.集群容錯方式有哪些？

1.Failover Cluster失敗自動切換：dubbo的默認容錯方案，當(dāng)調(diào)用失敗時自動切換到其他可用的節(jié)點，具體的重試次數(shù)和間隔時間可用通過引用服務(wù)的時候配置，默認重試次數(shù)為1是只調(diào)用一次。

2.Failback Cluster失敗自動恢復(fù)：在調(diào)用失敗，記錄日志和調(diào)用信息，然后返回空結(jié)果給consumer，并且通過定時任務(wù)每隔5秒對失敗的調(diào)用進行重試

3.Failfast Cluster快速失敗：只會調(diào)用一次，失敗后立刻拋出異常

4.Failsafe Cluster失敗安全：調(diào)用出現(xiàn)異常，記錄日志不拋出，返回空結(jié)果

5.Forking Cluster并行調(diào)用多個服務(wù)提供者：通過線程池創(chuàng)建多個線程，并發(fā)調(diào)用多個provider，結(jié)果保存到阻塞隊列，只要有一個provider成功返回了結(jié)果，就會立刻返回結(jié)果

6.Broadcast Cluster廣播模式：逐個調(diào)用每個provider，如果其中一臺報錯，在循環(huán)調(diào)用結(jié)束后，拋出異常。

14.說說Dubbo的分層？

分層圖：

從大的范圍來說，dubbo分為三層

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

Service和Config兩層可以認為是API層，主要提供給API使用者，使用者只需要配置和完成業(yè)務(wù)代碼就可以了。

后面所有的層級是SPI層，主 要提供給擴展者使用主要是用來做Dubbo的二次開發(fā)擴展功能。

再劃分到更細的層面，就是圖中的10層模式。

15.服務(wù)提供者能實現(xiàn)失效踢出是什么原理？

服務(wù)失效踢出基于Zookeeper的臨時節(jié)點原理。

Zookeeper中節(jié)點是有生命周期的，具體的生命周期取決于節(jié)點的類型，節(jié)點主要分為持久節(jié)點(Persistent)和臨時節(jié)點(Ephemeral) 。

16.為什么要通過代理對象通信？？

其實主要就是為了將調(diào)用細節(jié)封裝起來，將調(diào)用遠程方法變得和調(diào)用本地方法一樣簡單，還可以做一些其他方面的增強，比如負載均衡，容錯機制，過濾操作，調(diào)用數(shù)據(jù)的統(tǒng)計。

17.怎么設(shè)計一個RPC框架？

關(guān)于這個問題，其實核心考察點就是你對于RPC框架的理解，一個成熟的RPC框架可以完成哪些功能，其實當(dāng)我們看過一兩個RPC框架后，就可以對這個問題回答個七七八八了，我們來舉個例子。

1.首先我們得需要一個注冊中心，去管理消費者和提供者的節(jié)點信息，這樣才會有消費者和提供才可以去訂閱服務(wù)，注冊服務(wù)。

2.當(dāng)有了注冊中心后，可能會有很多個provider節(jié)點，那么我們肯定會有一個負載均衡模塊來負責(zé)節(jié)點的調(diào)用，至于用戶指定路由規(guī)則可以使一個額外的優(yōu)化點。

3.具體的調(diào)用肯定會需要牽扯到通信協(xié)議，所以需要一個模塊來對通信協(xié)議進行封裝，網(wǎng)絡(luò)傳輸還要考慮序列化。

4.當(dāng)調(diào)用失敗后怎么去處理？所以我們還需要一個容錯模塊，來負責(zé)失敗情況的處理。

5.其實做完這些一個基礎(chǔ)的模型就已經(jīng)搭建好了，我們還可以有更多的優(yōu)化點，比如一些請求數(shù)據(jù)的監(jiān)控，配置信息的處理，日志信息的處理等等。

這其實就是一個比較基本的RPC框架的大體思路，大家有沒有g(shù)et到？