Dubbo面試題及答案有哪些

本篇內(nèi)容介紹了“Dubbo面試題及答案有哪些”的有關(guān)知識，在實(shí)際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細(xì)閱讀，能夠?qū)W有所成！

　　1、Dubbo是什么?

　　Dubbo是一個(gè)分布式、高性能、透明化的 RPC 服務(wù)框架，提供服務(wù)自動注冊、自動發(fā)現(xiàn)等高效服務(wù)治理方案， 可以和Spring框架無縫集成。

　　RPC指的是遠(yuǎn)程調(diào)用協(xié)議，也就是說兩個(gè)服務(wù)器交互數(shù)據(jù)。

　　2、Dubbo的由來?

　　互聯(lián)網(wǎng)的快速發(fā)展，Web應(yīng)用程序的規(guī)模不斷擴(kuò)大，一般會經(jīng)歷如下四個(gè)發(fā)展階段。

　　①單一應(yīng)用架構(gòu)

　　當(dāng)網(wǎng)站流量很小時(shí)，只需一個(gè)應(yīng)用，將所有功能都部署在一起即可。

　?、诖怪睉?yīng)用架構(gòu)

　　當(dāng)訪問量逐漸增大，單一應(yīng)用按照有業(yè)務(wù)線拆成多個(gè)應(yīng)用，以提升效率。此時(shí)，用于加速前端頁面開發(fā)的 Web框架(MVC) 是關(guān)鍵。

　　③分布式服務(wù)架構(gòu)

　　當(dāng)垂直應(yīng)用越來越多，應(yīng)用之間交互不可避免，將核心業(yè)務(wù)抽取出來，作為獨(dú)立的服務(wù)，逐漸形成穩(wěn)定的服務(wù)中心，使前端應(yīng)用能更快速的響應(yīng)多變的市場需求。

　　此時(shí)，用于提高業(yè)務(wù)復(fù)用及整合的 分布式服務(wù)框架(RPC)是關(guān)鍵。

　　④流動計(jì)算架構(gòu)

　　當(dāng)服務(wù)越來越多，容量的評估，小服務(wù)資源的浪費(fèi)等問題逐漸顯現(xiàn)，此時(shí)需增加一個(gè)調(diào)度中心基于訪問壓力實(shí)時(shí)管理集群容量，提高集群利用率。

　　此時(shí)，用于提高機(jī)器利用率的 資源調(diào)度和治理中心(SOA)是關(guān)鍵。

　　3、Dubbo的主要應(yīng)用場景?

　　透明化的遠(yuǎn)程方法調(diào)用，就像調(diào)用本地方法一樣調(diào)用遠(yuǎn)程方法，只需簡單配置，沒有任何API侵入。

　　軟負(fù)載均衡及容錯(cuò)機(jī)制，可在內(nèi)網(wǎng)替代F5等硬件負(fù)載均衡器，降低成本，減少單點(diǎn)。

　　服務(wù)自動注冊與發(fā)現(xiàn)，不再需要寫死服務(wù)提供方地址，注冊中心基于接口名查詢服務(wù)提供者的IP地址，并且能夠平滑添加或刪除服務(wù)提供者。

　　4、Dubbo的核心功能?

　　主要就是如下3個(gè)核心功能：

　?、賀emoting：網(wǎng)絡(luò)通信框架，提供對多種NIO框架抽象封裝，包括“同步轉(zhuǎn)異步”和“請求-響應(yīng)”模式的信息交換方式。

　?、贑luster：服務(wù)框架，提供基于接口方法的透明遠(yuǎn)程過程調(diào)用，包括多協(xié)議支持，以及軟負(fù)載均衡，失敗容錯(cuò)，地址路由，動態(tài)配置等集群支持。

　?、跼egistry：服務(wù)注冊，基于注冊中心目錄服務(wù)，使服務(wù)消費(fèi)方能動態(tài)的查找，使地址透明，使服務(wù)提供方可以平滑增加或減少機(jī)器。

