1、dubbo是什么

dubbo是一個分布式的服務框架，致力于提高性能和透明化的RPC遠程服務調用方案，以及SOA服務治理方案。

簡言之，dubbo就是一個服務框架，如果沒有分布式的需求，其實不需要用的，只有分布式的時候，才需要dubbo這樣的分布式框架

本質里，dubbo就是個服務調用的東東。。

說白了就是個遠程服務調用的分布式框架(告別webservice模式中的wsdl，以服務者與消費者的方式在dubbo上注冊)

dubbo可以和spring無縫集成

2、dubbo能干什么

1)透明化的遠程方法調用，就像調用本地方法一樣，只需簡單配置，沒有任何API侵入

2)軟負載均衡及容錯機制，可在內網(wǎng)替代F5等硬件負載均衡器，降低成本，減少單點

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

4)dubbo采用全spring配置方式，透明化接入應用，對應用沒有任何API侵入，只需spring加載dubbo的配置即可，dubbo基于spring的schema擴展進行加載

3、dubbo怎么用——即dubbo工作原理

dubbo的核心：

1)遠程通訊：提供多種基于長連接的NIO框架封裝，包括多線程模型，序列號，以及“請求-響應”模式的信息交換方式

2)集群容錯：提供基于接口方法的透明遠程過程調用，包括多協(xié)議支持，以及軟負載均衡，失敗容錯，地址路由，動態(tài)配置等集群支持

3)自動發(fā)現(xiàn)：基于注冊中心目錄服務，使服務消費方能夠動態(tài)查找服務提供方，使地址透明，使服務提供方可以平滑增加或減少機器

dubbo主要核心部件

Remoting：網(wǎng)絡通信框架，實現(xiàn)了sync-over-async和request-response消息機制。

RPC：一個遠程過程調用的抽象，支持負載均衡、容災和集群功能。

Registry：服務目錄框架用于服務的注冊和服務事件發(fā)布和訂閱。

dubbo核心架構圖：

角色說明：

provider:服務提供方

consumer:服務消費方

registry:服務注冊與發(fā)現(xiàn)的注冊中心

monitor:統(tǒng)計服務的調用次數(shù)和調用時間的監(jiān)控中心

container:服務運行容器

調用關系說明：

0.服務器負責啟動、加載、運行服務提供者

1.服務提供者在啟動時，向注冊中心注冊自己提供的服務

2.服務消費者在啟動時，向注冊中心訂閱自己所需的服務

3.注冊中心返回服務提供者地址列表給消費者，如果有變更，注冊中心將基于長連接推送變更數(shù)據(jù)給消費者

4.服務消費者，從提供者列表中，基于軟負載均衡算法，選一臺提供者進行調用，如果調用失敗，更換另一臺調用

5.服務消費者和服務提供者，在內存中累計調用次數(shù)和調用時間，定時每分鐘發(fā)送一次統(tǒng)計數(shù)據(jù)到監(jiān)控中心

4、dubbo怎么用

dubbo基于spring的schema擴展進行加載

服務提供者：

1)下載zookeeper注冊中心

2)定義服務接口(該接口需單獨打包，在服務提供方和消費方共享)

3)spring配置聲明暴露服務

//具體的實現(xiàn)Bean

<dubbo:application name="x_provider" /> //提供方信息

<dubbo:egister address="multicast://ip" />//multicast廣播注冊中心，暴露服務地址

<dubbo:register address="zookeeper://ip:2181" />//zookeeper注冊中心暴露服務地址

<dubbo:protocol name="dubbo" port="20880" />//用dubbo協(xié)議在20880端口暴露服務

<dubbo:service interface="..." ref="demoService"/>//聲明需暴露的服務接口

服務消費者：

applicationContext-dubbo.xml:注冊自己需要調用的接口(業(yè)務多了，按照業(yè)務將拆分成N多個applicationContext-dubbo-xxx.xml)

通過spring配置引用遠程服務

<dubbo:application name=".._consumer"/>//消費方應用名

