基礎(chǔ)知識

1.為什么要用Dubb。？

?隨著服務化的進一步發(fā)展，服務越來越多，服務之間的調(diào)用和依賴關(guān)系也越來越復雜，誕生了面向

服務的架構(gòu)體系(SOA),也因此衍生出了一系列相應的技術(shù)，如對服務提供、服務調(diào)用、連接處

理、通信協(xié)議、序列化方式、服務發(fā)現(xiàn)、服務路由、日志輸出等行為進行封裝的服務框架。就這樣

為分布式系統(tǒng)的服務治理框架就出現(xiàn)了，Dubbo也就這樣產(chǎn)生了。

2.Dubbo是什么？

?Dubb。是一款高性能、輕量級的開源RPC框架，提供服務自動注冊、自動發(fā)現(xiàn)等高效服務治理方

案，可以和Spring框架無縫集成。

3.Dubbo的使用場景有哪些？

?透明化的遠程方法調(diào)用：就像調(diào)用本地方法一樣調(diào)用遠程方法，只需簡單配置，沒有任何API侵

入。

?軟負載均衡及容錯機制：可在內(nèi)網(wǎng)替代F5等硬件負載均衡器，降低成本，減少單點。

?服務自動注冊與發(fā)現(xiàn)：不再需要寫死服務提供方地址，注冊中心基于接口名查詢服務提供者的IP地

址，并且能夠平滑添加或刪除服務提供者。

4.Dubbo核心功能有哪些？

?Remoting:網(wǎng)絡(luò)通信框架，提供對多種NIO框架抽象封裝，包括“同步轉(zhuǎn)異步"和"請求-響應”模式

的信息交換方式。

?Cluster:服務框架，提供基于接口方法的透明遠程過程調(diào)用，包括多協(xié)議支持，以及軟負載均

衡，失敗容錯，地址路由，動態(tài)配置等集群支持。

?Registry:服務注冊，基于注冊中心目錄服務，使服務消費方能動態(tài)的查找服務提供方，使地址透

明，使服務提供方可以平滑增加或減少機器。

5.Dubbo核心組件有哪些?

DubboArchitecture

?initasync—?sync

Registry

.z.??

.??.??

,*%1.register

2.subscr/ibeZ??’.?3.notify

Provider

4.invoke

Consumer：0.start

Container

5.count

Monitor

?Provider:暴露服務的服務提供方

?Consumer:調(diào)用遠程服務消費方

?Registry:服務注冊與發(fā)現(xiàn)注冊中心

?Monitor:監(jiān)控中心和訪問調(diào)用統(tǒng)計

?Container:服務運行容器

6.Dubbo服務器注冊與發(fā)現(xiàn)的流程？

?服務容器Container負責啟動，加載，運行服務提供者。

?服務提供者Provider在啟動時，向注冊中心注冊自己提供的服務。

?服務消費者Consumer在啟動時，向注冊中心訂閱自己所需的服務。

?注冊中心Registry返回服務提供者地址列表給消費者，如果有變更，注冊中心將基于長連接推送變

更數(shù)據(jù)給消費者。

?服務消費者Consumer,從提供者地址列表中，基于軟負載均衡算法，選一臺提供者進行調(diào)用，如

果調(diào)用失敗，再選另一臺調(diào)用。

?服務消費者Consumer和提供者Provider,在內(nèi)存中累計調(diào)用次數(shù)和調(diào)用時間，定時每分鐘發(fā)送一

次統(tǒng)計數(shù)據(jù)到監(jiān)控中心Monitor。

架構(gòu)設(shè)計

7.Dubbo的整體架構(gòu)設(shè)計有哪些分層？

sDubboFramework_ConsumerProvider，StartInterface.Class―>Depend

&

Servicea

-InterfaceImplementv

.￡

s嗔

n

mConfign

ReferenceConfigServiceConfig

Proxy

ProxyFactoryInvoker

Registry

NotifyListenerRegistryRegistryFactory

RegistryDirectoryRegistryProtocol

Cluster

DirectoryCluster

InvokerRouterRouterFactory

loadBalance

d一

s

Monitor-

o

+

MonitorFilterMonitorMonitorFactory一n

q

u

Protocolu

InvokerProtocolExporter

DubbolnvokerDubboProtocolDubboExporterDubboHandlcr

Exchange

ExchangeclientExchangerExchangeSereverExchangeHandler

M3Transport

U

AClientTransporterServerChannciHandler

O-

E

w

aCodecChannelHandlerWrappcr

Serialize