　　5、Dubbo的核心組件?

　　①Provider：暴露服務(wù)的服務(wù)提供方

　?、贑onsumer：調(diào)用遠(yuǎn)程服務(wù)的服務(wù)消費(fèi)方

　　③Registry：服務(wù)注冊與發(fā)現(xiàn)的注冊中心

　?、躆onitor：統(tǒng)計(jì)服務(wù)的調(diào)用次調(diào)和調(diào)用時(shí)間的監(jiān)控中心

　?、軨ontainer：服務(wù)運(yùn)行容器

　　6、Dubbo服務(wù)注冊與發(fā)現(xiàn)的流程?

　　流程說明：

　?、貾rovider(提供者)綁定指定端口并啟動服務(wù)

　?、谥腹┱哌B接注冊中心，并發(fā)本機(jī)IP、端口、應(yīng)用信息和提供服務(wù)信息發(fā)送至注冊中心存儲

　?、跜onsumer(消費(fèi)者)，連接注冊中心 ，并發(fā)送應(yīng)用信息、所求服務(wù)信息至注冊中心

　?、茏灾行母鶕?jù)消費(fèi)者所求服務(wù)信息匹配對應(yīng)的提供者列表發(fā)送至Consumer 應(yīng)用緩存。

　?、軨onsumer在發(fā)起遠(yuǎn)程調(diào)用時(shí)基于緩存的消費(fèi)者列表擇其一發(fā)起調(diào)用。

　?、轕rovider狀態(tài)變更會實(shí)時(shí)通知注冊中心、在由注冊中心實(shí)時(shí)推送至Consumer。

　　設(shè)計(jì)的原因：

　?、貱onsumer與Provider解偶，雙方都可以橫向增減節(jié)點(diǎn)數(shù);

　?、谧灾行膶Ρ旧砜勺鰧Φ燃海蓜討B(tài)增減節(jié)點(diǎn)，并且任意一臺宕掉后，將自動切換到另一臺;

　　③去中心化，雙方不直接依懶注冊中心，即使注冊中心全部宕機(jī)短時(shí)間內(nèi)也不會影響服務(wù)的調(diào)用;

　?、芊?wù)提供者無狀態(tài)，任意一臺宕掉后，不影響使用。

　　7.Dubbo的架構(gòu)設(shè)計(jì)?

　　Dubbo框架設(shè)計(jì)一共劃分了10個(gè)層：

　?、俜?wù)接口層(Service)：該層是與實(shí)際業(yè)務(wù)邏輯相關(guān)的，根據(jù)服務(wù)提供方和服務(wù)消費(fèi)方的業(yè)務(wù)設(shè)計(jì)對應(yīng)的接口和實(shí)現(xiàn)。

　?、谂渲脤?Config)：對外配置接口，以ServiceConfig和ReferenceConfig為中心，可以直接new配置類，也可以通過spring解析配置生成配置類。

　?、鄯?wù)代理層(Proxy)：服務(wù)接口透明代理，生成服務(wù)的客戶端Stub和服務(wù)器端Skeleton，以ServiceProxy為中心，擴(kuò)展接口為ProxyFactory。

　?、芊?wù)注冊層(Registry)：封裝服務(wù)地址的注冊與發(fā)現(xiàn)，以服務(wù)URL為中心，擴(kuò)展接口為RegistryFactory、Registry和RegistryService?？赡軟]有服務(wù)注冊中心，此時(shí)服務(wù)提供方直接暴露服務(wù)。

　　⑤集群層(Cluster)：封裝多個(gè)提供者的路由及負(fù)載均衡，并橋接注冊中心，以Invoker為中心，擴(kuò)展接口為Cluster、Directory、Router和LoadBalance。將多個(gè)服務(wù)提供方組合為一個(gè)服務(wù)提供方，實(shí)現(xiàn)對服務(wù)消費(fèi)方來透明，只需要與一個(gè)服務(wù)提供方進(jìn)行交互。

