什么是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)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。