Dubbo面試題及答案

Dubbo面試題及答案1.Dubbo和SpringCloud有什么區(qū)別？對(duì)(正確答案)錯(cuò)答案解析：兩個(gè)沒關(guān)聯(lián)，如果硬要說區(qū)別，有以下幾點(diǎn)。

1）通信方式不同

Dubbo使用的是RPC通信，而SpringCloud使用的是HTTPRESTFul方式。

2）組成部分不同

2.dubbo都支持什么協(xié)議，推薦用哪種？

對(duì)(正確答案)錯(cuò)答案解析：dubbo://（推薦）

rmi://

hessian://

http://

webservice://

thrift://

memcached://

redis://

rest://3.Dubbo需要Web容器嗎？對(duì)(正確答案)錯(cuò)答案解析：不需要，如果硬要用Web容器，只會(huì)增加復(fù)雜性，也浪費(fèi)資源。4.Dubbo內(nèi)置了哪幾種服務(wù)容器？對(duì)(正確答案)錯(cuò)答案解析：SpringContainer

JettyContainer

Log4jContainer

Dubbo的服務(wù)容器只是一個(gè)簡單的Main方法，并加載一個(gè)簡單的Spring容器，用于暴露服務(wù)。5.Dubbo里面有哪幾種節(jié)點(diǎn)角色？對(duì)(正確答案)錯(cuò)答案解析：6.畫一畫服務(wù)注冊(cè)與發(fā)現(xiàn)的流程圖對(duì)(正確答案)錯(cuò)答案解析：7.Dubbo默認(rèn)使用什么注冊(cè)中心，還有別的選擇嗎？對(duì)(正確答案)錯(cuò)答案解析：推薦使用Zookeeper作為注冊(cè)中心，還有Redis、Multicast、Simple注冊(cè)中心，但不推薦。8.Dubbo有哪幾種配置方式？對(duì)(正確答案)錯(cuò)答案解析：

1）Spring配置方式

2）JavaAPI配置方式9.Dubbo核心的配置有哪些？對(duì)(正確答案)錯(cuò)答案解析：

配置之間的關(guān)系見下圖。

10.在Provider上可以配置的Consumer端的屬性有哪些？對(duì)(正確答案)錯(cuò)答案解析：1）timeout：方法調(diào)用超時(shí)

2）retries：失敗重試次數(shù)，默認(rèn)重試2次

3）loadbalance：負(fù)載均衡算法，默認(rèn)隨機(jī)

4）actives消費(fèi)者端，最大并發(fā)調(diào)用限制11.Dubbo啟動(dòng)時(shí)如果依賴的服務(wù)不可用會(huì)怎樣？對(duì)(正確答案)錯(cuò)答案解析：Dubbo缺省會(huì)在啟動(dòng)時(shí)檢查依賴的服務(wù)是否可用，不可用時(shí)會(huì)拋出異常，阻止Spring初始化完成，默認(rèn)check="true"，可以通過check="false"關(guān)閉檢查。12.Dubbo推薦使用什么序列化框架，你知道的還有哪些？對(duì)(正確答案)錯(cuò)答案解析：推薦使用Hessian序列化，還有Duddo、FastJson、Java自帶序列化。13.Dubbo默認(rèn)使用的是什么通信框架，還有別的選擇嗎？對(duì)(正確答案)錯(cuò)答案解析：Dubbo默認(rèn)使用Netty框架，也是推薦的選擇，另外內(nèi)容還集成有Mina、Grizzly。14.Dubbo有哪幾種集群容錯(cuò)方案，默認(rèn)是哪種？對(duì)(正確答案)錯(cuò)答案解析：15.Dubbo有哪幾種負(fù)載均衡策略，默認(rèn)是哪種？對(duì)(正確答案)錯(cuò)答案解析：16.注冊(cè)了多個(gè)同一樣的服務(wù)，如果測(cè)試指定的某一個(gè)服務(wù)呢？對(duì)(正確答案)錯(cuò)答案解析：可以配置環(huán)境點(diǎn)對(duì)點(diǎn)直連，繞過注冊(cè)中心，將以服務(wù)接口為單位，忽略注冊(cè)中心的提供者列表。17.Dubbo支持服務(wù)多協(xié)議嗎？對(duì)(正確答案)錯(cuò)答案解析：Dubbo允許配置多協(xié)議，在不同服務(wù)上支持不同協(xié)議或者同一服務(wù)上同時(shí)支持多種協(xié)議。18.當(dāng)一個(gè)服務(wù)接口有多種實(shí)現(xiàn)時(shí)怎么做？對(duì)(正確答案)錯(cuò)答案解析：當(dāng)一個(gè)接口有多種實(shí)現(xiàn)時(shí)，可以用group屬性來分組，服務(wù)提供方和消費(fèi)方都指定同一個(gè)group即可。19.服務(wù)上線怎么兼容舊版本？對(duì)(正確答案)錯(cuò)答案解析：可以用版本號(hào)（version）過渡，多個(gè)不同版本的服務(wù)注冊(cè)到注冊(cè)中心，版本號(hào)不同的服務(wù)相互間不引用。這個(gè)和服務(wù)分組的概念有一點(diǎn)類似。20.Dubbo可以對(duì)結(jié)果進(jìn)行緩存嗎？對(duì)(正確答案)錯(cuò)答案解析：為了提高數(shù)據(jù)訪問的速度。Dubbo提供了聲明式緩存，以減少用戶加緩存的工作量<dubbo:referencecache=“true”/>

