隨著服務(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 的整體架構(gòu)設(shè)計(jì)有哪些分層?

接口服務(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 和 ThreadPool

3、默認(rèn)使用的是什么通信框架，還有別的選擇嗎?

默認(rèn)也推薦使用 netty 框架，還有 mina。

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

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

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

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

6、默認(rèn)使用什么序列化框架，你知道的還有哪些？

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

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

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

8、服務(wù)上線怎么不影響舊版本？

采用多版本開發(fā)，不影響舊版本。

9、如何解決服務(wù)調(diào)用鏈過長的問題？

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

10、說說核心的配置有哪些？

11、Dubbo 推薦用什么協(xié)議？

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

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

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

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

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

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

可以通過 dubbo:reference 中設(shè)置 mock="return null"。mock 的值也可以修改為 true，然后再跟接口同一個(gè)路徑下實(shí)現(xiàn)一個(gè) Mock 類，命名規(guī)則是 “接口名稱+Mock” 后綴。然后在 Mock 類里實(shí)現(xiàn)自己的降級(jí)邏輯

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

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

17、Dubbo Monitor 實(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 向 DubboMonitor 發(fā)送數(shù)據(jù)?

2、DubboMonitor 將數(shù)據(jù)進(jìn)行聚合后（默認(rèn)聚合 1min 中的統(tǒng)計(jì)數(shù)據(jù)）暫存到ConcurrentMap 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ù)塞入 BlockingQueue queue 中（隊(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ù)畫成圖表

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

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

工廠模式

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

private?static?final?Protocol?protocol?=
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 完成的，具體是將注解中含有 group=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ò)展 JDK SPI 的類 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。

19、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ì)象！

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

JDK SPI：

JDK 標(biāo)準(zhǔn)的 SPI 會(huì)一次性加載所有的擴(kuò)展實(shí)現(xiàn)，如果有的擴(kuò)展吃實(shí)話很耗時(shí)，但也沒用上，很浪費(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í)不支持，可與通過 tcc-transaction 框架實(shí)現(xiàn)

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

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

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

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

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

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

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

24、Dubbo 必須依賴的包有哪些？

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

25、Dubbo telnet 命令能做什么？

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

連接服務(wù)

telnet localhost 20880 //鍵入回車進(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í)嗎？

以通過 dubbo:reference 中設(shè)置 mock="return null"。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 -9 PID 等強(qiáng)制關(guān)閉指令，是不會(huì)執(zhí)行優(yōu)雅停機(jī)的，只有通過 kill PID 時(shí)，才會(huì)執(zhí)行。

28、Dubbo 和 Dubbox 之間的區(qū)別？

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

29、Dubbo 和 Spring Cloud 的區(qū)別？

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

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

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

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

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

?	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)	無	Spring Cloud Netflix Zuul
分布式配置	無	Spring Cloud Config
服務(wù)跟蹤	無	Spring Cloud Sleuth
消息總線	無	Spring Cloud Bus
數(shù)據(jù)流	無	Spring Cloud Stream
批量任務(wù)	無	Spring Cloud Task
......	......	......

最大的區(qū)別:Spring Cloud拋棄了Dubbo 的RPC通信，采用的是基于HTTP的REST方式。嚴(yán)格來說，這兩種方式各有優(yōu)劣。雖然在一定程度上來說，后者犧牲了服務(wù)調(diào)用的性能，但也避免了上面提到的原生RPC帶來的問題。而且REST相比RPC更為靈活，服務(wù)提供方和調(diào)用方的依賴只依靠一紙契約，不存在代碼級(jí)別的強(qiáng)依賴，這在強(qiáng)調(diào)快速演化的微服務(wù)環(huán)境下，顯得更為合適。