<dubbo:register address="zookeeper://ip:2181"/>//使用zookeeper注冊中心暴露服務地址

<dubbo:reference id="demoService" interface="..demoService"/>//生成遠程服務代理，可以像使用本地bean一樣使用demoService

服務保護:

服務保護的原則上是避免發(fā)生類似雪崩效應，盡量將異常控制在服務周圍，不要擴散開。

說到雪崩效應，還得提下dubbo自身的重試機制，默認3次，當失敗時會進行重試，這樣在某個時間點出現(xiàn)性能問題，然后調用方再連續(xù)重復調用，很容易引起雪崩，建議的話還是很據(jù)業(yè)務情況規(guī)劃好如何進行異常處理，何時進行重試。

服務保護的話，目前我們主要從以下幾個方面來實施，也不成熟，還在摸索：

考慮服務的dubbo線程池類型（fix線程池的話考慮線程池大小）、數(shù)據(jù)庫連接池、dubbo連接數(shù)限制是否都合適

考慮服務超時時間和重試的關系，設置合適的值

一定時間內服務異常數(shù)較大，則可考慮使用failfast讓客戶端請求直接返回或者讓客戶端不再請求

zkclient問題

前文已經(jīng)提到過zkclient有兩個問題，修改服務器時間會導致容器掛掉；dubbo使用zkclient沒有傳超時時間導致zookeeper無法連接的時候，直接阻塞Integer.MAX_VALUE。

正在調研curator，目前只能說curator不會在無法連接的時候直接阻塞。

另外zkclient和curator的jar包應該都是jdk1.6編譯的，所以系統(tǒng)還在jdk1.5以下的話無法使用。

注冊中心的分組group和服務的不同實現(xiàn)group

這兩個東西完全不同的概念，使用的時候不要弄混了。

registry上可以配置group，用于區(qū)分不同分組的注冊中心，比如在同一個注冊中心下，有一部分注冊信息是要給開發(fā)環(huán)境用的，有一部分注冊信息時要給測試環(huán)境用的，可以分別用不同的group區(qū)分開，目前對這個理解還不透徹，大致就是用于區(qū)分不同環(huán)境。

service和reference上也可以配置group，這個用于區(qū)分同一個接口的不同實現(xiàn)，只有在reference上指定與service相同的group才會被發(fā)現(xiàn)，還有前文提到的分組合并結果也是用的這個。

5、dubbo的容錯方案

當我們的系統(tǒng)中用到Dubbo的集群環(huán)境,因為各種原因在集群調用失敗時，Dubbo提供了多種容錯方案，缺省為failover重試。

Dubbo的集群容錯在這里想說說他是因為我們實際的項目中出現(xiàn)了此類的問題,因為依賴的第三方項目出現(xiàn)異常,導致dubbo調用超時,此時使用的是默認的集群容錯方式,而配置的reties='3',這樣前段系統(tǒng)連續(xù)掉用了三次服務,結果可想而知.

先說一下各節(jié)點關系：

這里的Invoker是Provider的一個可調用Service的抽象，Invoker封裝了Provider地址及Service接口信息。

Directory代表多個Invoker，可以把它看成List，但與List不同的是，它的值可能是動態(tài)變化的，比如注冊中心推送變更。

Cluster將Directory中的多個Invoker偽裝成一個Invoker，對上層透明，偽裝過程包含了容錯邏輯，調用失敗后，重試另一個。

Router負責從多個Invoker中按路由規(guī)則選出子集，比如讀寫分離，應用隔離等。

LoadBalance負責從多個Invoker中選出具體的一個用于本次調用，選的過程包含了負載均衡算法，調用失敗后，需要重選。

集群容錯模式： Failover Cluster

失敗自動切換，當出現(xiàn)失敗，重試其它服務器。(缺省)

通常用于讀操作，但重試會帶來更長延遲。

可通過retries="2"來設置重試次數(shù)(不含第一次)。正是文章剛開始說的那種情況.

Failfast Cluster

快速失敗，只發(fā)起一次調用，失敗立即報錯。