　　⑥監(jiān)控層(Monitor)：RPC調(diào)用次數(shù)和調(diào)用時(shí)間監(jiān)控，以Statistics為中心，擴(kuò)展接口為MonitorFactory、Monitor和MonitorService。

　?、哌h(yuǎn)程調(diào)用層(Protocol)：封將RPC調(diào)用，以Invocation和Result為中心，擴(kuò)展接口為Protocol、Invoker和Exporter。Protocol是服務(wù)域，它是Invoker暴露和引用的主功能入口，它負(fù)責(zé)Invoker的生命周期管理。

　　Invoker是實(shí)體域，它是Dubbo的核心模型，其它模型都向它靠擾，或轉(zhuǎn)換成它，它代表一個(gè)可執(zhí)行體，可向它發(fā)起invoke調(diào)用，它有可能是一個(gè)本地的實(shí)現(xiàn)，也可能是一個(gè)遠(yuǎn)程的實(shí)現(xiàn)，也可能一個(gè)集群實(shí)現(xiàn)。

　　⑧信息交換層(Exchange)：封裝請求響應(yīng)模式，同步轉(zhuǎn)異步，以Request和Response為中心，擴(kuò)展接口為Exchanger、ExchangeChannel、ExchangeClient和ExchangeServer。

　?、峋W(wǎng)絡(luò)傳輸層(Transport)：抽象mina和netty為統(tǒng)一接口，以Message為中心，擴(kuò)展接口為Channel、Transporter、Client、Server和Codec。

　　⑩數(shù)據(jù)序列化層(Serialize)：可復(fù)用的一些工具，擴(kuò)展接口為Serialization、 ObjectInput、ObjectOutput和ThreadPool。

　　8、Dubbo支持哪些協(xié)議，每種協(xié)議的應(yīng)用場景，優(yōu)缺點(diǎn)?

　?、賒ubbo：單一長連接和NIO異步通訊，適合大并發(fā)小數(shù)據(jù)量的服務(wù)調(diào)用，以及消費(fèi)者遠(yuǎn)大于提供者。傳輸協(xié)議TCP，異步，Hessian序列化;

　　②rmi：采用JDK標(biāo)準(zhǔn)的rmi協(xié)議實(shí)現(xiàn)，傳輸參數(shù)和返回參數(shù)對象需要實(shí)現(xiàn)③Serializable接口，使用java標(biāo)準(zhǔn)序列化機(jī)制，使用阻塞式短連接，傳輸數(shù)據(jù)包大小混合，消費(fèi)者和提供者個(gè)數(shù)差不多，可傳文件，傳輸協(xié)議TCP。

　　多個(gè)短連接，TCP協(xié)議傳輸，同步傳輸，適用常規(guī)的遠(yuǎn)程服務(wù)調(diào)用和rmi互操作。在依賴低版本的Common-Collections包，java序列化存在安全漏洞;

　?、躻ebservice：基于WebService的遠(yuǎn)程調(diào)用協(xié)議，集成CXF實(shí)現(xiàn)，提供和原生WebService的互操作。多個(gè)短連接，基于HTTP傳輸，同步傳輸，適用系統(tǒng)集成和跨語言調(diào)用;

　?、輍ttp：基于Http表單提交的遠(yuǎn)程調(diào)用協(xié)議，使用Spring的HttpInvoke實(shí)現(xiàn)。多個(gè)短連接，傳輸協(xié)議HTTP，傳入?yún)?shù)大小混合，提供者個(gè)數(shù)多于消費(fèi)者，需要給應(yīng)用程序和瀏覽器JS調(diào)用;

　?、辢essian：集成Hessian服務(wù)，基于HTTP通訊，采用Servlet暴露服務(wù)，Dubbo內(nèi)嵌Jetty作為服務(wù)器時(shí)默認(rèn)實(shí)現(xiàn)，提供與Hession服務(wù)互操作。多個(gè)短連接，同步HTTP傳輸，Hessian序列化，傳入?yún)?shù)較大，提供者大于消費(fèi)者，提供者壓力較大，可傳文件;

