Java面試題－Dubbo

1.Dubbo 面試題

1、為什麼要用Dubbo？

2、Dubbo 的整體架構設計有哪些分層?

3、預設使用的是什麼通訊框架，還有別的選擇嗎?

4、服務呼叫是阻塞的嗎？

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

6、預設使用什麼序列化框架，你知道的還有哪些？

7、服務提供者能實現失效踢出是什麼原理？

8、服務上線怎麼不影響舊版？

9、如何解決服務呼叫鏈過長的問題？

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

11、Dubbo 推薦用什麼協定？

12、同一個服務多個註冊的情況下可以直連某一個服務嗎？

13、畫一畫服務註冊與發現的流程圖？

14、Dubbo 叢集容錯有幾種方案？

15、Dubbo 服務降級，失敗重試怎麼做？

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

17、Dubbo Monitor 實作原理？

18、Dubbo 用到哪些設計模式？

19、Dubbo 設定檔是如何載入到 Spring 中的？

20、Dubbo SPI 和 Java SPI 區別？

21、Dubbo 支援分散式事務嗎？

22、Dubbo 可以對結果進行快取嗎？

23、服務上線怎麼相容舊版？

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

25、Dubbo telnet 指令能做什麼？

26、Dubbo 支援服務降級嗎？

27、Dubbo 如何優雅停機？

28、Dubbo 和 Dubbox 之間的差異？

29、Dubbo 和 Spring Cloud 的差別？

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

2.Dubbo 面試題答案解析

1、為什麼要用 Dubbo？

隨著服務化的進一步發展，服務越來越多，服務之間的呼叫與依賴關係也越來越複雜，誕生了服務導向的架構系統(SOA)，也因此衍生出了一系列對應的技術，如對服務提供、服務呼叫、連接處理、通訊協定、序列化方式、服務發現、服務路由、日誌輸出等行為進行封裝的服務架構。就這樣為分散式系統的服務治理架構就出現了，Dubbo 也就這樣產生了。

2、Dubbo 的整體架構設計有哪些分層?

介面服務層（Service）：該層與業務邏輯相關，根據provider 和consumer 的業務設計對應的介面和實作

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

##服務代理層（Proxy）： 服務介面透明代理，產生服務的客戶端Stub 和服務端的Skeleton，以ServiceProxy 為中心，擴充介面為ProxyFactory

服務註冊層（Registry）：封裝服務位址的註冊和發現，以服務URL 為中心，擴展介面為RegistryFactory、Registry、RegistryService

路由層（Cluster）：封裝多個提供者的路由和負載平衡，並橋接註冊中心，以Invoker 為中心，擴充介面為Cluster、Directory、Router 和LoadBlancce

監控層（Monitor）：RPC 呼叫次數和呼叫時間監控，以Statistics 為中心，擴展介面為MonitorFactory、Monitor 和MonitorService

遠端調用層（Protocal）：封裝RPC 調用，以Invocation 和Result 為中心，擴充介面為Protocal、Invoker 和Exporter

訊息交換層（Exchange）：封裝請求回應模式，同步轉異步。以Request 和Response 為中心，擴充介面為Exchanger、ExchangeChannel、ExchangeClient 和ExchangeServer

網路傳輸層（Transport）：抽象mina 和netty 為統一介面，以Message 為中心，擴充介面為Channel、Transporter、Client、Server 和Codec

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

3、預設使用的是什麼通訊框架，還有別的選擇嗎?

預設也推薦使用netty 框架，還有mina。

4、服務呼叫是阻塞的嗎？

預設是阻塞的，可以非同步調用，沒有回傳值的可以這麼做。 Dubbo 是基於 NIO 的非阻塞實作並行調用，客戶端不需要啟動多執行緒即可完成並行調用多個遠端服務，相對多執行緒開銷較小，非同步調用會傳回一個 Future 物件。

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

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

6、預設使用什麼序列化框架，你知道的還有哪些？

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

7、服務提供者能實現失效踢出是什麼原理？

服務失效踢出基於 zookeeper 的臨時節點原理。

8、服務上線怎麼不影響舊版？

採用多版本開發，不影響舊版。

9、如何解決服務呼叫鏈過長的問題？

可以結合 zipkin 實現分散式服務追蹤。

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

11、Dubbo 推薦用什麼協定？

12、同一個服務多個註冊的情況下可以直接連某一個服務嗎？

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

（更多相關面試題推薦：java面試題目及答案）

#13、畫一畫服務註冊與發現的流程圖？

14、Dubbo 叢集容錯有幾種方案？

15、Dubbo 服務降級，失敗重試怎麼做？