通常用于非冪等性的寫操作，比如新增記錄。

Failsafe Cluster

失敗安全，出現(xiàn)異常時，直接忽略。

通常用于寫入審計日志等操作。

Failback Cluster

失敗自動恢復，后臺記錄失敗請求，定時重發(fā)。

通常用于消息通知操作。

Forking Cluster

并行調用多個服務器，只要一個成功即返回。

通常用于實時性要求較高的讀操作，但需要浪費更多服務資源。

可通過forks="2"來設置最大并行數(shù)。

Broadcast Cluster

廣播調用所有提供者，逐個調用，任意一臺報錯則報錯。(2.1.0開始支持)

通常用于通知所有提供者更新緩存或日志等本地資源信息。

重試次數(shù)配置如：(failover集群模式生效)

dubbo:serviceretries="2"/

或：dubbo:referenceretries="2"/

或：dubbo:reference

dubbo:methodname="findFoo"retries="2"/

</dubbo:reference>

集群模式配置如：

dubbo:servicecluster="failsafe"/

或：dubbo:referencecluster="failsafe"/

6、dubbo負載均衡策略

在集群負載均衡時，Dubbo提供了多種均衡策略，缺省為random隨機調用。

RandomLoadBalance

隨機，按權重設置隨機概率。

在一個截面上碰撞的概率高，但調用量越大分布越均勻，而且按概率使用權重后也比較均勻，有利于動態(tài)調整提供者權重。

RoundRobinLoadBalance

輪循，按公約后的權重設置輪循比率。

存在慢的提供者累積請求問題，比如：第二臺機器很慢，但沒掛，當請求調到第二臺時就卡在那，久而久之，所有請求都卡在調到第二臺上。

LeastActiveLoadBalance

最少活躍調用數(shù)，相同活躍數(shù)的隨機，活躍數(shù)指調用前后計數(shù)差。

使慢的提供者收到更少請求，因為越慢的提供者的調用前后計數(shù)差會越大。

ConsistentHashLoadBalance

一致性Hash，相同參數(shù)的請求總是發(fā)到同一提供者。

當某一臺提供者掛時，原本發(fā)往該提供者的請求，基于虛擬節(jié)點，平攤到其它提供者，不會引起劇烈變動。

Dubbo的集群容錯和負載均衡同樣也是Dubbo本身的高級特性.正如我們在說自定義擴展的時候一樣,這兩個特征同樣也可以進行自定義擴展,用戶可以根據(jù)自己實際的需求來擴展他們從而滿足項目的實際需求。

7、服務之間如何實現(xiàn)通信

1)同步調用

REST(JAX-RS，Spring Boot)

RPC(Thrift,Dubbo,HSF)

2)異步消息調用(kafka,Notify,NetaQ)

RESTFUL和RPC比較：

restful基于HTTP，更易實現(xiàn)，服務端技術更靈活，各語言都支持，跨客戶端，對客戶端無特殊要求，只需封裝HTTP的SDK就能調用

RPC:傳輸協(xié)議更高效，安全更可控

特別在一個公司內部，如果有統(tǒng)一的開發(fā)規(guī)范和統(tǒng)一的服務框架時，開發(fā)效率優(yōu)勢更明顯

同步：調用問題，性能差(特別是層次多時)

異步：減低調用服務之間的耦合，調用之間的緩沖，確保消息擠壓不會沖垮被調用方，同時保證調用方的服務體驗，繼續(xù)干自己該干的活，不至于被后臺性能拖慢，付出的代價是一致性的減弱，需要接受數(shù)據(jù)最終一致性，后臺服務一般要實現(xiàn)冪等性，因為消息發(fā)送處于性能的考慮一般會有重復；必須引入一個獨立的broker。

有興趣的朋友們可以前往球球：1903832579

轉載于:https://juejin.im/post/5b62b14b5188251b1e1fe857

總結

以上是生活随笔為你收集整理的dubbo详解的全部內容，希望文章能夠幫你解決所遇到的問題。

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