　?、適emcache：基于memcached實(shí)現(xiàn)的RPC協(xié)議

　?、?a title="redis" target="_blank" href="http://kemok4.com/redis/">redis：基于redis實(shí)現(xiàn)的RPC協(xié)議

　　9、dubbo推薦用什么協(xié)議?

　　默認(rèn)使用dubbo協(xié)議

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

　?、費(fèi)ulticast注冊中心：Multicast注冊中心不需要任何中心節(jié)點(diǎn)，只要廣播地址，就能進(jìn)行服務(wù)注冊和發(fā)現(xiàn)?；诰W(wǎng)絡(luò)中組播傳輸實(shí)現(xiàn);

　?、赯ookeeper注冊中心：基于分布式協(xié)調(diào)系統(tǒng)Zookeeper實(shí)現(xiàn)，采用Zookeeper的watch機(jī)制實(shí)現(xiàn)數(shù)據(jù)變更;

　?、踨edis注冊中心：基于redis實(shí)現(xiàn)，采用key/Map存儲，住key存儲服務(wù)名和類型，Map中key存儲服務(wù)URL，value服務(wù)過期時(shí)間?；趓edis的發(fā)布/訂閱模式通知數(shù)據(jù)變更;

　?、躍imple注冊中心

　　11、Dubbo的服務(wù)治理?

　?、龠^多的服務(wù)URL配置困難;

　　②負(fù)載均衡分配節(jié)點(diǎn)壓力過大的情況下也需要部署集群;

　?、鄯?wù)依賴混亂，啟動順序不清晰;

　?、苓^多服務(wù)導(dǎo)致性能指標(biāo)分析難度較大，需要監(jiān)控;

　　12、Dubbo的注冊中心集群掛掉，發(fā)布者和訂閱者之間還能通信么?

　　可以的，啟動dubbo時(shí)，消費(fèi)者會從zookeeper拉取注冊的生產(chǎn)者的地址接口等數(shù)據(jù)，緩存在本地。

　　每次調(diào)用時(shí)，按照本地存儲的地址進(jìn)行調(diào)用。

　　13、Dubbo與Spring的關(guān)系?

　　Dubbo采用全Spring配置方式，透明化接入應(yīng)用，對應(yīng)用沒有任何API侵入，只需用Spring加載Dubbo的配置即可，Dubbo基于Spring的Schema擴(kuò)展進(jìn)行加載。

　　14、Dubbo使用的是什么通信框架?

　　默認(rèn)使用NIO Netty框架

　　15、Dubbo集群提供了哪些負(fù)載均衡策略?

　?、賀andom LoadBalance：隨機(jī)選取提供者策略，有利于動態(tài)調(diào)整提供者權(quán)重。截面碰撞率高，調(diào)用次數(shù)越多，分布越均勻;

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

　?、跮eastActive LoadBalance：最少活躍調(diào)用策略，解決慢提供者接收更少的請求;

　?、蹸onstantHash LoadBalance：一致性Hash策略，使相同參數(shù)請求總是發(fā)到同一提供者，一臺機(jī)器宕機(jī)，可以基于虛擬節(jié)點(diǎn)，分?jǐn)傊疗渌峁┱?，避免引起提供者的劇烈變?

　　16、Dubbo的集群容錯(cuò)方案有哪些?

　　①Failover Cluster：失敗自動切換，當(dāng)出現(xiàn)失敗，重試其它服務(wù)器。通常用于讀操作，但重試會帶來更長延遲。

　　②Failfast Cluster：快速失敗，只發(fā)起一次調(diào)用，失敗立即報(bào)錯(cuò)。通常用于非冪等性的寫操作，比如新增記錄。

　　③Failsafe Cluster：失敗安全，出現(xiàn)異常時(shí)，直接忽略。通常用于寫入審計(jì)日志等操作。

　　④Failback Cluster：失敗自動恢復(fù)，后臺記錄失敗請求，定時(shí)重發(fā)。通常用于消息通知操作。

