看了也不會弔打面試官的Dubbo高頻面試題

Dubbo是阿里巴巴公司開源的一個高性能優秀的服務框架,使得應用可通過高性能的 RPC 實現服務的輸出和輸入功能,可以和 Spring框架無縫集成。Dubbo是一款高性能、輕量級的開源Java RPC框架,它提供了三大核心能力:面向接口的遠程方法調用,智能容錯和負載均衡,以及服務自動註冊和發現。因此Dubbo的應用非常廣泛,也在互聯網公司的應用中起到非常重要的角色,只要你的簡歷上有Dubbo的字眼,面試官一定會問你Dubbo的問題,所以,今天碼之初就爲大家帶來的Dubbo的高頻面試題整理,望鄉親們喜歡,關注、轉發、在看。

1、Dubbo 是什麼?

Dubbo 是一個分佈式、高性能、透明化的 RPC 服務框架,提 供服務自動註冊、自動發現等高效服務治理方案, 可以和Spring 框架無縫集成。

2、Dubbo 的主要應用場景?

  • 透明化的遠程方法調用,就像調用本地方法一樣調用遠程方法,只需簡單配置,沒有任何 API 侵入。

  • 軟負載均衡及容錯機制,可在內網替代 F5 等硬件負載均衡器, 降低成本,減少單點。

  • 服務自動註冊與發現,不再需要寫死服務提供方地址,註冊中心 基於接口名查詢服務提供者的 IP 地址,並且能夠平滑添加或刪 除服務提供者。

3、Dubbo 支持哪些協議,每種協議的應用場景,優缺點?

  • dubbo: 單一長連接和 NIO 異步通訊,適合大併發小數據量的服務調用, 以及消費者遠大於提供者。傳輸協議 TCP,異步,Hessian 序列化;

  • rmi: 採用 JDK 標準的 rmi 協議實現,傳輸參數和返回參數對象需要實現Serializable 接口,使用 java 標準序列化機制,使用阻塞式短連接,傳輸數 據包大小混合,消費者和提供者個數差不多,可傳文件,傳輸協議 TCP。多個短連接,TCP 協議傳輸,同步傳輸,適用常規的遠程服務調用和 rmi 互 操作。在依賴低版本的 Common-Collections 包,java 序列化存在安全漏 洞;

  • webservice: 基於 WebService 的遠程調用協議,集成 CXF 實現,提供和 原生 WebService 的互操作。多個短連接,基於 HTTP 傳輸,同步傳輸,適 用系統集成和跨語言調用;

  • http: 基於 Http 表單提交的遠程調用協議,使用 Spring 的 HttpInvoke 實 現。多個短連接,傳輸協議 HTTP,傳入參數大小混合,提供者個數多於消 費者,需要給應用程序和瀏覽器 JS 調用;

  • hessian: 集成 Hessian 服務,基於 HTTP 通訊,採用 Servlet 暴露服務,Dubbo 內嵌 Jetty 作爲服務器時默認實現,提供與 Hession 服務互操作。多 個短連接,同步 HTTP 傳輸,Hessian 序列化,傳入參數較大,提供者大於 消費者,提供者壓力較大,可傳文件;

  • memcache: 基於 memcached 實現的 RPC 協議

  • redis: 基於 redis 實現的 RPC 協議

**4、dubbo 推薦用什麼協議?**默認使用 dubbo 協議

5、Dubbo 超時時間怎樣設置?

Dubbo 超時時間設置有兩種方式:

  • 服務提供者端設置超時時間,在 Dubbo 的用戶文檔中,推薦如果能在服務 端多配置就儘量多配置,因爲服務提供者比消費者更清楚自己提供的服務特性。

  • 服務消費者端設置超時時間,如果在消費者端設置了超時時間,以消費者端 爲主,即優先級更高。因爲服務調用方設置超時時間控制性更靈活。如果消 費方超時,服務端線程不會定製,會產生警告。

6、Dubbo 有些哪些註冊中心?

  • Multicast 註冊中心: Multicast 註冊中心不需要任何中心節點,只要廣播地 址,就能進行服務註冊和發現。基於網絡中組播傳輸實現;

  • Zookeeper 註冊中心: 基於分佈式協調系統 Zookeeper 實現,採用Zookeeper 的 watch 機制實現數據變更;

  • redis 註冊中心: 基於 redis 實現,採用 key/Map 存儲,住 key 存儲服務名 和類型,Map 中 key 存儲服務 URL,value 服務過期時間。基於 redis 的發 布/訂閱模式通知數據變更;

  • Simple 註冊中心

7、Dubbo 默認採用註冊中心?

採用 Zookeeper

**8、Dubbo 集羣的負載均衡有哪些策略 **