ObjectoutputSerializationObjectinputThreadPool

?接口服務層(Service):該層與業(yè)務邏輯相關(guān)，根據(jù)provider和consumer的業(yè)務設(shè)計對應的接

口和實現(xiàn)

?配置層(Config):對外配置接口，以ServiceConfig和ReferenceConfig為中心

?服務代理層(Proxy):服務接口透明代理，生成服務的客戶端Stub和服務端的Skeleton,以

ServiceProxy為中心，擴展接口為ProxyFactory

?服務注冊層(Registry):封裝服務地址的注冊和發(fā)現(xiàn)，以服務URL為中心，擴展接口為

RegistryFactory.Registry.Registryservice

?路由層(Cluster):封裝多個提供者的路由和負載均衡，并橋接注冊中心，以Invoker為中心，

擴展接口為Cluster、Directory、Router和LoadBlancce

?監(jiān)控層(Monitor):RPC調(diào)用次數(shù)和調(diào)用時間監(jiān)控，以Statistics為中心，擴展接口為

MonitorFactory.Monitor和Monitorservice

?遠程調(diào)用層(Protocal):封裝RPC調(diào)用，以Invocation和Result為中心,擴展接口為

ProtocaLInvoker和Exporter

?信息交換層(Exchange):封裝請求響應模式，同步轉(zhuǎn)異步。以Request和Response為中心，

擴展接口為Exchanger,ExchangeChannekExchangeclient和Exchangeserver

?網(wǎng)絡(luò)傳輸層(Transport):抽象mina和netty為統(tǒng)一接口，以Message為中心，擴展接口為

Channel,Transporter.Client,ServerfnCodec

?數(shù)據(jù)序列化層(Serialize):可復用的一些工具，擴展接口為Serialization.Objectinput.

Objectoutput和ThreadPool

8.DubboMonitor實現(xiàn)原理?

?Consumer端在發(fā)起調(diào)用之前會先走filter鏈；provider端在接收到請求時也是先走filter鏈，然

后才進行真正的業(yè)務邏輯處理。默認情況下，在consumer和provider的filter鏈中都會有

Monitorfilter。

1.MonitorFilter[R]DubboMonitor發(fā)送數(shù)據(jù)

ZDubboMonitor將數(shù)據(jù)進行聚合后（默認聚合1min中的統(tǒng)計數(shù)據(jù)）暫存到

然后使用一個含有個線程（線

ConcurrentMap<StatisticszAtomicReference>statisticsMap,3

程名字：DubboMonitorSendTimer）的線程池每隔1min鐘，調(diào)用SimpleMonitorService遍歷

發(fā)送statisticsM叩中的統(tǒng)計數(shù)據(jù)，每發(fā)送完畢一個，就重置當前的Statistics的

AtomicReference

3.SimpleMonitorService將這些聚合數(shù)據(jù)塞入BlockingQueuequeue中（隊列大寫為100000）

4.SimpleMonitorService使用一個后臺線程（線程名為：DubboMonitorAsyncWriteLogThread）

將queue中的數(shù)據(jù)寫入文件（該線程以死循環(huán)的形式來寫）

5.SimpleMonitorService還會使用一個含有1個線程（線程名字：DubboMonitorTimer）的線程

池每隔5min鐘，將文件中的統(tǒng)計數(shù)據(jù)畫成圖表

分布式框架

9.Dubbo類似的分布式框架還有哪些？

?比較著名的就是SpringCloud。

10.Dubbo和SpringCloud有什么關(guān)系？

?Dubb。是SOA時代的產(chǎn)物，它的關(guān)注點主要在于服務的調(diào)用，流量分發(fā)、流量監(jiān)控和熔斷。而

SpringCloud誕生于微服務架構(gòu)時代，考慮的是微服務治理的方方面面，另外由于依托了

Spring、SpringBoot的優(yōu)勢之上，兩個框架在開始目標就不一致，Dubbo定位服務治理、

SpringCloud是打造一個生態(tài)。

11.Dubbo和SpringCloud有什么哪些區(qū)別？

?Dubbo底層是使用Netty這樣的NIO框架，是基于TCP協(xié)議傳輸?shù)模浜弦訦ession序列化完

成RPC通信。

?SpringCloud是基于Http協(xié)議Rest接口調(diào)用遠程過程的通信，相對來說Http請求會有更大的報

文，占的帶寬也會更多。但是REST相比RPC更為靈活，服務提供方和調(diào)用方的依賴只依靠一紙

契約，不存在代碼級別的強依賴，這在強調(diào)快速演化的微服務環(huán)境下，顯得更為合適，至于注重通

