Dubbo面試25題答案詳解

陝西優就業發表於2019-12-11

   陝西優就業小編在此總結一下Dubbo常見的面試題,希望對面試的小夥伴有幫助。


  1、Dubbo是什麼?

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

  RPC指的是遠端呼叫協議,也就是說兩個伺服器互動資料。

  2、Dubbo的由來?

  網際網路的快速發展,Web應用程式的規模不斷擴大,一般會經歷如下四個發展階段。

  ①單一應用架構

  當網站流量很小時,只需一個應用,將所有功能都部署在一起即可。

  ②垂直應用架構

  當訪問量逐漸增大,單一應用按照有業務線拆成多個應用,以提升效率。此時,用於加速前端頁面開發的 Web框架(MVC) 是關鍵。

  ③分散式服務架構

  當垂直應用越來越多,應用之間互動不可避免,將核心業務抽取出來,作為獨立的服務,逐漸形成穩定的服務中心,使前端應用能更快速的響應多變的市場需求。

  此時,用於提高業務複用及整合的 分散式服務框架(RPC)是關鍵。

  ④流動計算架構

  當服務越來越多,容量的評估,小服務資源的浪費等問題逐漸顯現,此時需增加一個排程中心基於訪問壓力實時管理叢集容量,提高叢集利用率。

  此時,用於提高機器利用率的 資源排程和治理中心(SOA)是關鍵。

  3、Dubbo的主要應用場景?

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

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

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

  4、Dubbo的核心功能?

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

  ①Remoting:網路通訊框架,提供對多種NIO框架抽象封裝,包括“同步轉非同步”和“請求-響應”模式的資訊交換方式。

  ②Cluster:服務框架,提供基於介面方法的透明遠端過程呼叫,包括多協議支援,以及軟負載均衡,失敗容錯,地址路由,動態配置等叢集支援。

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

  5、Dubbo的核心元件?

  ①Provider:暴露服務的服務提供方

  ②Consumer:呼叫遠端服務的服務消費方

  ③Registry:服務註冊與發現的註冊中心

  ④Monitor:統計服務的呼叫次調和呼叫時間的監控中心

  ⑤Container:服務執行容器

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

  流程說明:

  ①Provider(提供者)繫結指定埠並啟動服務

  ②指供者連線註冊中心,併發本機IP、埠、應用資訊和提供服務資訊傳送至註冊中心儲存

  ③Consumer(消費者),連線註冊中心 ,併傳送應用資訊、所求服務資訊至註冊中心

  ④註冊中心根據消費者所求服務資訊匹配對應的提供者列表傳送至Consumer 應用快取。

  ⑤Consumer在發起遠端呼叫時基於快取的消費者列表擇其一發起呼叫。

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

  設計的原因:

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

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

  ③去中心化,雙方不直接依懶註冊中心,即使註冊中心全部當機短時間內也不會影響服務的呼叫;

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

  7.Dubbo的架構設計?

  Dubbo框架設計一共劃分了10個層:

  ①服務介面層(Service):該層是與實際業務邏輯相關的,根據服務提供方和服務消費方的業務設計對應的介面和實現。

  ②配置層(Config):對外配置介面,以ServiceConfig和ReferenceConfig為中心,可以直接new配置類,也可以透過spring解析配置生成配置類。

  ③服務代理層(Proxy):服務介面透明代理,生成服務的客戶端Stub和伺服器端Skeleton,以ServiceProxy為中心,擴充套件介面為ProxyFactory。

  ④服務註冊層(Registry):封裝服務地址的註冊與發現,以服務URL為中心,擴充套件介面為RegistryFactory、Registry和RegistryService。可能沒有服務註冊中心,此時服務提供方直接暴露服務。

  ⑤叢集層(Cluster):封裝多個提供者的路由及負載均衡,並橋接註冊中心,以Invoker為中心,擴充套件介面為Cluster、Directory、Router和LoadBalance。將多個服務提供方組合為一個服務提供方,實現對服務消費方來透明,只需要與一個服務提供方進行互動。

  ⑥監控層(Monitor):RPC呼叫次數和呼叫時間監控,以Statistics為中心,擴充套件介面為MonitorFactory、Monitor和MonitorService。

  ⑦遠端呼叫層(Protocol):封將RPC呼叫,以Invocation和Result為中心,擴充套件介面為Protocol、Invoker和Exporter。Protocol是服務域,它是Invoker暴露和引用的主功能入口,它負責Invoker的生命週期管理。

  Invoker是實體域,它是Dubbo的核心模型,其它模型都向它靠擾,或轉換成它,它代表一個可執行體,可向它發起invoke呼叫,它有可能是一個本地的實現,也可能是一個遠端的實現,也可能一個叢集實現。

  ⑧資訊交換層(Exchange):封裝請求響應模式,同步轉非同步,以Request和Response為中心,擴充套件介面為Exchanger、ExchangeChannel、ExchangeClient和ExchangeServer。

  ⑨網路傳輸層(Transport):抽象mina和netty為統一介面,以Message為中心,擴充套件介面為Channel、Transporter、Client、Server和Codec。

  ⑩資料序列化層(Serialize):可複用的一些工具,擴充套件介面為Serialization、 ObjectInput、ObjectOutput和ThreadPool。

  8、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協議

  9、dubbo推薦用什麼協議?

  預設使用dubbo協議

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

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

  ②Zookeeper註冊中心:基於分散式協調系統Zookeeper實現,採用Zookeeper的watch機制實現資料變更;

  ③redis註冊中心:基於redis實現,採用key/Map儲存,住key儲存服務名和型別,Map中key儲存服務URL,value服務過期時間。基於redis的釋出/訂閱模式通知資料變更;

  ④Simple註冊中心

  11、Dubbo的服務治理?

  ①過多的服務URL配置困難;

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

  ③服務依賴混亂,啟動順序不清晰;

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

  12、Dubbo的註冊中心叢集掛掉,釋出者和訂閱者之間還能通訊麼?

  可以的,啟動dubbo時,消費者會從zookeeper拉取註冊的生產者的地址介面等資料,快取在本地。

  每次呼叫時,按照本地儲存的地址進行呼叫。

  13、Dubbo與Spring的關係?

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

  14、Dubbo使用的是什麼通訊框架?

  預設使用NIO Netty框架

  15、Dubbo叢集提供了哪些負載均衡策略?

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

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

  ③LeastActive LoadBalance:最少活躍呼叫策略,解決慢提供者接收更少的請求;

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

  16、Dubbo的叢集容錯方案有哪些?

  ①Failover Cluster:失敗自動切換,當出現失敗,重試其它伺服器。通常用於讀操作,但重試會帶來更長延遲。

  ②Failfast Cluster:快速失敗,只發起一次呼叫,失敗立即報錯。通常用於非冪等性的寫操作,比如新增記錄。

  ③Failsafe Cluster:失敗安全,出現異常時,直接忽略。通常用於寫入審計日誌等操作。

  ④Failback Cluster:失敗自動恢復,後臺記錄失敗請求,定時重發。通常用於訊息通知操作。

  ⑤Forking Cluster:並行呼叫多個伺服器,只要一個成功即返回。通常用於實時性要求較高的讀操作,但需要浪費更多服務資源。可透過 forks=”2″ 來設定最大並行數。

  ⑥Broadcast Cluster:廣播呼叫所有提供者,逐個呼叫,任意一臺報錯則報錯 。通常用於通知所有提供者更新快取或日誌等本地資源資訊。

  17、Dubbo的預設叢集容錯方案?

  Failover Cluster

  18、Dubbo支援哪些序列化方式?

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

  19、Dubbo超時時間怎樣設定?

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

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

  ②服務消費者端設定超時時間,如果在消費者端設定了超時時間,以消費者端為主,即優先順序更高。因為服務呼叫方設定超時時間控制性更靈活。如果消費方超時,服務端執行緒不會定製,會產生警告。

  20、服務呼叫超時問題怎麼解決?

  dubbo在呼叫服務不成功時,預設是會重試兩次的。

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

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

  22、dubbo和dubbox之間的區別?

  dubbox基於dubbo上做了一些擴充套件,如加了服務可restful呼叫,更新了開源元件等。

  23、除了Dubbo還有哪些分散式框架?

  大家熟知的就是Spring cloud,當然國外也有類似的多個框架。

  24、Dubbo和Spring Cloud的關係?

  Dubbo是SOA時代的產物,它的關注點主要在於服務的呼叫,流量分發、流量監控和熔斷。而 Spring Cloud誕生於微服務架構時代,考慮的是微服務治理的方方面面,另外由於依託了Spirng、Spirng Boot的優勢之上,兩個框架在開始目標就不一致,Dubbo定位服務治理、Spirng Cloud是一個生態。

  25、dubbo和spring cloud的區別?

  最大的區別:Dubbo底層是使用Netty這樣的NIO框架,是基於TCP協議傳輸的,配合以Hession序列化完成RPC通訊。

  而SpringCloud是基於Http協議+Rest介面呼叫遠端過程的通訊,相對來說,Http請求會有更大的報文,佔的頻寬也會更多。但是REST相比RPC更為靈活,服務提供方和呼叫方的依賴只依靠一紙契約,不存在程式碼級別的強依賴,這在強調快速演化的微服務環境下,顯得更為合適,至於注重通訊速度還是方便靈活性,具體情況具體考慮。


來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/69902581/viewspace-2668142/,如需轉載,請註明出處,否則將追究法律責任。

相關文章