Dubbo 提供了常見的集羣策略實現,並預擴展點予以自行實現。

  • Random LoadBalance: 隨機選取提供者策略,有利於動態調整提供者權 重。截面碰撞率高,調用次數越多,分佈越均勻;

  • RoundRobin LoadBalance: 輪循選取提供者策略,平均分佈,但是存在請 求累積的問題;

  • LeastActive LoadBalance: 最少活躍調用策略,解決慢提供者接收更少的 請求;

  • ConstantHash LoadBalance: 一致性 Hash 策略,使相同參數請求總是發 到同一提供者,一臺機器宕機,可以基於虛擬節點,分攤至其他提供者,避 免引起提供者的劇烈變動。

9、Dubbo 的核心功能?

主要就是如下 3 個核心功能:

  • Remoting:網絡通信框架,提供對多種NIO框架抽象封裝,包括 “同步轉異步”和“請求-響應”模式的信息交換方式。

  • Cluster:服務框架,提供基於接口方法的透明遠程過程調用,包括多 協議支持,以及軟負載均衡,失敗容錯,地址路由,動態配置等集羣 支持。

  • Registry:服務註冊,基於註冊中心目錄服務,使服務消費方能動態 的查找服務提供方,使地址透明,使服務提供方可以平滑增加或減少 機器。

10、Dubbo的核心組件和核心配置?

核心組件:

image

核心配置:

image

配置之間關係如下圖:

image

11、在 Provider 上可以配置的 Consumer 端的屬性有哪些?

  • timeout:方法調用超時

  • retries:失敗重試次數,默認重試 2 次

  • loadbalance:負載均衡算法,默認隨機

  • actives 消費者端,最大併發調用限制

12、Dubbo啓動時如果依賴的服務不可用會怎樣?

Dubbo 缺省會在啓動時檢查依賴的服務是否可用,不可用時會拋出異常,阻止 Spring 初始化完成,默認 check=“true”,可以通過 check=“false” 關閉檢查。

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

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

14、服務上線怎麼不影響舊版本?

答:採用多版本開發,不影響舊版本。在配置中添加version來作爲版本區分

15、如何解決服務調用鏈過長的問題?

答:可以結合 zipkin 實現分佈式服務追蹤。

16、Dubbo 服務註冊與發現的流程?

image

流程說明:

  • Provider(提供者)綁定指定端口並啓動服務

  • 指供者連接註冊中心,併發本機IP、端口、應用信息和提供服務信息發送至註冊中心存儲

  • Consumer(消費者),連接註冊中心 ,併發送應用信息、所求服務信息至註冊中心

  • 註冊中心根據 消費 者所求服務信息匹配對應的提供者列表發送至Consumer 應用緩存。

  • Consumer 在發起遠程調用時基於緩存的消費者列表擇其一發起調用。

  • Provider 狀態變更會實時通知註冊中心、在由註冊中心實時推送至

  • Consumer

設計的原因:

  • Consumer 與 Provider 解偶,雙方都可以橫向增減節點數。

  • 註冊中心對本身可做對等集羣,可動態增減節點,並且任意一臺宕掉後,將自動切換到另一臺

  • 去中心化,雙方不直接依懶註冊中心,即使註冊中心全部宕機短時間內也不會影響服務的調用

  • 服務提供者無狀態,任意一臺宕掉後,不影響使用

image

17、Dubbo需要 Web 容器嗎?

不需要,如果硬要用 Web 容器,只會增加複雜性,也浪費資源。

18、Dubbo內置了哪幾種服務容器?

  • Spring Container
  • Jetty Container
  • Log4j Container

Dubbo 的服務容器只是一個簡單的 Main 方法,並加載一個簡單的 Spring 容器,用於暴露服務。

19、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

20、Dubbo 的服務調用流程?

image

20、Dubbo 用到哪些設計模式?

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

工廠模式

Provider在export服務時,會調用ServiceConfig的export方法。ServiceConfig中有個字段:

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

Dubbo裏有很多這種代碼。這也是一種工廠模式,只是實現類的獲取採用了JDK SPI的機制。這麼實現的優點是可擴展性強,想要擴展實現,只需要在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。

21、爲什麼需要服務治理?

image

  • 過多的服務URL配置困難

  • 負載均衡分配節點壓力過大的情況下也需要部署集羣

  • 服務依賴混亂,啓動順序不清晰

  • 過多服務導致性能指標分析難度較大,需要監控

22、Dubbo 的註冊中心集羣掛掉,發佈者和訂閱者之間還能通信麼?

可以的,啓動 dubbo 時,消費者會從 zookeeper 拉取註冊的生產者 的地址接口等數據,緩存在本地。

每次調用時,按照本地存儲的地址進行調用。

23、Dubbo 與 Spring 的關係?

Dubbo 採用全 Spring 配置方式,透明化接入應用,對應用沒有任何API 侵入,只需用 Spring 加載 Dubbo 的配置即可,Dubbo 基於Spring 的 Schema 擴展進行加載。