信速度還是方便靈活性，具體情況具體考慮。

12.Dubbo和Dubbox之間的區(qū)別？

?Dubbox是繼Dubb。停止維護后，當當網(wǎng)基于Dubbo做的一個擴展項目，如加了服務可Restful

調(diào)用，更新了開源組件等。

注冊中心

13.Dubbo有哪些注冊中心?

?Multicast注冊中心：Multicast注冊中心不需要任!可中心節(jié)點，只要廣播地址，就能進行服務注冊

和發(fā)現(xiàn)，基于網(wǎng)絡(luò)中組播傳輸實現(xiàn)。

?Zookeeper注冊中心：基于分布式協(xié)調(diào)系統(tǒng)Zookeeper實現(xiàn)，采用Zookeeper的watch機制實

現(xiàn)數(shù)據(jù)變更。

?Redis注冊中心：基于Redis實現(xiàn)，采用key/m叩存儲，key存儲服務名和類型，m叩中key存

儲服務url,value服務過期時間?；赗edis的發(fā)布/訂閱模式通知數(shù)據(jù)變更。

?Simple注冊中心。

?推薦使用Zookeeper作為注冊中心

14.Dubbo的注冊中心集群掛掉，發(fā)布者和訂閱者之間還能通信

么？

?可以通訊。啟動Dubb。時，消費者會從Zookeeper拉取注冊的生產(chǎn)者的地址接口等數(shù)據(jù)，緩存

在本地。每次調(diào)用時，按照本地存儲的地址進行調(diào)用。

集群

15.Dubbo集群提供了哪些負載均衡策略？

?RandomLoadBagnee:隨機選取提供者策略，有利于動態(tài)調(diào)整提供者權(quán)重。截面碰撞率高，調(diào)用

次數(shù)越多，分布越均勻。

?RoundRobinLoadBalance:輪循選取提供者策略，平均分布，但是存在請求累積的問題。

?LeastActiveLoadBalance:最少活躍調(diào)用策略，解決慢提供者接收更少的請求。

?ConstantHashLoadBalance:一致性Hash策略，使相同參數(shù)請求總是發(fā)到同一提供者，一臺機

器宕機，可以基于虛擬節(jié)點，分攤至其他提供者，避免引起提供者的劇烈變動。

默認為Random隨機調(diào)用。

16.Dubbo的集群容錯方案有哪些？

?FailoverCluster:失敗自動切換，當出現(xiàn)失敗，重試其它服務器。通常用于讀操作，但重試會帶

來更長延遲。

?FailfastCluster:快速失敗，只發(fā)起一次調(diào)用，失敗立即報錯。通常用于非鬲等性的寫操作，比如

新增記錄。

?FailsafeCluster:失敗安全，出現(xiàn)異常時，直接忽略。通常用于寫入審計日志等操作。

?FallbackCluster:失敗自動恢復，后臺記錄失敗請求，定時重發(fā)。通常用于消息通知操作。

?ForkingCluster:并行調(diào)用多個服務器，只要一個成功即返回。通常用于實時性要求較高的讀操

作，但需要浪費更多服務資源?？赏ㄟ^forks="2”來設(shè)置最大并行數(shù)。

?BroadcastCluster:廣播調(diào)用所有提供者，逐個調(diào)用，任意一臺報錯則報錯。通常用于通知所有

提供者更新緩存或日志等本地資源信息。

默認的容錯方案是Failovercluster.

配置

17.Dubbo配置文件是如何力口載到Spring中的?

?Spring容器在啟動的時候，會讀取到Spring默認的一些schema以及Dubbo自定義的

schema,每個schema都會對應一個自己的NamespaceHandler,NamespaceHandler里面通

過BeanDefinitionParser來解析配置信息并轉(zhuǎn)化為需要加載的bean對象！

18.說說核心的配置有哪些?

標簽用途解釋

dubboser服務配用于暴露一個服務，定義服務的元信息，一個服務可以用多個協(xié)議暴

vice/置露，一個服務也可以注冊到多個注冊中心

dubbo:ref引用配

用于創(chuàng)建一個遠程服務代理，一個引用可以指向多個注冊中心

6renee/置

dubbo:pro協(xié)議配

用于配置提供服務的協(xié)議信息，協(xié)議由提供方指定，消費方被動接受

tocol/置

dubbo:叩應用配

用于配置當前應用信息，不管該應用是提供者還是消費者

plication/置

dubbo:mo模塊配

用于配置當前模塊信息，可選

