2021Java面試題合集-Dubbo面試題47道

基礎(chǔ)知識(shí)

1.為什么要用Dubb。？

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

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

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

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

2.Dubbo是什么？

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

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

3.Dubbo的使用場(chǎng)景有哪些？

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

入。

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

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

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

4.Dubbo核心功能有哪些？

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

的信息交換方式。

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

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

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

明，使服務(wù)提供方可以平滑增加或減少機(jī)器。

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:暴露服務(wù)的服務(wù)提供方

?Consumer:調(diào)用遠(yuǎn)程服務(wù)消費(fèi)方

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

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

?Container:服務(wù)運(yùn)行容器

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

?服務(wù)容器Container負(fù)責(zé)啟動(dòng)，加載，運(yùn)行服務(wù)提供者。

?服務(wù)提供者Provider在啟動(dòng)時(shí)，向注冊(cè)中心注冊(cè)自己提供的服務(wù)。

?服務(wù)消費(fèi)者Consumer在啟動(dòng)時(shí)，向注冊(cè)中心訂閱自己所需的服務(wù)。

?注冊(cè)中心Registry返回服務(wù)提供者地址列表給消費(fèi)者，如果有變更，注冊(cè)中心將基于長(zhǎng)連接推送變

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

?服務(wù)消費(fèi)者Consumer,從提供者地址列表中，基于軟負(fù)載均衡算法，選一臺(tái)提供者進(jìn)行調(diào)用，如

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

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

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

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

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

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

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

口和實(shí)現(xiàn)

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

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

ServiceProxy為中心，擴(kuò)展接口為ProxyFactory

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

RegistryFactory.Registry.Registryservice

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

擴(kuò)展接口為Cluster、Directory、Router和LoadBlancce

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

MonitorFactory.Monitor和Monitorservice

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

ProtocaLInvoker和Exporter

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

擴(kuò)展接口為Exchanger,ExchangeChannekExchangeclient和Exchangeserver

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

Channel,Transporter.Client,ServerfnCodec

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

Objectoutput和ThreadPool

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

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

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

Monitorfilter。

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

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

然后使用一個(gè)含有個(gè)線程（線

ConcurrentMap<StatisticszAtomicReference>statisticsMap,3

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

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

AtomicReference

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

4.SimpleMonitorService使用一個(gè)后臺(tái)線程（線程名為：DubboMonitorAsyncWriteLogThread）

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

5.SimpleMonitorService還會(huì)使用一個(gè)含有1個(gè)線程（線程名字：DubboMonitorTimer）的線程

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

分布式框架

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

?比較著名的就是SpringCloud。

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

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

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

Spring、SpringBoot的優(yōu)勢(shì)之上，兩個(gè)框架在開始目標(biāo)就不一致，Dubbo定位服務(wù)治理、

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

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

?Dubbo底層是使用Netty這樣的NIO框架，是基于TCP協(xié)議傳輸?shù)?，配合以Hession序列化完

成RPC通信。

?SpringCloud是基于Http協(xié)議Rest接口調(diào)用遠(yuǎn)程過程的通信，相對(duì)來說Http請(qǐng)求會(huì)有更大的報(bào)

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

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

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

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

?Dubbox是繼Dubb。停止維護(hù)后，當(dāng)當(dāng)網(wǎng)基于Dubbo做的一個(gè)擴(kuò)展項(xiàng)目，如加了服務(wù)可Restful

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

注冊(cè)中心

13.Dubbo有哪些注冊(cè)中心?

?Multicast注冊(cè)中心：Multicast注冊(cè)中心不需要任!可中心節(jié)點(diǎn)，只要廣播地址，就能進(jìn)行服務(wù)注冊(cè)

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

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

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

?Redis注冊(cè)中心：基于Redis實(shí)現(xiàn)，采用key/m叩存儲(chǔ)，key存儲(chǔ)服務(wù)名和類型，m叩中key存

儲(chǔ)服務(wù)url,value服務(wù)過期時(shí)間。基于Redis的發(fā)布/訂閱模式通知數(shù)據(jù)變更。

?Simple注冊(cè)中心。

?推薦使用Zookeeper作為注冊(cè)中心

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

么？

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

在本地。每次調(diào)用時(shí)，按照本地存儲(chǔ)的地址進(jìn)行調(diào)用。

集群

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

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

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

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

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

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

器宕機(jī)，可以基于虛擬節(jié)點(diǎn)，分?jǐn)傊疗渌峁┱?，避免引起提供者的劇烈變?dòng)。

默認(rèn)為Random隨機(jī)調(diào)用。

16.Dubbo的集群容錯(cuò)方案有哪些？

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

來更長(zhǎng)延遲。

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

新增記錄。

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

?FallbackCluster:失敗自動(dòng)恢復(fù)，后臺(tái)記錄失敗請(qǐng)求，定時(shí)重發(fā)。通常用于消息通知操作。

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