24、Dubbo有哪幾種負載均衡策略,默認是哪種?

image

25、註冊了多個同一樣的服務,如果測試指定的某一個服務呢?

可以配置環境點對點直連,繞過註冊中心,將以服務接口爲單位,忽略註冊中心的提供者列表。

26、Dubbo支持服務多協議嗎?

Dubbo 允許配置多協議,在不同服務上支持不同協議或者同一服務上同時支持多種協議。

27、當一個服務接口有多種實現時怎麼做?

當一個接口有多種實現時,可以用 group 屬性來分組,服務提供方和消費方都指定同一個 group 即可。

28、服務上線怎麼兼容舊版本?

可以用版本號(version)過渡,多個不同版本的服務註冊到註冊中心,版本號不同的服務相互間不引用。這個和服務分組的概念有一點類似。

29、Dubbo可以對結果進行緩存嗎?

可以,Dubbo 提供了聲明式緩存,用於加速熱門數據的訪問速度,以減少用戶加緩存的工作量。

30、默認使用的是什麼通信框架,還有別的選擇嗎?

答:默認也推薦使用 netty 框架,還有 mina。

31、Dubbo服務之間的調用是阻塞的嗎?

默認是同步等待結果阻塞的,支持異步調用。

Dubbo 是基於 NIO 的非阻塞實現並行調用,客戶端不需要啓動多線程即可完成並行調用多個遠程服務,相對多線程開銷較小,異步調用會返回一個 Future 對象。

異步調用流程圖如下。

image

32、D****ubbo支持分佈式事務嗎?

答:目前暫時不支持,可與通過 tcc-transaction框架實現介紹:tcc-transaction是開源的TCC補償性分佈式事務框架Git地址:https://github.com/changmingxie/tcc-transactionTCC-Transaction 通過 Dubbo 隱式傳參的功能,避免自己對業務代碼的入侵。

33、Dubbo 的集羣容錯方案有哪些?

image

34、Dubbo 的默認集羣容錯方案?

Failover Cluster

35、Dubbo 支持哪些序列化方式?

默認使用 Hessian 序列化,還有 Duddo、FastJson、Java 自帶序列 化。

**36、服務調用超時問題怎麼解決?**

dubbo 在調用服務不成功時,默認是會重試兩次的。

37、Dubbo 在安全機制方面是如何解決?

Dubbo 通過 Token 令牌防止用戶繞過註冊中心直連,然後在註冊中 心上管理授權。Dubbo 還提供服務黑白名單,來控制服務所允許的調 用方。

38、Dubbo 和 Dubbox 之間的區別?

dubbox 基於 dubbo 上做了一些擴展,如加了服務可 restful 調 用,更新了開源組件等。

39、Dubbo支持服務降級嗎?

Dubbo 2.2.0 以上版本支持。

40、Dubbo如何優雅停機?

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

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

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

42、如何解決服務調用鏈過長的問題?

Dubbo 可以使用 Pinpoint 和 Apache Skywalking(Incubator) 實現分佈式服務追蹤,當然還有其他很多方案。

43、服務讀寫推薦的容錯策略是怎樣的?

  • 讀操作建議使用 Failover 失敗自動切換,默認重試兩次其他服務器。

  • 寫操作建議使用 Failfast 快速失敗,發一次調用失敗就立即報錯。

44、Dubbo必須依賴的包有哪些?

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

45、Dubbo的管理控制檯能做什麼?

管理控制檯主要包含:路由規則,動態配置,服務降級,訪問控制,權重調整,負載均衡,等管理功能。

46、說說 Dubbo 服務暴露的過程。

Dubbo 會在 Spring 實例化完 bean 之後,在刷新容器最後一步發佈 ContextRefreshEvent 事件的時候,通知實現了 ApplicationListener 的 ServiceBean 類進行回調 onApplicationEvent 事件方法,Dubbo 會在這個方法中調用 ServiceBean 父類 ServiceConfig 的 export 方法,而該方法真正實現了服務的(異步或者非異步)發佈。

47、Dubbo 和 Spring Cloud 的區別?

最大的區別:Dubbo 底層是使用 Netty 這樣的 NIO 框架,是基於TCP 協議傳輸的,配合以 Hession 序列化完成 RPC 通信。而 SpringCloud 是基於 Http 協議+Rest 接口調用遠程過程的通信, 相對來說,Http 請求會有更大的報文,佔的帶寬也會更多。但是REST 相比 RPC 更爲靈活,服務提供方和調用方的依賴只依靠一紙契約,不存在代碼級別的強依賴。

image

參考文章:https://blog.csdn.net/azhegps/article/details/99104880

參考文章:https://blog.csdn.net/t4i2b10x4c22nf6a/article/details/89530201

參考文章:https://blog.csdn.net/yanpenglei/article/details/88363884

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章