duIe/置

dubbo:reg注冊中

用于配置連接注冊中心相關(guān)信息

Istry/心配置

dubbo:mo監(jiān)控中

用于配置連接監(jiān)控中心相關(guān)信息，可選

nitor/心配置

dubbo:pr。提供方當ProtocolConfig和ServiceConfig某屬性沒有配置時，采用此缺省

video/配置值，可選

dubbo:co消費方

當ReferenceConfig某屬性沒有配置時，采用此缺省值，可選

nsumerV配置

dubbo:me方法配

用于ServiceConfig和ReferenceConfig指定方法級的配置信息

thod/置

dubbo:arg參數(shù)配

用于指定方法參數(shù)配置

ument置

如果是SpringBoot項目就只需要注解，或者開Application配置文件！！！

19.Dubbo超時設(shè)置有哪些方式？

Dubb。超時設(shè)置有兩種方式：

?服務提供者端設(shè)置超時時間，在Dubbo的用戶文檔中，推薦如果能在服務端多配置就盡量多配

置，因為服務提供者比消費者更清楚自己提供的服務特性。

?服務消費者端設(shè)置超時時間，如果在消費者端設(shè)置了超時時間，以消費者端為主，即優(yōu)先級更高。

因為服務調(diào)用方設(shè)置超時時間控制性更靈活。如果消費方超時，服務端線程不會定制，會產(chǎn)生警

告。

20.服務調(diào)用超時會怎么樣？

?dubb。在調(diào)用服務不成功時，默認是會重試兩次。

通信協(xié)議

21.Dubbo使用的是什么通信框架？

?默認使用Netty作為通訊框架。

22.Dubbo支持哪些協(xié)議，它們的優(yōu)缺點有哪些？

?Dubbo:單一長連接和NI0異步通訊，適合大并發(fā)小數(shù)據(jù)量的服務調(diào)用，以及消費者遠大于提供

者。傳輸協(xié)議TCP,異步Hessian序列化。Dubb。推薦使用dubb。協(xié)議。

?RMI:采用JDK標準的RMI協(xié)議實現(xiàn)，傳輸參數(shù)和返回參數(shù)對象需要實現(xiàn)Serializable接口，使

用Java標準序列化機制，使用阻塞式短連接，傳輸數(shù)據(jù)包大小混合，消費都口提供者個數(shù)差不

多，可傳文件，傳輸協(xié)議TCP。多個短連接TCP協(xié)議傳輸，同步傳輸，適用常規(guī)的遠程服務調(diào)用

和RMI互操作。在依賴低版本的Common-Collections包，Java序列化存在安全漏洞。

?WebService:基于WebService的遠程調(diào)用協(xié)議，集成CXF實現(xiàn)，提供和原生WebService的互

操作。多個短連接，基于HTTP傳輸，同步傳輸，適用系統(tǒng)集砌口跨語言調(diào)用。

?HTTP:基于Http表單提交的遠程調(diào)用協(xié)議，使用Spring的Httplnvoke實現(xiàn)。多個短連接，傳

輸協(xié)議HTTP,傳入?yún)?shù)大小混合，提供者個數(shù)多于消費者，需要給應用程序和瀏覽器JS調(diào)用。

?Hessian:集成Hessian服務,基于HTTP通訊，采用Servlet暴露服務，Dubbo內(nèi)嵌Jetty作為

服務器時默認實現(xiàn)，提供與Hession服務互操作。多個短連接，同步HTTP傳輸，Hessian序歹［|

化，傳入?yún)?shù)較大，提供者大于消費者，提供者壓力較大，可傳文件。

?Memcache:基于Memcache實現(xiàn)的RPC協(xié)議。

?Redis:基于Redis實現(xiàn)的RPC協(xié)議。

設(shè)計模式

23.Dubbo用到哪些設(shè)計模式？

Dubbo框架在初始化和通信過程中使用了多種設(shè)計模式，可靈活控制類加載、權(quán)限控制等功能。

?工廠模式

Provider在export服務時，會調(diào)用ServiceConfig的export方法。ServiceConfig中有個字段：

privatestaticfinalProtocolprotocol=

ExtensionLoader.getExtensionLoader(Protocol.class).getAdaptiveExtensi

on();

?工廠模式

Provider在export服務時，會調(diào)用ServiceConfig的export方法。ServiceConfig中有個字段:

privatestaticfinalProtocolprotocol=

ExtensionLoader.getExtensionLoader(Protocol.class).getAdaptiveExtensi

on();