其實(shí)比普通的配置文件就多了一個(gè)標(biāo)簽cache=“true”21.Dubbo服務(wù)之間的調(diào)用是阻塞的嗎？對(duì)(正確答案)錯(cuò)答案解析：默認(rèn)是同步等待結(jié)果阻塞的，支持異步調(diào)用。

Dubbo是基于NIO的非阻塞實(shí)現(xiàn)并行調(diào)用，客戶端不需要啟動(dòng)多線程即可完成并行調(diào)用多個(gè)遠(yuǎn)程服務(wù)，相對(duì)多線程開銷較小，異步調(diào)用會(huì)返回一個(gè)Future對(duì)象。

異步調(diào)用流程圖如下。

22.Dubbo支持分布式事務(wù)嗎？對(duì)(正確答案)錯(cuò)答案解析：目前暫時(shí)不支持，后續(xù)可能采用基于JTA/XA規(guī)范實(shí)現(xiàn)，如以圖所示。

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

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

TCC-Transaction通過Dubbo隱式傳參的功能，避免自己對(duì)業(yè)務(wù)代碼的入侵。23.Dubbotelnet命令能做什么？對(duì)(正確答案)錯(cuò)答案解析：dubbo通過telnet命令來進(jìn)行服務(wù)治理，具體使用看這篇文章《dubbo服務(wù)調(diào)試管理實(shí)用命令》。

telnetlocalhost8090

Dubbo2.0.5以上版本服務(wù)提供端口支持telnet命令24.Dubbo支持服務(wù)降級(jí)嗎？對(duì)(正確答案)錯(cuò)答案解析：Dubbo2.2.0以上版本支持。

可以通過dubbo:reference中設(shè)置mock=“returnnull”。mock的值也可以修改為true，然后再跟接口同一個(gè)路徑下實(shí)現(xiàn)一個(gè)Mock類，命名規(guī)則是“接口名稱+Mock”后綴。然后在Mock類里實(shí)現(xiàn)自己的降級(jí)邏輯25.Dubbo如何優(yōu)雅停機(jī)？對(duì)(正確答案)錯(cuò)答案解析：Dubbo是通過JDK的ShutdownHook來完成優(yōu)雅停機(jī)的，所以如果使用kill-9PID等強(qiáng)制關(guān)閉指令，是不會(huì)執(zhí)行優(yōu)雅停機(jī)的，只有通過killPID時(shí)，才會(huì)執(zhí)行。26.服務(wù)提供者能實(shí)現(xiàn)失效踢出是什么原理？對(duì)(正確答案)錯(cuò)答案解析：服務(wù)失效踢出基于Zookeeper的臨時(shí)節(jié)點(diǎn)原理。27.如何解決服務(wù)調(diào)用鏈過長的問題？對(duì)(正確答案)錯(cuò)答案解析：Dubbo可以使用Pinpoint和ApacheSkywalking(Incubator)實(shí)現(xiàn)分布式服務(wù)追蹤，當(dāng)然還有其他很多方案。28.服務(wù)讀寫推薦的容錯(cuò)策略是怎樣的？對(duì)(正確答案)錯(cuò)答案解析：讀操作建議使用Failover失敗自動(dòng)切換，默認(rèn)重試兩次其他服務(wù)器。