可以透過 dubbo:reference 中設定 mock="return null"。 mock 的值也可以修改為 true，然後再跟介面同一個路徑下實作一個 Mock 類，命名規則是 “介面名稱 Mock” 字尾。然後在 Mock 類別裡實作自己的降級邏輯

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

在註冊中心找不到對應的服務,檢查service 實現類別是否新增了@service 註解無法連接到註冊中心,檢查設定檔中的對應的測試ip 是否正確

17 、Dubbo Monitor 實作原理？

Consumer 端在發起呼叫之前會先走 filter 鏈；provider 端在接收到請求時也是先走 filter 鏈，然後才進行真正的業務邏輯處理。預設情況下，在 consumer 和 provider 的 filter 鏈中都會有 Monitorfilter。

1、MonitorFilter 傳送資料至DubboMonitor

2、DubboMonitor 將資料聚合後（預設聚合1min 中的統計資料）暫存到ConcurrentMap statisticsMap，然後使用一個含有3 個線程（線程名字：DubboMonitorSendTimer）的線程池每隔1min 鐘，調用SimpleMonitorService 遍歷發送statisticsMap 中的統計數據，每發送完畢一個，就重置當前的Statistics 的AtomicReference

#3、SimpleMonitorService將這些聚合資料塞入BlockingQueue queue 中（隊列大寫為100000）

4、SimpleMonitorService 使用一個後台執行緒（執行緒名為：DubboMonitorAsyncWriteLogThread）將queue 中的資料寫入檔案（該執行緒以死的循環形式來寫）

5、SimpleMonitorService 也會使用一個含有1 個執行緒（執行緒名字：DubboMonitorTimer）的執行緒池每隔5min 鐘，將檔案中的統計資料畫成圖表

18.Dubbo 用到哪些設計模式？

Dubbo 框架在初始化和通訊過程中使用了多種設計模式，可靈活控制類別載入、權限控制等功能。

工廠模式

Provider 在 export 服務時，會呼叫 ServiceConfig 的 export 方法。 ServiceConfig中有個欄位：

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

登入後複製

Dubbo 裡有很多這種程式碼。這也是一種工廠模式，只是實作類別的取得採用了 JDKSPI 的機制。這麼實現的優點是可擴充性強，想要擴充實現，只要在 classpath下增加個檔案就可以了，程式碼零侵入。另外，像上面的 Adaptive 實現，可以做到呼叫時動態決定調用哪個實現，但是由於這種實現採用了動態代理，會造成代碼調試比較麻煩，需要分析出實際調用的實現類。

裝飾器模式

Dubbo 在启动和调用阶段都大量使用了装饰器模式。以 Provider 提供的调用链为例，具体的调用链代码是在 ProtocolFilterWrapper 的 buildInvokerChain 完成的，具体是将注解中含有 group=provider 的 Filter 实现，按照 order 排序，最后的调用顺序是：

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

登入後複製

更确切地说，这里是装饰器和责任链模式的混合使用。例如，EchoFilter 的作用是判断是否是回声测试请求，是的话直接返回内容，这是一种责任链的体现。而像ClassLoaderFilter 则只是在主功能上添加了功能，更改当前线程的 ClassLoader，这是典型的装饰器模式。

观察者模式

Dubbo 的 Provider 启动时，需要与注册中心交互，先注册自己的服务，再订阅自己的服务，订阅时，采用了观察者模式，开启一个 listener。注册中心会每 5 秒定时检查是否有服务更新，如果有更新，向该服务的提供者发送一个 notify 消息，provider 接受到 notify 消息后，运行 NotifyListener 的 notify 方法，执行监听器方法。

动态代理模式

Dubbo 扩展 JDK SPI 的类 ExtensionLoader 的 Adaptive 实现是典型的动态代理实现。Dubbo 需要灵活地控制实现类，即在调用阶段动态地根据参数决定调用哪个实现类，所以采用先生成代理类的方法，能够做到灵活的调用。生成代理类的代码是 ExtensionLoader 的 createAdaptiveExtensionClassCode 方法。代理类主要逻辑是，获取 URL 参数中指定参数的值作为获取实现类的 key。

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

Spring 容器在启动的时候，会读取到 Spring 默认的一些 schema 以及 Dubbo 自定义的 schema，每个 schema 都会对应一个自己的 NamespaceHandler，NamespaceHandler 里面通过 BeanDefinitionParser 来解析配置信息并转化为需要加载的 bean 对象！

20、Dubbo SPI 和 Java SPI 区别？

JDK SPI：

JDK 标准的 SPI 会一次性加载所有的扩展实现，如果有的扩展吃实话很耗时，但也没用上，很浪费资源。所以只希望加载某个的实现，就不现实了

DUBBO SPI：