Dubb。里有很多這種代碼。這也是一種工廠模式，只是實現(xiàn)類的獲取采用了JDKSPI的機制。這么實現(xiàn)

的優(yōu)點是可擴展性強，想要擴展實現(xiàn)，只需要在classpath下增加個文件就可以了，代碼零侵入。另

外，像上面的Adaptive實現(xiàn)，可以做到調(diào)用時動態(tài)決定調(diào)用哪個實現(xiàn)，但是由于這種實現(xiàn)采用了動態(tài)

代理，會造成代碼調(diào)試比較麻煩，需要分析出實際調(diào)用的實現(xiàn)類。

?裝飾器模式

Dubb。在啟動和調(diào)用階段都大量使用了裝飾器模式.以Provider提供的調(diào)用鏈為例，具體的調(diào)用

鏈代碼是在ProtocolFilterWrapper的buildlnvokerChain完成的，具體是將注解中含有

group=provider的Filter實現(xiàn)，按照order排序，最后的調(diào)用II褥是：

EchoFilter->ClassLoaderFiIter->GenericFi1ter->ContextFi1ter->

ExecuteLimitFi1ter->TraceFi1ter->TimeoutFi1ter->MonitorFi1ter->

Except!onFiIter

更確切地說，這里是裝飾器和責任鏈模式的混合使用。例如，EchoFilter的作用是判斷是否是回聲測試

請求，是的話直接返回內(nèi)容，這是一種責任鏈的體現(xiàn)。而像ClassLoaderFilter則只是在主功能上添加了

功能，更改當前線程的ClassLoader,這是典型的裝飾器模式。

?觀察者模式

Dubb。的Provider啟動時，需要與注冊中心交互，先注冊自己的服務，再訂閱自己的服務，訂閱

時，采用了觀察者模式，開啟一個listener。注冊中心會每5秒定時檢杳是否有服務更新，如果有

更新，向該服務的提供者發(fā)送Tnotify消息，provider接受至IJnotify消息后，運行

NotifyListener的notify方法，執(zhí)行監(jiān)聽器方法。

?動態(tài)代理模式

Dubbo擴展JDKSPI的類ExtensionLoader的Adaptive實現(xiàn)是典型的動態(tài)代理實現(xiàn)。Dubbo需

要靈活地控制實現(xiàn)類，即在調(diào)用階段動態(tài)地根據(jù)參數(shù)決定調(diào)用哪個實現(xiàn)類，所以采用先生成代理類

的方法，能夠做到靈活的調(diào)用。生成代理類的代碼是ExtensionLoader的

createAdaptiveExtensionClassCode方法。代理類主要邏輯是，獲取URL參數(shù)中指定參數(shù)的值作

為獲取實現(xiàn)類的key。

運維管理

24.服務上線怎么兼容舊版本？

?可以用版本號（version）過渡，多個不同版本的服務注冊到注冊中心，版本號不同的服務相互間

不引用。這個和服務分組的概念有一點類似。

25.Dubbotelnet命令能做什么？

?dubb。服務發(fā)布之后，我們可以利用telnet命令進行調(diào)試、管理。Dubbo2.0.5以上版本服務提

供端口支持telnet命令

26.Dubbo支持服務降級嗎？

?以通過dubbo:reference中設(shè)置mock="returnnull"。mock的值也可以修改為true,然后再跟

接口同一個路徑下實現(xiàn)一個Mock類，命名規(guī)則是“接口名稱+Mock”后綴。然后在Mock類里實

現(xiàn)自己的降級邏輯

27.Dubbo如何優(yōu)雅停機？

?Dubbo是通過JDK的ShutdownHook來完成優(yōu)雅停機的，所以如果使用kill-9PID等強制關(guān)閉指

令，是不會執(zhí)行優(yōu)雅停機的，只有通過killPID時，才會執(zhí)行。

SPI

28.DubboSPI和JavaSPI區(qū)別？

?JDKSPI：

JDK標準的SPI會一次性加載所有的擴展實現(xiàn)，如果有的擴展很耗時，但也沒用上，很浪費資源。

所以只希望加載某個的實現(xiàn)，就不現(xiàn)實了

?DUBBOSPI:

1、對Dubb。進行擴展，不需要改動Dubb。的源碼

2、延遲加載，可以一次只加載自己想要加載的擴展實現(xiàn)。

3、增加了對擴展點IOC和AOP的支持，一個擴展點可以直接setter注入其它擴展點。

4、Dubb。的擴展機制能很好的支持第三方loC容器，默認支持SpringBean。

其他