作，但需要浪費(fèi)更多服務(wù)資源。可通過forks="2”來設(shè)置最大并行數(shù)。

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

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

默認(rèn)的容錯(cuò)方案是Failovercluster.

配置

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

?Spring容器在啟動(dòng)的時(shí)候，會(huì)讀取到Spring默認(rèn)的一些schema以及Dubbo自定義的

schema,每個(gè)schema都會(huì)對(duì)應(yīng)一個(gè)自己的NamespaceHandler,NamespaceHandler里面通

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

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

標(biāo)簽用途解釋

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

vice/置露，一個(gè)服務(wù)也可以注冊(cè)到多個(gè)注冊(cè)中心

dubbo:ref引用配

用于創(chuàng)建一個(gè)遠(yuǎn)程服務(wù)代理，一個(gè)引用可以指向多個(gè)注冊(cè)中心

6renee/置

dubbo:pro協(xié)議配

用于配置提供服務(wù)的協(xié)議信息，協(xié)議由提供方指定，消費(fèi)方被動(dòng)接受

tocol/置

dubbo:叩應(yīng)用配

用于配置當(dāng)前應(yīng)用信息，不管該應(yīng)用是提供者還是消費(fèi)者

plication/置

dubbo:mo模塊配

用于配置當(dāng)前模塊信息，可選

duIe/置

dubbo:reg注冊(cè)中

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

Istry/心配置

dubbo:mo監(jiān)控中

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

nitor/心配置

dubbo:pr。提供方當(dāng)ProtocolConfig和ServiceConfig某屬性沒有配置時(shí)，采用此缺省

video/配置值，可選

dubbo:co消費(fèi)方

當(dāng)ReferenceConfig某屬性沒有配置時(shí)，采用此缺省值，可選

nsumerV配置

dubbo:me方法配

用于ServiceConfig和ReferenceConfig指定方法級(jí)的配置信息

thod/置

dubbo:arg參數(shù)配

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

ument置

如果是SpringBoot項(xiàng)目就只需要注解，或者開Application配置文件?。?！

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

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

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

置，因?yàn)榉?wù)提供者比消費(fèi)者更清楚自己提供的服務(wù)特性。

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

因?yàn)榉?wù)調(diào)用方設(shè)置超時(shí)時(shí)間控制性更靈活。如果消費(fèi)方超時(shí)，服務(wù)端線程不會(huì)定制，會(huì)產(chǎn)生警

告。

20.服務(wù)調(diào)用超時(shí)會(huì)怎么樣？

?dubb。在調(diào)用服務(wù)不成功時(shí)，默認(rèn)是會(huì)重試兩次。

通信協(xié)議

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

?默認(rèn)使用Netty作為通訊框架。

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

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

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

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

用Java標(biāo)準(zhǔn)序列化機(jī)制，使用阻塞式短連接，傳輸數(shù)據(jù)包大小混合，消費(fèi)都口提供者個(gè)數(shù)差不

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

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

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

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

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

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

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

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

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

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

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

設(shè)計(jì)模式

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

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

?工廠模式

Provider在export服務(wù)時(shí)，會(huì)調(diào)用ServiceConfig的export方法。ServiceConfig中有個(gè)字段：

privatestaticfinalProtocolprotocol=

ExtensionLoader.getExtensionLoader(Protocol.class).getAdaptiveExtensi

on();

?工廠模式

Provider在export服務(wù)時(shí)，會(huì)調(diào)用ServiceConfig的export方法。ServiceConfig中有個(gè)字段:

privatestaticfinalProtocolprotocol=

ExtensionLoader.getExtensionLoader(Protocol.class).getAdaptiveExtensi

on();

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

的優(yōu)點(diǎn)是可擴(kuò)展性強(qiáng)，想要擴(kuò)展實(shí)現(xiàn)，只需要在classpath下增加個(gè)文件就可以了，代碼零侵入。另

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

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

?裝飾器模式

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

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

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

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

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

Except!onFiIter

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

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

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

?觀察者模式

Dubb。的Provider啟動(dòng)時(shí)，需要與注冊(cè)中心交互，先注冊(cè)自己的服務(wù)，再訂閱自己的服務(wù)，訂閱

時(shí)，采用了觀察者模式，開啟一個(gè)listener。注冊(cè)中心會(huì)每5秒定時(shí)檢杳是否有服務(wù)更新，如果有

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

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

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

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

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

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

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

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

運(yùn)維管理

24.服務(wù)上線怎么兼容舊版本？

?可以用版本號(hào)（version）過渡，多個(gè)不同版本的服務(wù)注冊(cè)到注冊(cè)中心，版本號(hào)不同的服務(wù)相互間

不引用。這個(gè)和服務(wù)分組的概念有一點(diǎn)類似。

25.Dubbotelnet命令能做什么？

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

供端口支持telnet命令

