隨著服務(wù)化的進(jìn)一步發(fā)展，服務(wù)越來(lái)越多，服務(wù)之間的呼叫與依賴(lài)關(guān)係也越來(lái)越複雜，誕生了服務(wù)導(dǎo)向的架構(gòu)系統(tǒng)(SOA)，也因此衍生出了一系列對(duì)應(yīng)的技術(shù)，如對(duì)服務(wù)提供、服務(wù)呼叫、連接處理、通訊協(xié)定、序列化方式、服務(wù)發(fā)現(xiàn)、服務(wù)路由、日誌輸出等行為進(jìn)行封裝的服務(wù)架構(gòu)。就這樣為分散式系統(tǒng)的服務(wù)治理架構(gòu)就出現(xiàn)了，Dubbo 也就這樣產(chǎn)生了。

2、Dubbo 的整體架構(gòu)設(shè)計(jì)有哪些分層?

介面服務(wù)層（Service）：該層與業(yè)務(wù)邏輯相關(guān)，根據(jù)provider 和consumer 的業(yè)務(wù)設(shè)計(jì)對(duì)應(yīng)的介面和實(shí)作

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

##服務(wù)代理層（Proxy）： 服務(wù)介面透明代理，產(chǎn)生服務(wù)的客戶(hù)端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 呼叫次數(shù)和呼叫時(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)路傳輸層（Transport）：抽象mina 和netty 為統(tǒng)一介面，以Message 為中心，擴(kuò)充介面為Channel、Transporter、Client、Server 和Codec

資料序列化層（Serialize）：可重複使用的一些工具，擴(kuò)充介面為Serialization、ObjectInput、ObjectOutput 和ThreadPool

3、預(yù)設(shè)使用的是什麼通訊框架，還有別的選擇嗎?

預(yù)設(shè)也推薦使用netty 框架，還有mina。

4、服務(wù)呼叫是阻塞的嗎？

預(yù)設(shè)是阻塞的，可以非同步調(diào)用，沒(méi)有回傳值的可以這麼做。 Dubbo 是基於 NIO 的非阻塞實(shí)作並行調(diào)用，客戶(hù)端不需要啟動(dòng)多執(zhí)行緒即可完成並行調(diào)用多個(gè)遠(yuǎn)端服務(wù)，相對(duì)多執(zhí)行緒開(kāi)銷(xiāo)較小，非同步調(diào)用會(huì)傳回一個(gè) Future 物件。

5、一般使用什麼註冊(cè)中心？還有別的選擇嗎？

推薦使用 Zookeeper 作為註冊(cè)中心，還有 Redis、Multicast、Simple 註冊(cè)中心，但不推薦。

6、預(yù)設(shè)使用什麼序列化框架，你知道的還有哪些？

建議使用 Hessian 序列化，還有 Duddo、FastJson、Java 自帶序列化。

7、服務(wù)提供者能實(shí)現(xiàn)失效踢出是什麼原理？

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

8、服務(wù)上線(xiàn)怎麼不影響舊版？

採(cǎi)用多版本開(kāi)發(fā)，不影響舊版。

9、如何解決服務(wù)呼叫鏈過(guò)長(zhǎng)的問(wèn)題？

可以結(jié)合 zipkin 實(shí)現(xiàn)分散式服務(wù)追蹤。

10、說(shuō)說(shuō)核心的配置有哪些？

11、Dubbo 推薦用什麼協(xié)定？

12、同一個(gè)服務(wù)多個(gè)註冊(cè)的情況下可以直接連某一個(gè)服務(wù)嗎？

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

（更多相關(guān)面試題推薦：java面試題目及答案）

#13、畫(huà)一畫(huà)服務(wù)註冊(cè)與發(fā)現(xiàn)的流程圖？

14、Dubbo 叢集容錯(cuò)有幾種方案？

15、Dubbo 服務(wù)降級(jí)，失敗重試怎麼做？

可以透過(guò) dubbo:reference 中設(shè)定 mock="return null"。 mock 的值也可以修改為 true，然後再跟介面同一個(gè)路徑下實(shí)作一個(gè) Mock 類(lèi)，命名規(guī)則是 “介面名稱(chēng) Mock” 字尾。然後在 Mock 類(lèi)別裡實(shí)作自己的降級(jí)邏輯