29.Dubbo支持分布式事務嗎？

?目前暫時不支持，可與通過tcc-transaction框架實現(xiàn)

?介紹：tcc-transaction是開源的TCC補償性分布式事務框架

?TCC-Transaction通過Dubb。隱式傳參的功能，避免自己對業(yè)務代碼的入侵。

30.Dubbo可以對結(jié)果進行緩存嗎？

?為了提高數(shù)據(jù)訪問的速度。Dubb。提供了聲明式緩存，以減少用戶加緩存的工作量

<dubbo:referencecache=Mtrue,//>

?其實比普通的配置文件就多了一個標簽cache=〃true〃

31.Dubbo必須依賴的包有哪些?

?Dubbo必須依賴JDK,其他為可選。

32.Dubbo支持哪些序列化方式？

?默認使用Hessian序列化，還有Duddo、Fastjson、Java自帶序列化。

33.Dubbo在安全方面有哪些措施？

?Dubb。通過Token令牌防止用戶繞過注冊中心直連，然后在注冊中心上管理授權(quán)。

?Dubb。還提供服務黑白名單，來控制服務所允許的調(diào)用方。

34.服務調(diào)用是阻塞的嗎？

?默認是阻塞的，可以異步調(diào)用，沒有返回值的可以這么做.Dubb。是基于NI。的非阻塞實現(xiàn)并行

調(diào)用，客戶端不需要啟動多線程即可完成并行調(diào)用多個遠程服務，相對多線程開銷較小，異步調(diào)用

會返回一個Future對象。

35.服務提供者能實現(xiàn)失效踢出是什么原理?

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

36.同一個服務多個注冊的情況下可以直連某一個服務嗎?

?可以點對點直連，修改配置即可，也可以通過telnet直接某個服務。

37.Dubbo服務降級，失敗重試怎么做?

?可以通過dubbo:reference中設(shè)置mock="returnnull"。mock的值也可以修改為true,然后再

跟接口同一個路徑下實現(xiàn)一個Mock類，命名規(guī)則是“接口名稱+Mock”后綴。然后在Mock類里

實現(xiàn)自己的降級邏輯

38.Dubbo使用過程中都遇到了些什么問題？

?在注冊中心找不到對應的服務，檢查service實現(xiàn)類是否添加了@service注解無法連接到注冊中心,

檢查配置文件中的對應的測試ip是否正確

RPC

39.為什么要有RPC

?http接口是在接口不多、系統(tǒng)與系統(tǒng)交互較少的情況下，解決信息孤島初期常使用的一種通信手

段；優(yōu)點就是簡單、直接、開發(fā)方便。利用現(xiàn)成的http協(xié)議進行傳輸。但是如果是一個大型的網(wǎng)

站，內(nèi)部子系統(tǒng)較多、接口非常多的情況下，RPC框架的好處就顯示出來了，首先就是長鏈接，不

必每次通信都要像http一樣去3次握手什么的，減少了網(wǎng)絡(luò)開銷；其次就是RPC框架一般都有注冊

中心，有豐富的監(jiān)控管理；發(fā)布、下線接口、動態(tài)擴展等，對調(diào)用方來說是無感知、統(tǒng)一化的操

作。第三個來說就是安全性。最后就是最近流行的服務化架構(gòu)、服務化治理，RPC框架是一個強力

的支撐。

?socket只是一個簡單的網(wǎng)絡(luò)通信方式，只是創(chuàng)建通信雙方的通信通道，而要實現(xiàn)rpc的功能，還需

要對其進行封裝，以實現(xiàn)更多的功能。

?RPC一般配合netty框架、spring自定義注解來編寫輕量級框架，其實netty內(nèi)部是封裝了socket

的，較新的jdk的10一般是NIO,即非阻塞10,在高并發(fā)網(wǎng)站中，RPC的優(yōu)勢會很明顯

40.什么是RPC

?RPC（RemoteProcedureCallProtocol）遠程過程調(diào)用協(xié)議，它是一種通過網(wǎng)絡(luò)從遠程計算機程

序上請求服務，而不需要了解底層網(wǎng)絡(luò)技術(shù)的協(xié)議。簡言之，RPC使得程序能夠像訪問本地系統(tǒng)資

源一樣，去訪問遠端系統(tǒng)資源。比較關(guān)鍵的一些方面包括：通訊協(xié)議、序列化、資源（接口）描

述、服務框架、性能、語言支持等。

［注冊中心

?簡單的說，RPC就是從一臺機器（客戶端）上通過參數(shù)傳遞的方式調(diào)用另一臺機器（服務器）上的一個