　　⑤Forking Cluster：并行調(diào)用多個(gè)服務(wù)器，只要一個(gè)成功即返回。通常用于實(shí)時(shí)性要求較高的讀操作，但需要浪費(fèi)更多服務(wù)資源?？赏ㄟ^ forks=”2″ 來設(shè)置最大并行數(shù)。

　?、轇roadcast Cluster：廣播調(diào)用所有提供者，逐個(gè)調(diào)用，任意一臺報(bào)錯(cuò)則報(bào)錯(cuò) 。通常用于通知所有提供者更新緩存或日志等本地資源信息。

　　17、Dubbo的默認(rèn)集群容錯(cuò)方案?

　　Failover Cluster

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

　　默認(rèn)使用Hessian序列化，還有Duddo、FastJson、Java自帶序列化。

　　19、Dubbo超時(shí)時(shí)間怎樣設(shè)置?

　　Dubbo超時(shí)時(shí)間設(shè)置有兩種方式：

　　①服務(wù)提供者端設(shè)置超時(shí)時(shí)間，在Dubbo的用戶文檔中，推薦如果能在服務(wù)端多配置就盡量多配置，因?yàn)榉?wù)提供者比消費(fèi)者更清楚自己提供的服務(wù)特性。

　?、诜?wù)消費(fèi)者端設(shè)置超時(shí)時(shí)間，如果在消費(fèi)者端設(shè)置了超時(shí)時(shí)間，以消費(fèi)者端為主，即優(yōu)先級更高。因?yàn)榉?wù)調(diào)用方設(shè)置超時(shí)時(shí)間控制性更靈活。如果消費(fèi)方超時(shí)，服務(wù)端線程不會定制，會產(chǎn)生警告。

　　20、服務(wù)調(diào)用超時(shí)問題怎么解決?

　　dubbo在調(diào)用服務(wù)不成功時(shí)，默認(rèn)是會重試兩次的。

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

　　Dubbo通過Token令牌防止用戶繞過注冊中心直連，然后在注冊中心上管理授權(quán)。Dubbo還提供服務(wù)黑白名單，來控制服務(wù)所允許的調(diào)用方。

　　22、dubbo和dubbox之間的區(qū)別?

　　dubbox基于dubbo上做了一些擴(kuò)展，如加了服務(wù)可restful調(diào)用，更新了開源組件等。

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

　　大家熟知的就是Spring cloud，當(dāng)然國外也有類似的多個(gè)框架。

　　24、Dubbo和Spring Cloud的關(guān)系?

　　Dubbo是SOA時(shí)代的產(chǎn)物，它的關(guān)注點(diǎn)主要在于服務(wù)的調(diào)用，流量分發(fā)、流量監(jiān)控和熔斷。而 Spring Cloud誕生于微服務(wù)架構(gòu)時(shí)代，考慮的是微服務(wù)治理的方方面面，另外由于依托了Spirng、Spirng Boot的優(yōu)勢之上，兩個(gè)框架在開始目標(biāo)就不一致，Dubbo定位服務(wù)治理、Spirng Cloud是一個(gè)生態(tài)。

　　25、dubbo和spring cloud的區(qū)別?

　　最大的區(qū)別：Dubbo底層是使用Netty這樣的NIO框架，是基于TCP協(xié)議傳輸?shù)?，配合以Hession序列化完成RPC通信。

　　而SpringCloud是基于Http協(xié)議+Rest接口調(diào)用遠(yuǎn)程過程的通信，相對來說，Http請求會有更大的報(bào)文，占的帶寬也會更多。但是REST相比RPC更為靈活，服務(wù)提供方和調(diào)用方的依賴只依靠一紙契約，不存在代碼級別的強(qiáng)依賴，這在強(qiáng)調(diào)快速演化的微服務(wù)環(huán)境下，顯得更為合適，至于注重通信速度還是方便靈活性，具體情況具體考慮。

“Dubbo面試題及答案有哪些”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識可以關(guān)注億速云網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實(shí)用文章！