1、对 Dubbo 进行扩展，不需要改动 Dubbo 的源码

2、延迟加载，可以一次只加载自己想要加载的扩展实现。

3、增加了对扩展点 IOC 和 AOP 的支持，一个扩展点可以直接 setter 注入其

它扩展点。

4、Dubbo 的扩展机制能很好的支持第三方 IoC 容器，默认支持 Spring Bean。

21、Dubbo 支持分布式事务吗？

目前暂时不支持，可与通过 tcc-transaction 框架实现

介绍：tcc-transaction 是开源的 TCC 补偿性分布式事务框架

TCC-Transaction 通过 Dubbo 隐式传参的功能，避免自己对业务代码的入侵。

22、Dubbo 可以对结果进行缓存吗？

为了提高数据访问的速度。Dubbo 提供了声明式缓存，以减少用户加缓存的工作量

其实比普通的配置文件就多了一个标签 cache="true"

23、服务上线怎么兼容旧版本？

可以用版本号（version）过渡，多个不同版本的服务注册到注册中心，版本号不同的服务相互间不引用。这个和服务分组的概念有一点类似。

24、Dubbo 必须依赖的包有哪些？

Dubbo 必须依赖 JDK，其他为可选。

25、Dubbo telnet 命令能做什么？

dubbo 服务发布之后，我们可以利用 telnet 命令进行调试、管理。Dubbo2.0.5 以上版本服务提供端口支持 telnet 命令

连接服务

telnet localhost 20880 //键入回车进入 Dubbo 命令模式。

查看服务列表

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

登入後複製

· ls (list services and methods)

· ls : 显示服务列表。

· ls -l : 显示服务详细信息列表。

· ls XxxService：显示服务的方法列表。

· ls -l XxxService：顯示服務的方法詳細資訊清單。

26、Dubbo 支援服務降級嗎？

以透過 dubbo:reference 中設定 mock="return null"。 mock 的值也可以修改為 true，然後再跟介面同一個路徑下實作一個 Mock 類，命名規則是 “介面名稱 Mock” 字尾。然後在 Mock 類別中實作自己的降級邏輯

27、Dubbo 如何優雅停機？

Dubbo 是透過 JDK 的 ShutdownHook 來完成優雅停機的，所以如果使用kill -9 PID 等強制關閉指令，是不會執行優雅停機的，只有透過 kill PID 時，才會執行。

28、Dubbo 和 Dubbox 之間的差異？

Dubbox 是繼 Dubbo 停止維護後，當網基於 Dubbo 做的一個擴展項目，如加了服務可 Restful 調用，更新了開源組件等。

29、Dubbo 和 Spring Cloud 的差別？

根據微服務架構在各方面的要素，看看 Spring Cloud 和 Dubbo 都提供了哪些支援。

使用Dubbo 建構的微服務架構就像組裝電腦，各環節我們的選擇自由度很高，但是最終結果很有可能因為一條記憶體品質不行就點不亮了，總是讓人不怎麼放心，但是如果你是一名高手，那這些都不是問題；而Spring Cloud 就像品牌機，在Spring Source 的整合下，做了大量的兼容性測試，保證了機器擁有更高的穩定性，但是如果要在使用非原廠組件外的東西，就需要對其基礎有足夠的了解。

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

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

3.Spring Cloud 與Dubbo 區別

##分散式設定無Spring Cloud Config服務追蹤無Spring Cloud Sleuth訊息匯流排無Spring Cloud Bus

#	Dubbo	#Spring Cloud
##服務註冊中心	Zookeeper	Spring Cloud Netflix Eureka
服務調用方式	RPC	REST API
服務監控	Dubbo-monitor	Spring Boot Admin
斷路器	不完善	Spring Cloud Netflix Hystrix
服務網關	無	Spring Cloud Netflix Zuul





無	Spring Cloud Stream

##################################################### ###無############Spring Cloud Task############################################################################################ #####......############......###################最大的差異:Spring Cloud拋棄了Dubbo 的RPC通信，採用的是基於HTTP的REST方式。嚴格來說，這兩種方式各有優劣。雖然在某種程度上來說，後者犧牲了服務呼叫的效能，但也避免了上述的原生RPC所帶來的問題。而REST相比RPC更為靈活，服務提供者和呼叫方的依賴只依賴一紙契約，不存在程式碼層級的強依賴，這在強調快速演化的微服務環境下，顯得更為合適。 ######4.另一個微服務框架SpringCloud######請翻閱往期：######SpringCloud元件原理:Eureka，Feign，Ribbon，Hystrix，Zuul##### #相關推薦：###java入門#######

以上是Java面試題－Dubbo的詳細內容。更多資訊請關注PHP中文網其他相關文章！