函數(shù)或方法（可以統(tǒng)稱為服務）并得到返回的結(jié)果。

41.PRC架構(gòu)組件

?一個基本的RPC架構(gòu)里面應該至少包含以下4個組件：

1、客戶端(Client):服務調(diào)用方(服務消費者)

2、客戶端存根(ClientStub):存放服務端地址信息，將客戶端的請求參數(shù)數(shù)據(jù)信息打包成網(wǎng)絡(luò)消

息，再通過網(wǎng)絡(luò)傳輸發(fā)送給服務端

3、服務端存根(ServerStub):接收客戶端發(fā)送過來的請求消息并進行解包，然后再調(diào)用本地服

務進行處理4、服務端(Server):服務的真正提供者

?具體調(diào)用過程：

1、服務消費者(client客戶端)通過調(diào)用本地服務的方式調(diào)用需要消費的服務；

2、客戶端存根(clientstub)接收到調(diào)用請求后負責將方法、入?yún)⒌刃畔⑿蛄谢?組裝)成能夠

進行網(wǎng)絡(luò)傳輸?shù)南Ⅲw；

3、客戶端存根(clientstub)找到遠程的服務地址，并且將消息通過網(wǎng)絡(luò)發(fā)送給服務端；

4、服務端存根(serverstub)收到消息后進行解碼(反序列化操作)；

5、服務端存根(serverstub)根據(jù)解碼結(jié)果調(diào)用本地的服務進行相關(guān)處理；

6、本地服務執(zhí)行具體業(yè)務邏輯并將處理結(jié)果返回給服務端存根(serverstub);

7、服務端存根(serverstub)將返回結(jié)果重新打包成消息(序列化)并通過網(wǎng)絡(luò)發(fā)送至消費方；

8、客戶端存根(clientstub)接收到消息，并進行解碼(反序列化)；

9、服務消費方得到最終結(jié)果；

而RPC框架的實現(xiàn)目標則是將上面的第2-10步完好地封裝起來，也就是把調(diào)用、編碼/解碼的過程給封裝起來，讓

用戶感覺上像調(diào)用本地服務一樣的調(diào)用遠程服務。

42.RPC和SOA、SOAP、REST的區(qū)別

?1、REST

可以看著是HTTP協(xié)議的一種直接應用，默認基于JSON作為傳輸格式，使用簡單,學習成本低效率高，

但是安全性較低。

?2、SOAP

SOAP是一種數(shù)據(jù)交換協(xié)議規(guī)范，是一種輕量的、簡單的、基于XML的協(xié)議的規(guī)范。而SOAP可以看

著是一個重量級的協(xié)議，基于XML、SOAP在安全方面是通過使用XML-Securit押口XML-Signature

兩個規(guī)范組成了WS-Security來實現(xiàn)安全控制的,當前已經(jīng)得到了各個廠商的支持。

它有什么優(yōu)點？簡單總結(jié)為：易用、靈活、跨語言、跨平臺。

?3、SOA

面向服務架構(gòu)，它可以根據(jù)需求通過網(wǎng)絡(luò)對松散耦合的粗粒度應用組件進行分布式部署、組合和使

用。服務層是SOA的基礎(chǔ)，可以直接被應用調(diào)用，從而有效控制系統(tǒng)中與軟件代理交互的人為依賴

性。

SOA是一種粗粒度、松耦合服務架構(gòu)，服務之間通過簡單、精確定義接口進行通訊，不涉及底層編

程接口和通訊模型。SOA可以看作是B/S模型、XML（標準通用標記語言的子集）/WebService技

術(shù)之后的自然延伸。

?4、REST和SOAP、RPC有何區(qū)別呢？

沒什么太大區(qū)別，他們的本質(zhì)都是提供可支持分布式的基礎(chǔ)服務，最大的區(qū)別在于他們各自的的特

點所帶來的不同應用場景。

43.RPC框架需要解決的問題？

?1、如何確定客戶端和服務端之間的通信協(xié)議？

?2、如何更高效地進行網(wǎng)絡(luò)通信？

?3、服務端提供的服務如何暴露給客戶端？

?4、客戶端如何發(fā)現(xiàn)這些暴露的服務？

?5、如何更高效地對請求對象和響應結(jié)果進行序列依口反序列化操作?

44.RPC的實現(xiàn)基礎(chǔ)？

?1、需要有非常高效的網(wǎng)絡(luò)通信，比如一般選擇Netty作為網(wǎng)絡(luò)通信框架；