寫操作建議使用Failfast快速失敗，發(fā)一次調(diào)用失敗就立即報(bào)錯(cuò)。29.Dubbo必須依賴的包有哪些？對(duì)(正確答案)錯(cuò)答案解析：Dubbo必須依賴JDK，其他為可選。30.Dubbo的管理控制臺(tái)能做什么？對(duì)(正確答案)錯(cuò)答案解析：管理控制臺(tái)主要包含：路由規(guī)則，動(dòng)態(tài)配置，服務(wù)降級(jí)，訪問控制，權(quán)重調(diào)整，負(fù)載均衡，等管理功能。31.說說Dubbo服務(wù)暴露的過程。對(duì)(正確答案)錯(cuò)答案解析：Dubbo會(huì)在Spring實(shí)例化完bean之后，在刷新容器最后一步發(fā)布ContextRefreshEvent事件的時(shí)候，通知實(shí)現(xiàn)了ApplicationListener的ServiceBean類進(jìn)行回調(diào)onApplicationEvent事件方法，Dubbo會(huì)在這個(gè)方法中調(diào)用ServiceBean父類ServiceConfig的export方法，而該方法真正實(shí)現(xiàn)了服務(wù)的（異步或者非異步）發(fā)布。

Dubbo處理服務(wù)暴露的關(guān)鍵就在Invoker轉(zhuǎn)換到Exporter的過程

服務(wù)發(fā)布過程的一些動(dòng)作

暴露本地服務(wù)

暴露遠(yuǎn)程服務(wù)

啟動(dòng)netty

連接zookeeper

到zookeeper注冊(cè)

監(jiān)聽zookeeper

一句話概括服務(wù)暴露：

Service->Invoker->Exporter

32.Dubbo停止維護(hù)了嗎？對(duì)(正確答案)錯(cuò)答案解析：2014年開始停止維護(hù)過幾年，17年開始重新維護(hù)，并進(jìn)入了Apache項(xiàng)目。33.Dubbo和Dubbox有什么區(qū)別？對(duì)(正確答案)錯(cuò)答案解析：Dubbox是繼Dubbo停止維護(hù)后，當(dāng)當(dāng)網(wǎng)基于Dubbo做的一個(gè)擴(kuò)展項(xiàng)目，如加了服務(wù)可Restful調(diào)用，更新了開源組件等。34.在使用過程中都遇到了些什么問題？對(duì)(正確答案)錯(cuò)答案解析：1、Dubbo的設(shè)計(jì)目的是為了滿足高并發(fā)小數(shù)據(jù)量的rpc調(diào)用，在大數(shù)據(jù)量下的性能表現(xiàn)并不好，建議使用rmi或http協(xié)議。