16、Dubbo 使用過(guò)程中都遇到了什麼問(wèn)題？

在註冊(cè)中心找不到對(duì)應(yīng)的服務(wù),檢查service 實(shí)現(xiàn)類(lèi)別是否新增了@service 註解無(wú)法連接到註冊(cè)中心,檢查設(shè)定檔中的對(duì)應(yīng)的測(cè)試ip 是否正確

17 、Dubbo Monitor 實(shí)作原理？

Consumer 端在發(fā)起呼叫之前會(huì)先走 filter 鏈；provider 端在接收到請(qǐng)求時(shí)也是先走 filter 鏈，然後才進(jìn)行真正的業(yè)務(wù)邏輯處理。預(yù)設(shè)情況下，在 consumer 和 provider 的 filter 鏈中都會(huì)有 Monitorfilter。

1、MonitorFilter 傳送資料至DubboMonitor ?

2、DubboMonitor 將資料聚合後（預(yù)設(shè)聚合1min 中的統(tǒng)計(jì)資料）暫存到ConcurrentMap statisticsMap，然後使用一個(gè)含有3 個(gè)線(xiàn)程（線(xiàn)程名字：DubboMonitorSendTimer）的線(xiàn)程池每隔1min 鐘，調(diào)用SimpleMonitorService 遍歷發(fā)送statisticsMap 中的統(tǒng)計(jì)數(shù)據(jù)，每發(fā)送完畢一個(gè)，就重置當(dāng)前的Statistics 的AtomicReference?

#3、SimpleMonitorService將這些聚合資料塞入BlockingQueue queue 中（隊(duì)列大寫(xiě)為100000）?

4、SimpleMonitorService 使用一個(gè)後臺(tái)執(zhí)行緒（執(zhí)行緒名為：DubboMonitorAsyncWriteLogThread）將queue 中的資料寫(xiě)入檔案（該執(zhí)行緒以死的循環(huán)形式來(lái)寫(xiě)）?

5、SimpleMonitorService 也會(huì)使用一個(gè)含有1 個(gè)執(zhí)行緒（執(zhí)行緒名字：DubboMonitorTimer）的執(zhí)行緒池每隔5min 鐘，將檔案中的統(tǒng)計(jì)資料畫(huà)成圖表

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

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

工廠(chǎng)模式

Provider 在 export 服務(wù)時(shí)，會(huì)呼叫 ServiceConfig 的 export 方法。 ServiceConfig中有個(gè)欄位：

private?static?final?Protocol?protocol?=
ExtensionLoader.getExtensionLoader(Protocol.class).getAdaptiveExtensi
on();

Dubbo 裡有很多這種程式碼。這也是一種工廠(chǎng)模式，只是實(shí)作類(lèi)別的取得採(cǎi)用了 JDKSPI 的機(jī)制。這麼實(shí)現(xiàn)的優(yōu)點(diǎn)是可擴(kuò)充性強(qiáng)，想要擴(kuò)充實(shí)現(xiàn)，只要在 classpath下增加個(gè)檔案就可以了，程式碼零侵入。另外，像上面的 Adaptive 實(shí)現(xiàn)，可以做到呼叫時(shí)動(dòng)態(tài)決定調(diào)用哪個(gè)實(shí)現(xiàn)，但是由於這種實(shí)現(xiàn)採(cǎi)用了動(dòng)態(tài)代理，會(huì)造成代碼調(diào)試比較麻煩，需要分析出實(shí)際調(diào)用的實(shí)現(xiàn)類(lèi)。

裝飾器模式

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

EchoFilter?->?ClassLoaderFilter?->?GenericFilter?->?ContextFilter?->
ExecuteLimitFilter?->?TraceFilter?->?TimeoutFilter?->?MonitorFilter?->
ExceptionFilter

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

?觀(guān)察者模式

