您好,登錄后才能下訂單哦!
本篇內(nèi)容介紹了“Dubbo的核心功能是什么”的有關(guān)知識,在實際案例的操作過程中,不少人都會遇到這樣的困境,接下來就讓小編帶領(lǐng)大家學習一下如何處理這些情況吧!希望大家仔細閱讀,能夠?qū)W有所成!
1.Dubbo是什么?
Dubbo 是一個分布式、高性能、透明化的 RPC 服務(wù)框架,提供服務(wù)自動注冊、自動發(fā)現(xiàn)等高效服務(wù)治理方案, 可以和 Spring 框架無縫集成。
RPC 指的是遠程調(diào)用協(xié)議,也就是說兩個服務(wù)器交互數(shù)據(jù)。
2.Dubbo的由來?
互聯(lián)網(wǎng)的快速發(fā)展,Web應(yīng)用程序的規(guī)模不斷擴大,一般會經(jīng)歷如下四個發(fā)展階段。
單一應(yīng)用架構(gòu)
當網(wǎng)站流量很小時,只需一個應(yīng)用,將所有功能都部署在一起即可。
垂直應(yīng)用架構(gòu)
當訪問量逐漸增大,單一應(yīng)用按照有業(yè)務(wù)線拆成多個應(yīng)用,以提升效率。
此時,用于加速前端頁面開發(fā)的 Web框架(MVC) 是關(guān)鍵。
分布式服務(wù)架構(gòu)
當垂直應(yīng)用越來越多,應(yīng)用之間交互不可避免,將核心業(yè)務(wù)抽取出來,作為獨立的服務(wù),逐漸形成穩(wěn)定的服務(wù)中心,使前端應(yīng)用能更快速的響應(yīng)多變的市場需求。
此時,用于提高業(yè)務(wù)復用及整合的 分布式服務(wù)框架(RPC) 是關(guān)鍵。
流動計算架構(gòu)
當服務(wù)越來越多,容量的評估,小服務(wù)資源的浪費等問題逐漸顯現(xiàn),此時需增加一個調(diào)度中心基于訪問壓力實時管理集群容量,提高集群利用率。
此時,用于提高機器利用率的 資源調(diào)度和治理中心(SOA) 是關(guān)鍵。
3.Dubbo的主要應(yīng)用場景?
透明化的遠程方法調(diào)用,就像調(diào)用本地方法一樣調(diào)用遠程方法,只需簡單配置,沒有任何API侵入。
軟負載均衡及容錯機制,可在內(nèi)網(wǎng)替代F5等硬件負載均衡器,降低成本,減少單點。
服務(wù)自動注冊與發(fā)現(xiàn),不再需要寫死服務(wù)提供方地址,注冊中心基于接口名查詢服務(wù)提供者的IP地址,并且能夠平滑添加或刪除服務(wù)提供者。
4.Dubbo的核心功能?
主要就是如下3個核心功能:
Remoting:網(wǎng)絡(luò)通信框架,提供對多種NIO框架抽象封裝,包括“同步轉(zhuǎn)異步”和“請求-響應(yīng)”模式的信息交換方式。
Cluster:服務(wù)框架,提供基于接口方法的透明遠程過程調(diào)用,包括多協(xié)議支持,以及軟負載均衡,失敗容錯,地址路由,動態(tài)配置等集群支持。
Registry:服務(wù)注冊,基于注冊中心目錄服務(wù),使服務(wù)消費方能動態(tài)的查找 服務(wù)提供方,使地址透明,使服務(wù)提供方可以平滑增加或減少機器。
5.Dubbo的核心組件?
6.Dubbo服務(wù)注冊與發(fā)現(xiàn)的流程?
流程說明:
Provider(提供者)綁定指定端口并啟動服務(wù)
指供者連接注冊中心,并發(fā)本機IP、端口、應(yīng)用信息和提供服務(wù)信息發(fā)送至注冊中心存儲
Consumer(消費者),連接注冊中心 ,并發(fā)送應(yīng)用信息、所求服務(wù)信息至注冊中心
注冊中心根據(jù) 消費 者所求服務(wù)信息匹配對應(yīng)的提供者列表發(fā)送至Consumer 應(yīng)用緩存。
Consumer 在發(fā)起遠程調(diào)用時基于緩存的消費者列表擇其一發(fā)起調(diào)用。
Provider 狀態(tài)變更會實時通知注冊中心、在由注冊中心實時推送至Consumer
設(shè)計的原因:
Consumer 與Provider 解偶,雙方都可以橫向增減節(jié)點數(shù)。
注冊中心對本身可做對等集群,可動態(tài)增減節(jié)點,并且任意一臺宕掉后,將自動切換到另一臺
去中心化,雙方不直接依懶注冊中心,即使注冊中心全部宕機短時間內(nèi)也不會影響服務(wù)的調(diào)用
服務(wù)提供者無狀態(tài),任意一臺宕掉后,不影響使用
image
7.Dubbo的架構(gòu)設(shè)計?
Dubbo框架設(shè)計一共劃分了10個層:
服務(wù)接口層(Service):該層是與實際業(yè)務(wù)邏輯相關(guān)的,根據(jù)服務(wù)提供方和服務(wù)消費方的業(yè)務(wù)設(shè)計對應(yīng)的接口和實現(xiàn)。
配置層(Config):對外配置接口,以ServiceConfig和ReferenceConfig為中心。
服務(wù)代理層(Proxy):服務(wù)接口透明代理,生成服務(wù)的客戶端Stub和服務(wù)器端Skeleton。
服務(wù)注冊層(Registry):封裝服務(wù)地址的注冊與發(fā)現(xiàn),以服務(wù)URL為中心。
集群層(Cluster):封裝多個提供者的路由及負載均衡,并橋接注冊中心,以Invoker為中心。
監(jiān)控層(Monitor):RPC調(diào)用次數(shù)和調(diào)用時間監(jiān)控。
遠程調(diào)用層(Protocol):封將RPC調(diào)用,以Invocation和Result為中心,擴展接口為Protocol、Invoker和Exporter。
信息交換層(Exchange):封裝請求響應(yīng)模式,同步轉(zhuǎn)異步,以Request和Response為中心。
網(wǎng)絡(luò)傳輸層(Transport):抽象mina和netty為統(tǒng)一接口,以Message為中心。
8.Dubbo的服務(wù)調(diào)用流程?
9.Dubbo支持哪些協(xié)議,每種協(xié)議的應(yīng)用場景,優(yōu)缺點?
dubbo: 單一長連接和NIO異步通訊,適合大并發(fā)小數(shù)據(jù)量的服務(wù)調(diào)用,以及消費者遠大于提供者。傳輸協(xié)議TCP,異步,Hessian序列化;
rmi:
采用JDK標準的rmi協(xié)議實現(xiàn),傳輸參數(shù)和返回參數(shù)對象需要實現(xiàn)Serializable接口,使用java標準序列化機制,使用阻塞式短連接,傳輸數(shù)據(jù)包大小混合,消費者和提供者個數(shù)差不多,可傳文件,傳輸協(xié)議TCP。
多個短連接,TCP協(xié)議傳輸,同步傳輸,適用常規(guī)的遠程服務(wù)調(diào)用和rmi互操作。在依賴低版本的Common-Collections包,java序列化存在安全漏洞;
webservice: 基于WebService的遠程調(diào)用協(xié)議,集成CXF實現(xiàn),提供和原生WebService的互操作。多個短連接,基于HTTP傳輸,同步傳輸,適用系統(tǒng)集成和跨語言調(diào)用;
http: 基于Http表單提交的遠程調(diào)用協(xié)議,使用Spring的HttpInvoke實現(xiàn)。多個短連接,傳輸協(xié)議HTTP,傳入?yún)?shù)大小混合,提供者個數(shù)多于消費者,需要給應(yīng)用程序和瀏覽器JS調(diào)用;
hessian: 集成Hessian服務(wù),基于HTTP通訊,采用Servlet暴露服務(wù),Dubbo內(nèi)嵌Jetty作為服務(wù)器時默認實現(xiàn),提供與Hession服務(wù)互操作。多個短連接,同步HTTP傳輸,Hessian序列化,傳入?yún)?shù)較大,提供者大于消費者,提供者壓力較大,可傳文件;
memcache: 基于memcached實現(xiàn)的RPC協(xié)議
redis: 基于redis實現(xiàn)的RPC協(xié)議
10.dubbo推薦用什么協(xié)議?
默認使用dubbo協(xié)議
11.Dubbo有些哪些注冊中心?
Multicast注冊中心: Multicast注冊中心不需要任何中心節(jié)點,只要廣播地址,就能進行服務(wù)注冊和發(fā)現(xiàn)?;诰W(wǎng)絡(luò)中組播傳輸實現(xiàn);
Zookeeper注冊中心: 基于分布式協(xié)調(diào)系統(tǒng)Zookeeper實現(xiàn),采用Zookeeper的watch機制實現(xiàn)數(shù)據(jù)變更;
redis注冊中心: 基于redis實現(xiàn),采用key/Map存儲,住key存儲服務(wù)名和類型,Map中key存儲服務(wù)URL,value服務(wù)過期時間?;趓edis的發(fā)布/訂閱模式通知數(shù)據(jù)變更;
Simple注冊中心
Java架構(gòu)/分布式:705127209(大牛交流群)沒有開發(fā)經(jīng)驗勿加!
12.Dubbo的服務(wù)治理?
過多的服務(wù)URL配置困難
負載均衡分配節(jié)點壓力過大的情況下也需要部署集群
服務(wù)依賴混亂,啟動順序不清晰
過多服務(wù)導致性能指標分析難度較大,需要監(jiān)控
13.Dubbo的注冊中心集群掛掉,發(fā)布者和訂閱者之間還能通信么?
可以的,啟動dubbo時,消費者會從zookeeper拉取注冊的生產(chǎn)者的地址接口等數(shù)據(jù),緩存在本地。
每次調(diào)用時,按照本地存儲的地址進行調(diào)用。
Java架構(gòu)/分布式:705 127 209釦 ?(大牛架構(gòu)圈子)
Dubbo采用全Spring配置方式,透明化接入應(yīng)用,對應(yīng)用沒有任何API侵入,只需用Spring加載Dubbo的配置即可,Dubbo基于Spring的Schema擴展進行加載。
15.Dubbo使用的是什么通信框架?
默認使用NIO Netty框架
16.Dubbo集群提供了哪些負載均衡策略?
Random LoadBalance: 隨機選取提供者策略,有利于動態(tài)調(diào)整提供者權(quán)重。截面碰撞率高,調(diào)用次數(shù)越多,分布越均勻;
RoundRobin LoadBalance: 輪循選取提供者策略,平均分布,但是存在請求累積的問題;
LeastActive LoadBalance: 最少活躍調(diào)用策略,解決慢提供者接收更少的請求;
ConstantHash LoadBalance: 一致性Hash策略,使相同參數(shù)請求總是發(fā)到同一提供者,一臺機器宕機,可以基于虛擬節(jié)點,分攤至其他提供者,避免引起提供者的劇烈變動;
缺省時為Random隨機調(diào)用
17.Dubbo的集群容錯方案有哪些?
Failover Cluster
失敗自動切換,當出現(xiàn)失敗,重試其它服務(wù)器。通常用于讀操作,但重試會帶來更長延遲。
Failfast Cluster
快速失敗,只發(fā)起一次調(diào)用,失敗立即報錯。通常用于非冪等性的寫操作,比如新增記錄。
Failsafe Cluster
失敗安全,出現(xiàn)異常時,直接忽略。通常用于寫入審計日志等操作。
Failback Cluster
失敗自動恢復,后臺記錄失敗請求,定時重發(fā)。通常用于消息通知操作。
Forking Cluster
并行調(diào)用多個服務(wù)器,只要一個成功即返回。通常用于實時性要求較高的讀操作,但需要浪費更多服務(wù)資源。可通過 forks=”2″ 來設(shè)置最大并行數(shù)。
Broadcast Cluster
廣播調(diào)用所有提供者,逐個調(diào)用,任意一臺報錯則報錯 。通常用于通知所有提供者更新緩存或日志等本地資源信息。
18.Dubbo的默認集群容錯方案?
Failover Cluster
19.Dubbo支持哪些序列化方式?
默認使用Hessian序列化,還有Duddo、FastJson、Java自帶序列化。
20.Dubbo超時時間怎樣設(shè)置?
Dubbo超時時間設(shè)置有兩種方式:
服務(wù)提供者端設(shè)置超時時間,在Dubbo的用戶文檔中,推薦如果能在服務(wù)端多配置就盡量多配置,因為服務(wù)提供者比消費者更清楚自己提供的服務(wù)特性。
服務(wù)消費者端設(shè)置超時時間,如果在消費者端設(shè)置了超時時間,以消費者端為主,即優(yōu)先級更高。因為服務(wù)調(diào)用方設(shè)置超時時間控制性更靈活。如果消費方超時,服務(wù)端線程不會定制,會產(chǎn)生警告。
21.服務(wù)調(diào)用超時問題怎么解決?
dubbo在調(diào)用服務(wù)不成功時,默認是會重試兩次的。
22.Dubbo在安全機制方面是如何解決?
Dubbo通過Token令牌防止用戶繞過注冊中心直連,然后在注冊中心上管理授權(quán)。Dubbo還提供服務(wù)黑白名單,來控制服務(wù)所允許的調(diào)用方。
23.dubbo 和 dubbox 之間的區(qū)別?
dubbox 基于 dubbo 上做了一些擴展,如加了服務(wù)可 restful 調(diào)用,更新了開源組件等。
24.除了Dubbo還有哪些分布式框架?
大家熟知的就是Spring cloud,當然國外也有類似的多個框架。
25.Dubbo和Spring Cloud的關(guān)系?
Dubbo
是 SOA 時代的產(chǎn)物,它的關(guān)注點主要在于服務(wù)的調(diào)用,流量分發(fā)、流量監(jiān)控和熔斷。而 Spring Cloud
誕生于微服務(wù)架構(gòu)時代,考慮的是微服務(wù)治理的方方面面,另外由于依托了 Spirng、Spirng Boot
的優(yōu)勢之上,兩個框架在開始目標就不一致,Dubbo 定位服務(wù)治理、Spirng Cloud 是一個生態(tài)。
26.dubbo和spring cloud的區(qū)別?
最大的區(qū)別:Dubbo底層是使用Netty這樣的NIO框架,是基于TCP協(xié)議傳輸?shù)?,配合以Hession序列化完成RPC通信。
而SpringCloud是基于Http協(xié)議+Rest接口調(diào)用遠程過程的通信,相對來說,Http請求會有更大的報文,占的帶寬也會更多。但是REST相比RPC更為靈活,服務(wù)提供方和調(diào)用方的依賴只依靠一紙契約,不存在代碼級別的強依賴,這在強調(diào)快速演化的微服務(wù)環(huán)境下,顯得更為合適,至于注重通信速度還是方便靈活性,具體情況具體考慮。
“Dubbo的核心功能是什么”的內(nèi)容就介紹到這里了,感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識可以關(guān)注億速云網(wǎng)站,小編將為大家輸出更多高質(zhì)量的實用文章!
免責聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉(zhuǎn)載和分享為主,文章觀點不代表本網(wǎng)站立場,如果涉及侵權(quán)請聯(lián)系站長郵箱:is@yisu.com進行舉報,并提供相關(guān)證據(jù),一經(jīng)查實,將立刻刪除涉嫌侵權(quán)內(nèi)容。