2、在注冊(cè)中心找不到對(duì)應(yīng)的服務(wù),檢查service實(shí)現(xiàn)類是否添加了@service注解無法連接到注冊(cè)中心,檢查配置文件中的對(duì)應(yīng)的測(cè)試ip是否正確35.你讀過Dubbo的源碼嗎？對(duì)(正確答案)錯(cuò)答案解析：要了解Dubbo就必須看其源碼，了解其原理，花點(diǎn)時(shí)間看下吧，網(wǎng)上也有很多教程，后續(xù)有時(shí)間我也會(huì)在公眾號(hào)上分享Dubbo的源碼。36.你覺得用Dubbo好還是SpringCloud好？對(duì)(正確答案)錯(cuò)答案解析：擴(kuò)展性的問題，沒有好壞，只有適合不適合，不過我好像更傾向于使用Dubbo,SpringCloud版本升級(jí)太快，組件更新替換太頻繁，配置太繁瑣，還有很多我覺得是沒有Dubbo順手的地方……37.Dubbo的整體架構(gòu)設(shè)計(jì)有哪些分層?對(duì)(正確答案)錯(cuò)答案解析：

接口服務(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ò)展接口為Protocal、Invoker和Exporter

信息交換層（Exchange）：封裝請(qǐng)求響應(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和ThreadPool38.DubboMonitor實(shí)現(xiàn)原理？對(duì)(正確答案)錯(cuò)答案解析：Consumer端在發(fā)起調(diào)用之前會(huì)先走filter鏈；provider端在接收到請(qǐng)求時(shí)也是先走filter鏈，然后才進(jìn)行真正的業(yè)務(wù)邏輯處理。默認(rèn)情況下，在consumer和provider的filter鏈中都會(huì)有Monitorfilter。

1、MonitorFilter向DubboMonitor發(fā)送數(shù)據(jù)

2、DubboMonitor將數(shù)據(jù)進(jìn)行聚合后（默認(rèn)聚合1min中的統(tǒng)計(jì)數(shù)據(jù)）暫存到ConcurrentMap<Statistics,AtomicReference>statisticsMap，然后使用一個(gè)含有3個(gè)線程（線程名字：DubboMonitorSendTimer）的線程池每隔1min鐘，調(diào)用SimpleMonitorService遍歷發(fā)送statisticsMap中的統(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ù)畫成圖表39.Dubbo的注冊(cè)中心集群掛掉，發(fā)布者和訂閱者之間還能通信么？

對(duì)(正確答案)錯(cuò)答案解析：可以通訊。啟動(dòng)Dubbo時(shí)，消費(fèi)者會(huì)從Zookeeper拉取注冊(cè)的生產(chǎn)者的地址接口等數(shù)據(jù)，緩存在本地。每次調(diào)用時(shí)，按照本地存儲(chǔ)的地址進(jìn)行調(diào)用。40.Dubbo配置文件是如何加載到Spring中的？對(duì)(正確答案)錯(cuò)答案解析：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ì)象！41.Dubbo超時(shí)設(shè)置有哪些方式？對(duì)(正確答案)錯(cuò)答案解析：Dubbo超時(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)生警告。42.服務(wù)調(diào)用超時(shí)會(huì)怎么樣？對(duì)(正確答案)錯(cuò)答案解析：dubbo在調(diào)用服務(wù)不成功時(shí)，默認(rèn)是會(huì)重試兩次。43.Dubbo使用的是什么通信框架?對(duì)(正確答案)錯(cuò)答案解析：默認(rèn)使用Netty作為通訊框架。44.Dubbo支持哪些協(xié)議，它們的優(yōu)缺點(diǎn)有哪些？對(duì)(正確答案)錯(cuò)答案解析：Dubbo：單一長連接和NIO異步通訊，適合大并發(fā)小數(shù)據(jù)量的服務(wù)調(diào)用，以及消費(fèi)者遠(yuǎn)大于提供者。傳輸協(xié)議TCP，異步Hessian序列化。Dubbo推薦使用dubbo協(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的HttpInvoke實(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é)議。45.Dubbo用到哪些設(shè)計(jì)模式？對(duì)(正確答案)錯(cuò)答案解析：工廠模式

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

privatestaticfinalProtocolprotocol=

ExtensionLoader.getExtensionLoader(Protocol.class).getAdaptiveExtensi

on（）;

Dubbo里有很多這種代碼。這也是一種工廠模式，只是實(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)類。

裝飾器模式

Dubbo在啟動(dòng)和調(diào)用階段都大量使用了裝飾器模式。以Provider提供的調(diào)用鏈為例，具體的調(diào)用鏈代碼是在ProtocolFilterWrapper的buildInvokerChain完成的，具體是將注解中含有g(shù)roup=provider的Filter實(shí)現(xiàn)，按照order排序，最后的調(diào)用順序是：

EchoFilter->ClassLoaderFilter->GenericFilter->ContextFilter->

ExecuteLimitFilter->TraceFilter->TimeoutFilter->MonitorFilter->

ExceptionFilter

更確切地說，這里是裝飾器和責(zé)任鏈模式的混合使用。例如，EchoFilter的作用是判斷是否是回聲測(cè)試請(qǐng)求，是的話直接返回內(nèi)容，這是一種責(zé)任鏈的體現(xiàn)。而像ClassLoaderFilter則只是在主功能上添加了功能，更改當(dāng)前線程的ClassLoader，這是典型的裝飾器模式。

觀察者模式

Dubbo的Provider啟動(dòng)時(shí)，需要與注冊(cè)中心交互，先注冊(cè)自己的服務(wù)，再訂閱自己的服務(wù)，訂閱時(shí)，采用了觀察者模式，開啟一個(gè)listener。注冊(cè)中心會(huì)每5秒定時(shí)檢查是否有服務(wù)更新，如果有更新，向該服務(wù)的提供者發(fā)送一個(gè)notify消息，provider接受到notify消息后，運(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。46.DubboSPI和JavaSPI區(qū)別？對(duì)(正確答案)錯(cuò)答案解析：什么是SPI?

SPI機(jī)制（ServiceProviderInterface)其實(shí)源自服務(wù)提供者框架（ServiceProviderFramework，參考【EffectiveJava】page6)，是一種將服務(wù)接口與服務(wù)實(shí)現(xiàn)分離以達(dá)到解耦、大大提升了程序可擴(kuò)展性的機(jī)制。引入服務(wù)提供者就是引入了spi接口的實(shí)現(xiàn)者，通過本地的注冊(cè)發(fā)現(xiàn)獲取到具體的實(shí)現(xiàn)類，輕松可插拔

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ì)Dubbo進(jìn)行擴(kuò)展，不需要改動(dòng)Dubbo的源碼

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

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