Dubbo 的 Provider 啟動(dòng)時(shí)，需要與注冊(cè)中心交互，先注冊(cè)自己的服務(wù)，再訂閱自己的服務(wù)，訂閱時(shí)，采用了觀(guān)察者模式，開(kāi)啟一個(gè) listener。注冊(cè)中心會(huì)每 5 秒定時(shí)檢查是否有服務(wù)更新，如果有更新，向該服務(wù)的提供者發(fā)送一個(gè) notify 消息，provider 接受到 notify 消息后，運(yùn)行 NotifyListener 的 notify 方法，執(zhí)行監(jiān)聽(tīng)器方法。

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

Dubbo 擴(kuò)展 JDK SPI 的類(lèi) ExtensionLoader 的 Adaptive 實(shí)現(xiàn)是典型的動(dòng)態(tài)代理實(shí)現(xiàn)。Dubbo 需要靈活地控制實(shí)現(xiàn)類(lèi)，即在調(diào)用階段動(dòng)態(tài)地根據(jù)參數(shù)決定調(diào)用哪個(gè)實(shí)現(xiàn)類(lèi)，所以采用先生成代理類(lèi)的方法，能夠做到靈活的調(diào)用。生成代理類(lèi)的代碼是 ExtensionLoader 的 createAdaptiveExtensionClassCode 方法。代理類(lèi)主要邏輯是，獲取 URL 參數(shù)中指定參數(shù)的值作為獲取實(shí)現(xiàn)類(lèi)的 key。

19、Dubbo 配置文件是如何加載到 Spring 中的？

Spring 容器在啟動(dòng)的時(shí)候，會(huì)讀取到 Spring 默認(rèn)的一些 schema 以及 Dubbo 自定義的 schema，每個(gè) schema 都會(huì)對(duì)應(yīng)一個(gè)自己的 NamespaceHandler，NamespaceHandler 里面通過(guò) BeanDefinitionParser 來(lái)解析配置信息并轉(zhuǎn)化為需要加載的 bean 對(duì)象！

20、Dubbo SPI 和 Java SPI 區(qū)別？

JDK SPI：

JDK 標(biāo)準(zhǔn)的 SPI 會(huì)一次性加載所有的擴(kuò)展實(shí)現(xiàn)，如果有的擴(kuò)展吃實(shí)話(huà)很耗時(shí)，但也沒(méi)用上，很浪費(fèi)資源。所以只希望加載某個(gè)的實(shí)現(xiàn)，就不現(xiàn)實(shí)了

?DUBBO SPI：

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)支持 Spring Bean。

21、Dubbo 支持分布式事務(wù)嗎？

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

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

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

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

為了提高數(shù)據(jù)訪(fǎng)問(wèn)的速度。Dubbo 提供了聲明式緩存，以減少用戶(hù)加緩存的工作量

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

23、服務(wù)上線(xiàn)怎么兼容舊版本？

可以用版本號(hào)（version）過(guò)渡，多個(gè)不同版本的服務(wù)注冊(cè)到注冊(cè)中心，版本號(hào)不同的服務(wù)相互間不引用。這個(gè)和服務(wù)分組的概念有一點(diǎn)類(lèi)似。

24、Dubbo 必須依賴(lài)的包有哪些？

Dubbo 必須依賴(lài) JDK，其他為可選。

25、Dubbo telnet 命令能做什么？

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

連接服務(wù)

telnet localhost 20880 //鍵入回車(chē)進(jìn)入 Dubbo 命令模式。

查看服務(wù)列表

dubbo>ls
com.test.TestService
dubbo>ls?com.test.TestService
create
delete
query

· ls (list services and methods)

· ls : 顯示服務(wù)列表。

· ls -l : 顯示服務(wù)詳細(xì)信息列表。

· ls XxxService：顯示服務(wù)的方法列表。

· ls -l XxxService：顯示服務(wù)的方法詳細(xì)資訊清單。

26、Dubbo 支援服務(wù)降級(jí)嗎？

以透過(guò) dubbo:reference 中設(shè)定 mock="return null"。 mock 的值也可以修改為 true，然後再跟介面同一個(gè)路徑下實(shí)作一個(gè) Mock 類(lèi)，命名規(guī)則是 “介面名稱(chēng) Mock” 字尾。然後在 Mock 類(lèi)別中實(shí)作自己的降級(jí)邏輯

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