?2、需要有比較高效的序列化框架，比如谷歌的Protobuf序列化框架；

?3、可靠的尋址方式（主要是提供服務的發(fā)現(xiàn)），比如可以使用Zookeeper來注冊服務等等;

?4、如果是帶會話（狀態(tài)）的RPC調(diào)用，還需要有會話和狀態(tài)保持的功能；

45.RPC使用了哪些關(guān)鍵技術(shù)？

?1、動態(tài)代理

生成ClientStub（客戶端存根）和ServerStub（服務端存根）的時候需要用到Java動態(tài)代理技術(shù)，可

以使用JDK提供的原生的動態(tài)代理機制，也可以使用開源的：CGLib代理，Javassist字節(jié)碼生成技術(shù)。

?2、序列化和反序列化

在網(wǎng)絡(luò)中，所有的數(shù)據(jù)都將會被轉(zhuǎn)化為字節(jié)進行傳送，所以為了能夠使參數(shù)對象在網(wǎng)絡(luò)中進行傳輸，需

要對這些參數(shù)進行序列化?口反序列化操作。

?序列化：把對象轉(zhuǎn)換為字節(jié)序列的過程稱為對象的序列化，也就是編碼的過程。反序列化：把字節(jié)

序列恢復為對象的過程稱為對象的反序列化，也就是解碼的過程。目前比較高效的開源序列化框

架：如Kryo、Fastjson和Protobuf等。

?反序列化：把字節(jié)序列恢復為對象的過程稱為對象的反序列化，也就是解碼的過程。目前比較高

效的開源序列化框架：如Kryo、Fastjson和Protobuf等。

?3、NIO通信

出于并發(fā)性能的考慮，傳統(tǒng)的阻塞式I。顯然不太合適，因此我們需要異步的10,即NIO。Java提供

了NI0的解決方案，Java7也提供了更優(yōu)秀的N10.2支持.可以選擇Netty或者MINA來解決NI0數(shù)據(jù)

傳輸?shù)膯栴}。

?4、服務注冊中心

可選：Redis、Zookeeper、ConsulxEtcd。一般使用ZooKeeper提供服務注冊與發(fā)現(xiàn)功能，解決單

點故障以及分布式部署的問題(注冊中心)。

46.主流RPC框架有哪些

?1、RMI

利用java.rmi包實現(xiàn)，基于Java遠程方法協(xié)議(JavaRemoteMethodProtocol)和java的原生序列

化。

?2、Hessian

是一個輕量級的remotingonhttp工具，使用簡單的方法提供了RMI的功能?；贖TTP協(xié)議，采

用二進制編解碼。

?3、protobuf-rpc-pro

是一個Java類庫，提供了基于Google的ProtocolBuffers協(xié)議的遠程方法調(diào)用的框架?；?/p>

Netty底層的NI0技術(shù)。支持TCP重用/keep-alive、SSL加密、RPC調(diào)用取消操作、嵌入式日志

等功能。

?4、Thrift

是一種可伸縮的跨語言服務的軟件框架。它擁有功能強大的代碼生成引擎，無縫地支持C++,

C#,Java,Python和PHP和Ruby。thrift允許你定義T?描述文件，描述數(shù)據(jù)類型和服務接口。

依據(jù)該文件，編譯器方便地生成RPC客戶端和服務器通信代碼。

最初由facebook開發(fā)用做系統(tǒng)內(nèi)個語言之間的RPC通信，2007年由facebook貢獻到apache基金，現(xiàn)

在是叩ache下的。pensource之一。支持多種語言之間的RPC方式的通信：php語言client可以構(gòu)造一

個對象，調(diào)用相應的服務方法來調(diào)用java語言的服務，跨越語言的C/SRPC調(diào)用。底層通訊基于

SOCKET.

?5、Avro

出自Hadoop之父DougCutting,在Thrift已經(jīng)相當流行的情況下推出Avr。的目標不僅是提供一套類

似Thrift的通訊中間件，更是要建立一個新的，標準性的云計算的數(shù)據(jù)交換和存儲的Protocol。支持

HTTP,TCP兩種協(xié)議。

?6、Dubbo

Dubb。是阿里巴巴公司開源的一個高性能優(yōu)秀的服務框架，使得應用可通過高性能的RPC實現(xiàn)服

務的輸出和輸入功能，可以和Spring框架無縫集成。

47.RPC的實現(xiàn)原理架構(gòu)圖

服務消防方服務提供方

客戶端線程服務端線程

請求對象響應對象

反

反

序

序

序