4、Dubbo的擴(kuò)展機(jī)制能很好的支持第三方IoC容器，默認(rèn)支持SpringBean。47.Dubbo在安全方面有哪些措施？對(duì)(正確答案)錯(cuò)答案解析：Dubbo通過Token令牌防止用戶繞過注冊(cè)中心直連，然后在注冊(cè)中心上管理授權(quán)。

Dubbo還提供服務(wù)黑白名單，來控制服務(wù)所允許的調(diào)用方。48.什么是RPC對(duì)(正確答案)錯(cuò)答案解析：RPC（RemoteProcedureCallProtocol）遠(yuǎn)程過程調(diào)用協(xié)議，它是一種通過網(wǎng)絡(luò)從遠(yuǎn)程計(jì)算機(jī)程序上請(qǐng)求服務(wù)，而不需要了解底層網(wǎng)絡(luò)技術(shù)的協(xié)議。簡言之，RPC使得程序能夠像訪問本地系統(tǒng)資源一樣，去訪問遠(yuǎn)端系統(tǒng)資源。比較關(guān)鍵的一些方面包括：通訊協(xié)議、序列化、資源（接口）描述、服務(wù)框架、性能、語言支持等。

簡單的說，RPC就是從一臺(tái)機(jī)器(客戶端)上通過參數(shù)傳遞的方式調(diào)用另一臺(tái)機(jī)器(服務(wù)器)上的一個(gè)函數(shù)或方法(可以統(tǒng)稱為服務(wù))并得到返回的結(jié)果。49.為什么要有RPC對(duì)(正確答案)錯(cuò)答案解析：http接口是在接口不多、系統(tǒng)與系統(tǒng)交互較少的情況下，解決信息孤島初期常使用的一種通信手段；優(yōu)點(diǎn)就是簡單、直接、開發(fā)方便。利用現(xiàn)成的http協(xié)議進(jìn)行傳輸。但是如果是一個(gè)大型的網(wǎng)站，內(nèi)部子系統(tǒng)較多、接口非常多的情況下，RPC框架的好處就顯示出來了，首先就是長鏈接，不必每次通信都要像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è)簡單的網(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的IO一般是NIO，即非阻塞IO，在高并發(fā)網(wǎng)站中，RPC的優(yōu)勢(shì)會(huì)很明顯50.RPC架構(gòu)組件對(duì)(正確答案)錯(cuò)答案解析：一個(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)⒌刃畔⑿蛄谢ńM裝）成能夠進(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ù)。51.RPC和SOA、SOAP、REST的區(qū)別對(duì)(正確答案)錯(cuò)答案解析：1、REST

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

2、SOAP

SOAP是一種數(shù)據(jù)交換協(xié)議規(guī)范,是一種輕量的、簡單的、基于XML的協(xié)議的規(guī)范。而SOAP可以看著是一個(gè)重量級(jí)的協(xié)議，基于XML、SOAP在安全方面是通過使用XML-Security和XML-Signature兩個(gè)規(guī)范組成了WS-Security來實(shí)現(xiàn)安全控制的,當(dāng)前已經(jīng)得到了各個(gè)廠商的支持。

它有什么優(yōu)點(diǎ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ù)之間通過簡單、精確定義接口進(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)景。52.RPC框架需要解決的問題？對(duì)(正確答案)錯(cuò)答案解析：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)行序列化和反序列化操作？53.RPC的實(shí)現(xiàn)基礎(chǔ)？對(duì)(正確答案)錯(cuò)答案解析：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)保持的功能；54.RPC使用了哪些關(guān)鍵技術(shù)？對(duì)(正確答案)錯(cuò)答案解析：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等。