Dubbo 是透過(guò) JDK 的 ShutdownHook 來(lái)完成優(yōu)雅停機(jī)的，所以如果使用kill -9 PID 等強(qiáng)制關(guān)閉指令，是不會(huì)執(zhí)行優(yōu)雅停機(jī)的，只有透過(guò) kill PID 時(shí)，才會(huì)執(zhí)行。

28、Dubbo 和 Dubbox 之間的差異？

Dubbox 是繼 Dubbo 停止維護(hù)後，當(dāng)網(wǎng)基於 Dubbo 做的一個(gè)擴(kuò)展項(xiàng)目，如加了服務(wù)可 Restful 調(diào)用，更新了開(kāi)源組件等。

29、Dubbo 和 Spring Cloud 的差別？

根據(jù)微服務(wù)架構(gòu)在各方面的要素，看看 Spring Cloud 和 Dubbo 都提供了哪些支援。

使用Dubbo 建構(gòu)的微服務(wù)架構(gòu)就像組裝電腦，各環(huán)節(jié)我們的選擇自由度很高，但是最終結(jié)果很有可能因?yàn)橐粭l記憶體品質(zhì)不行就點(diǎn)不亮了，總是讓人不怎麼放心，但是如果你是一名高手，那這些都不是問(wèn)題；而Spring Cloud 就像品牌機(jī)，在Spring Source 的整合下，做了大量的兼容性測(cè)試，保證了機(jī)器擁有更高的穩(wěn)定性，但是如果要在使用非原廠(chǎng)組件外的東西，就需要對(duì)其基礎(chǔ)有足夠的了解。

30、你還了解別的分散式框架嗎？

別的還有spring 的spring cloud，facebook 的thrift，twitter 的finagle 等

3.Spring Cloud 與Dubbo 區(qū)別

##分散式設(shè)定無(wú)Spring Cloud Config服務(wù)追蹤無(wú)Spring Cloud Sleuth訊息匯流排無(wú)Spring Cloud Bus

#?	Dubbo	#Spring Cloud
##服務(wù)註冊(cè)中心	Zookeeper	Spring Cloud Netflix Eureka
服務(wù)調(diào)用方式	RPC	REST API
服務(wù)監(jiān)控	Dubbo-monitor	Spring Boot Admin
斷路器	不完善	Spring Cloud Netflix Hystrix
服務(wù)網(wǎng)關(guān)	無(wú)	Spring Cloud Netflix Zuul





無(wú)	Spring Cloud Stream

##################################################### ###無(wú)############Spring Cloud Task############################################################################################ #####......############......###################最大的差異:Spring Cloud拋棄了Dubbo 的RPC通信，採(cǎi)用的是基於HTTP的REST方式。嚴(yán)格來(lái)說(shuō)，這兩種方式各有優(yōu)劣。雖然在某種程度上來(lái)說(shuō)，後者犧牲了服務(wù)呼叫的效能，但也避免了上述的原生RPC所帶來(lái)的問(wèn)題。而REST相比RPC更為靈活，服務(wù)提供者和呼叫方的依賴(lài)只依賴(lài)一紙契約，不存在程式碼層級(jí)的強(qiáng)依賴(lài)，這在強(qiáng)調(diào)快速演化的微服務(wù)環(huán)境下，顯得更為合適。 ######4.另一個(gè)微服務(wù)框架SpringCloud######請(qǐng)翻閱往期：######SpringCloud元件原理:Eureka，F(xiàn)eign，Ribbon，Hystrix，Zuul##### #相關(guān)推薦：###java入門(mén)#######

以上是Java面試題－Dubbo的詳細(xì)內(nèi)容。更多資訊請(qǐng)關(guān)注PHP中文網(wǎng)其他相關(guān)文章！

本網(wǎng)站聲明

本文內(nèi)容由網(wǎng)友自願(yuàn)投稿，版權(quán)歸原作者所有。本站不承擔(dān)相應(yīng)的法律責(zé)任。如發(fā)現(xiàn)涉嫌抄襲或侵權(quán)的內(nèi)容，請(qǐng)聯(lián)絡(luò)admin@php.cn