26.Dubbo支持服務(wù)降級(jí)嗎？

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

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

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

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

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

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

SPI

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

?JDKSPI：

JDK標(biāo)準(zhǔn)的SPI會(huì)一次性加載所有的擴(kuò)展實(shí)現(xiàn)，如果有的擴(kuò)展很耗時(shí)，但也沒用上，很浪費(fèi)資源。

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

?DUBBOSPI:

1、對(duì)Dubb。進(jìn)行擴(kuò)展，不需要改動(dòng)Dubb。的源碼

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

3、增加了對(duì)擴(kuò)展點(diǎn)IOC和AOP的支持，一個(gè)擴(kuò)展點(diǎn)可以直接setter注入其它擴(kuò)展點(diǎn)。

4、Dubb。的擴(kuò)展機(jī)制能很好的支持第三方loC容器，默認(rèn)支持SpringBean。

其他

29.Dubbo支持分布式事務(wù)嗎？

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

?介紹：tcc-transaction是開源的TCC補(bǔ)償性分布式事務(wù)框架

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

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

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

<dubbo:referencecache=Mtrue,//>

?其實(shí)比普通的配置文件就多了一個(gè)標(biāo)簽cache=〃true〃

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

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

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

?默認(rèn)使用Hessian序列化，還有Duddo、Fastjson、Java自帶序列化。

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

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

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

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

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

調(diào)用，客戶端不需要啟動(dòng)多線程即可完成并行調(diào)用多個(gè)遠(yuǎn)程服務(wù)，相對(duì)多線程開銷較小，異步調(diào)用

會(huì)返回一個(gè)Future對(duì)象。

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

?服務(wù)失效踢出基于zookeeper的臨時(shí)節(jié)點(diǎn)原理。

36.同一個(gè)服務(wù)多個(gè)注冊(cè)的情況下可以直連某一個(gè)服務(wù)嗎?

?可以點(diǎn)對(duì)點(diǎn)直連，修改配置即可，也可以通過telnet直接某個(gè)服務(wù)。

37.Dubbo服務(wù)降級(jí)，失敗重試怎么做?

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

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

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

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

?在注冊(cè)中心找不到對(duì)應(yīng)的服務(wù)，檢查service實(shí)現(xiàn)類是否添加了@service注解無法連接到注冊(cè)中心,

檢查配置文件中的對(duì)應(yīng)的測(cè)試ip是否正確

RPC

39.為什么要有RPC

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

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

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

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

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

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

的支撐。

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

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

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

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

40.什么是RPC

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

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

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

述、服務(wù)框架、性能、語言支持等。

［注冊(cè)中心

?簡(jiǎn)單的說，RPC就是從一臺(tái)機(jī)器（客戶端）上通過參數(shù)傳遞的方式調(diào)用另一臺(tái)機(jī)器（服務(wù)器）上的一個(gè)

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

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

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

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

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

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

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

務(wù)進(jìn)行處理4、服務(wù)端(Server):服務(wù)的真正提供者

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

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

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

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

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

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

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

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

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

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

9、服務(wù)消費(fèi)方得到最終結(jié)果；

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

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

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

?1、REST

可以看著是HTTP協(xié)議的一種直接應(yīng)用，默認(rèn)基于JSON作為傳輸格式，使用簡(jiǎn)單,學(xué)習(xí)成本低效率高，

但是安全性較低。

?2、SOAP

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

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

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

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

?3、SOA

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

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

性。

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

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

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

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

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

點(diǎn)所帶來的不同應(yīng)用場(chǎng)景。

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

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

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

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

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

?5、如何更高效地對(duì)請(qǐng)求對(duì)象和響應(yīng)結(jié)果進(jìn)行序列依口反序列化操作?

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

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

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

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

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

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

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

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

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

?2、序列化和反序列化

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

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

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

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

架：如Kryo、Fastjson和Protobuf等。

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

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

?3、NIO通信

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

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

傳輸?shù)膯栴}。

?4、服務(wù)注冊(cè)中心

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

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

46.主流RPC框架有哪些

?1、RMI

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

化。

?2、Hessian

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

用二進(jìn)制編解碼。

?3、protobuf-rpc-pro

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

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

等功能。

?4、Thrift

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

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

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

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

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

個(gè)對(duì)象，調(diào)用相應(yīng)的服務(wù)方法來調(diào)用java語言的服務(wù)，跨越語言的C/SRPC調(diào)用。底層通訊基于

SOCKET.

?5、Avro

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

似Thrift的通訊中間件，更是要建立一個(gè)新的，標(biāo)準(zhǔn)性的云計(jì)算的數(shù)據(jù)交換和存儲(chǔ)的Protocol。支持

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

?6、Dubbo

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

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

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

服務(wù)消防方服務(wù)提供方

客戶端線程服務(wù)端線程

請(qǐng)求對(duì)象響應(yīng)對(duì)象

反

反

序

序

序