3、NIO通信

出于并發(fā)性能的考慮，傳統(tǒng)的阻塞式IO顯然不太合適，因此我們需要異步的IO，即NIO。Java提供了NIO的解決方案，Java7也提供了更優(yōu)秀的NIO.2支持?？梢赃x擇Netty或者M(jìn)INA來解決NIO數(shù)據(jù)傳輸?shù)膯栴}。

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

可選：Redis、Zookeeper、Consul、Etcd。一般使用ZooKeeper提供服務(wù)注冊(cè)與發(fā)現(xiàn)功能，解決單點(diǎn)故障以及分布式部署的問題(注冊(cè)中心)。55.主流RPC框架有哪些對(duì)(正確答案)錯(cuò)答案解析：1、RMI

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

2、Hessian

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

3、protobuf-rpc-pro

是一個(gè)Java類庫，提供了基于Google的ProtocolBuffers協(xié)議的遠(yuǎn)程方法調(diào)用的框架?；贜etty底層的NIO技術(shù)。支持TCP重用/keep-alive、SSL加密、RPC調(diào)用取消操作、嵌入式日志等功能。

4、Thrift

是一種可伸縮的跨語言服務(wù)的軟件框架。它擁有功能強(qiáng)大的代碼生成引擎，無縫地支持C++，C#，Java，Python和PHP和Ruby。thrift允許你定義一個(gè)描述文件，描述數(shù)據(jù)類型和服務(wù)接口。依據(jù)該文件，編譯器方便地生成RPC客戶端和服務(wù)器通信代碼。

最初由facebook開發(fā)用做系統(tǒng)內(nèi)個(gè)語言之間的RPC通信，2007年由facebook貢獻(xiàn)到apache基金，現(xiàn)在是apache下的opensource之一。支持多種語言之間的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)流行的情況下推出Avro的目標(biāo)不僅是提供一套類似Thrift的通訊中間件,更是要建立一個(gè)新的，標(biāo)準(zhǔn)性的云計(jì)算的數(shù)據(jù)交換和存儲(chǔ)的Protocol。支持HTTP，TCP兩種協(xié)議。

6、Dubbo

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