Dubbo入门详细教程
什么是Dubbo?
Dubbo 是阿里開源的遠(yuǎn)程服務(wù)調(diào)用(RPC)的分布式框架,提供了 SOA 服務(wù)治理方案;它的架構(gòu)主要有五個角色/核心組件,分為是 Container(容器)、Provider(服務(wù)的提供方)、Registry(注冊中心)、Consumer(服務(wù)的消費方)、Monitor(監(jiān)控中心)。
容器主要負(fù)責(zé)啟動、加載、運行服務(wù)提供者;
同時服務(wù)提供者在啟動時,向注冊中心注冊自己提供的服務(wù);
消費者向注冊中心訂閱自己的服務(wù);注冊中心返回服務(wù)提供者列表給消費者,如果有變更,注冊中心將基于長連接推送變更數(shù)據(jù)給消費者;
對于服務(wù)消費者,從提供者地址列表中,基于軟負(fù)載均衡算法,選一臺提供者進(jìn)行調(diào)用,如果調(diào)用失敗,再選另外一臺調(diào)用;
服務(wù)消費者和提供者,在內(nèi)存中累計調(diào)用次數(shù)和調(diào)用時間,定時每分鐘發(fā)送一次統(tǒng)計數(shù)據(jù)到監(jiān)控中心;
Dubbo 在項目中主要用來實現(xiàn)不同系統(tǒng)之間的服務(wù)調(diào)用,由于項目是按照不同的功能分了不同的系統(tǒng),按照三層架構(gòu)又分了不同的服務(wù),其中三層架構(gòu)中的控制層作為服務(wù)的消費方,業(yè)務(wù)層和持久層共同作為服務(wù)的發(fā)布方,這樣的架構(gòu)實現(xiàn)了系統(tǒng)的服務(wù)化,提高了開發(fā)效率,實現(xiàn)了業(yè)務(wù)的解耦。
項目中通過 Dubbo 和 Spring 的整合,采用全 Spring 配置方式,只需要用 Spring 來加載Dubbo 的配置,完成了服務(wù)的發(fā)布和調(diào)用。
我們主要在服務(wù)的暴露方通過dubbo:service標(biāo)簽來暴露服務(wù),在服務(wù)的消費方通過dubbo:reference標(biāo)簽來引用服務(wù),注冊中心我們選用的是 zookeeper,對服務(wù)的URL進(jìn)行了管理和配置。
Dubbo 支持 Dubbo 協(xié)議、RMI 協(xié)議、hessian 協(xié)議、Http 協(xié)議等。
Dubbo 協(xié)議:缺省協(xié)議、采用了單一長連接和 NIO 異步通訊、使用線程池并發(fā)處理請求,能減少握手和加大并發(fā)效率、采用的是 Hession 二進(jìn)制序列化、性能較好,推薦使用。
主要應(yīng)用于傳入傳出參數(shù)數(shù)據(jù)包較小(建議小于 100K),消費者比提供者個數(shù)多,由于是單一連接,因為盡量不要傳輸大文件。
RMI 協(xié)議:采用 JDK 標(biāo)準(zhǔn)的 RMI 協(xié)議(基于 TCP 協(xié)議)、堵塞式短連接、JDK 標(biāo)準(zhǔn)序列化方式、同步通訊。
適用于消費者和提供者個數(shù)差不多的,可傳文件。測試發(fā)現(xiàn)偶爾會連接失敗,需要重建 Stub。
Hessian 協(xié)議:采用 http 通訊,采用 Servlet 暴露服務(wù),多連接短連接的同步傳輸方式,采用hession 的二進(jìn)制序列化,適合提供者比消費者多。
Dubbo入門詳細(xì)教程
Dubbo快速入門,Java分布式框架必會的dubbo教程
關(guān)于Dubbo面試題
【面試題1】Dubbo支持的協(xié)議、
dubbo(默認(rèn)):單一長連接和NIO異步通訊,適合大并發(fā)小數(shù)據(jù)量的服務(wù)調(diào)用,以及消費者遠(yuǎn)大于提供者。傳輸協(xié)議 TCP,異步,Hessian 序列化;
rmi:采用JDK標(biāo)準(zhǔn)的rmi協(xié)議實現(xiàn),傳輸參數(shù)和返回參數(shù)對象需要實現(xiàn)Serializable接口,使用java標(biāo)準(zhǔn)序列化機制,使用阻塞式短連接,傳輸數(shù)據(jù)包大小混合,消費者和提供者個數(shù)差不多,可傳文件,傳輸協(xié)議 TCP。多個短連接,TCP 協(xié)議傳輸,同步傳輸,適用常規(guī)的遠(yuǎn)程服務(wù)調(diào)用和 rmi 互操作。在依賴低版本的 Common-Collections包,java 序列化存在安全漏洞;
webservice:基于 WebService 的遠(yuǎn)程調(diào)用協(xié)議,集成 CXF 實現(xiàn),提供和原生 WebService 的互操作。多個短連接,基于 HTTP 傳輸,同步傳輸,適用系統(tǒng)集成和跨語言調(diào)用;
http:基于 Http 表單提交的遠(yuǎn)程調(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ù)器時默認(rèn)實現(xiàn),提供與Hession服務(wù)互操作。多個短連接,同步 HTTP 傳輸,Hessian 序列化,傳入?yún)?shù)較大,提供者大于消費者,提供者壓力較大,可傳文件;
memcache: 基于memcached實現(xiàn)的RPC協(xié)議
傳入傳出參數(shù)數(shù)據(jù)包較小(建議小于100K),消費者比提供者個數(shù)多,單一消費者無法壓滿提供者,盡量不要用dubbo協(xié)議傳輸大文件或超大字符串。
redis: 基于redis實現(xiàn)的RPC協(xié)議
【面試題2】Dubbo推薦用什么協(xié)議?使用該協(xié)議有哪些優(yōu)缺點?
傳入傳出參數(shù)數(shù)據(jù)包較小(建議小于100K),消費者比提供者個數(shù)多,單一消費者無法壓滿提供者,盡量不要用dubbo協(xié)議傳輸大文件或超大字符串。
【面試題3】Dubbo超時時間的設(shè)置
通過timeout屬性配置超時時間,服務(wù)的提供者和消費者都可以配置,盡量在服務(wù)提供者中配置,因為服務(wù)的提供者會對自己提供的服務(wù)情況更清楚超時時間不要設(shè)置太大(1~5S),會影響并發(fā)性能問題。
【面試題4】Dubbo自動重試機
Dubbo在調(diào)用服務(wù)不成功時,默認(rèn)會重試2次。Dubbo的路由機制,會把超時的請求路由到其他機器上,而不是本機嘗試,所以 dubbo的重試機制也能一定程度的保證服務(wù)的質(zhì)量
【面試題5】Dubbo支持的注冊中心
Multicast 注冊中心
Multicast 注冊中心不需要任何中心節(jié)點,只要廣播地址,就能進(jìn)行服務(wù)注冊和發(fā)現(xiàn)。基于網(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ù)過期時間。基于redis 的發(fā)布/訂閱模式通知數(shù)據(jù)變更;
【面試題6】Dubbo集群的負(fù)載均衡策略
隨機
按權(quán)重設(shè)置隨機概率。在一個截面上碰撞的概率高,但調(diào)用量越大分布越均勻,而且按概率使用權(quán)重后也比較均勻,有利于動態(tài)調(diào)整提供者權(quán)重。(權(quán)重可以在dubbo管控臺配置)
輪循
按公約后的權(quán)重設(shè)置輪循比率。存在慢的提供者累積請求問題,比如:第二臺機器很慢,但沒掛,當(dāng)請求調(diào)到第二臺時就卡在那,久而久之,所有請求都卡在調(diào)到第二臺上。
最少活躍調(diào)用數(shù)
相同活躍數(shù)的隨機,活躍數(shù)指調(diào)用前后計數(shù)差。使慢的提供者收到更少請求,因為越慢的提供者的調(diào)用前后計數(shù)差會越大。
一致性Hash
相同參數(shù)的請求總是發(fā)到同一提供者。當(dāng)某一臺提供者掛時,原本發(fā)往該提供者的請求,基于虛擬節(jié)點,平攤到其它提供者,不會引起劇烈變動。
【面試題7】Dubbo支持哪些序列化方式?
dubbo序列化:阿里尚未開發(fā)成熟的高效java序列化實現(xiàn),阿里不建議在生產(chǎn)環(huán)境使用它
hessian2序列化(默認(rèn)推薦):hessian是一種跨語言的高效二進(jìn)制序列化方式。但這里實際不是原生的hessian2序列化,而是阿里修改過的hessian lite,它是dubbo RPC默認(rèn)啟用的序列化方式
json序列化:目前有兩種實現(xiàn),一種是采用的阿里的fastjson庫,另一種是采用dubbo中自己實現(xiàn)的簡單json庫,但其實現(xiàn)都不是特別成熟,而且json這種文本序列化性能一般不如上面兩種二進(jìn)制序列化。
java序列化:主要是采用JDK自帶的Java序列化實現(xiàn),性能很不理想。
【面試題8】注冊中心宕機,服務(wù)間是否可以繼續(xù)通信
可以通信的,啟動dubbo時,消費者會從zk拉取注冊的生產(chǎn)者的地址接口等數(shù)據(jù),緩存在本地。每次調(diào)用時,按照本地存儲的地址進(jìn)行調(diào)用;
但前提是你沒有增加新的服務(wù),如果你要調(diào)用新的服務(wù),則是不能辦到的。
另外如果服務(wù)的提供者全部宕機,服務(wù)消費者會無法使用,并無限次重連等待服務(wù)者恢復(fù);
【面試題9】Dubbo與spring的關(guān)系
Dubbo采用全Spring 配置方式,透明化接入應(yīng)用,對應(yīng)用沒有任何API 侵入,只需用Spring加載Dubbo的配置即可。
【面試題10】Dubbo使用的是什么通信框架?
NIO Netty框架
【面試題11】Dubbo的集群容錯方案
Failover Cluster(默認(rèn)):
失敗自動切換,當(dāng)出現(xiàn)失敗,重試其它服務(wù)器。通常用于讀操作,但重試會帶來更長延遲。
Failfast Cluster
快速失敗,只發(fā)起一次調(diào)用,失敗立即報錯。通常用于非冪等性的寫操作,比如新增記錄。
Failsafe Cluster
失敗安全,出現(xiàn)異常時,直接忽略。通常用于寫入審計日志等操作。
Failback Cluster
失敗自動恢復(fù),后臺記錄失敗請求,定時重發(fā)。通常用于消息通知操作。
Forking Cluster
并行調(diào)用多個服務(wù)器,只要一個成功即返回。通常用于實時性要求較高的讀操作,但需要浪費更多服務(wù)資源。可通過 forks=“2” 來設(shè)置最大并行數(shù)。
Broadcast Cluster
廣播調(diào)用所有提供者,逐個調(diào)用,任意一臺報錯則報錯 。通常用于通知所有提供者更新緩存或日志等本地資源信息。
【面試題12】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)勢之上,兩個框架在開始目標(biāo)就不一致,Dubbo定位服務(wù)治理、Spirng Cloud 是一個生態(tài)。最大的區(qū)別:Dubbo 底層是使用 Netty 這樣的 NIO 框架,是基于TCP 協(xié)議傳輸?shù)?#xff0c;配合以 Hession 序列化完成 RPC 通信。而 SpringCloud 是基于 Http 協(xié)議+Rest 接口調(diào)用遠(yuǎn)程過程的通信,相對來說,Http 請求會有更大的報文,占的帶寬也會更多。但是REST相比RPC更為靈活,服務(wù)提供方和調(diào)用方的依賴只依靠一紙契約,不存在代碼級別的強依賴。
總結(jié)
以上是生活随笔為你收集整理的Dubbo入门详细教程的全部內(nèi)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: PMP读书笔记(第12章)
- 下一篇: poj 1201 差分约束