1、dubbo是什么

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

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

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

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

dubbo可以和spring無縫集成

2、dubbo能干什么

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

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

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

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

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

dubbo的核心：

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

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

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

dubbo主要核心部件

Remoting：網絡通信框架，實現了sync-over-async和request-response消息機制。

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

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

dubbo核心架構圖：

角色說明：

provider:服務提供方

consumer:服務消費方

registry:服務注冊與發現的注冊中心

monitor:統計服務的調用次數和調用時間的監控中心

container:服務運行容器

調用關系說明：

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

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

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

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

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

5.服務消費者和服務提供者，在內存中累計調用次數和調用時間，定時每分鐘發送一次統計數據到監控中心

4、dubbo怎么用

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

服務提供者：

1)下載zookeeper注冊中心

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

3)spring配置聲明暴露服務

//具體的實現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協議在20880端口暴露服務

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

服務消費者：

applicationContext-dubbo.xml:注冊自己需要調用的接口(業務多了，按照業務將拆分成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

服務保護:

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

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

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

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

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

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

zkclient問題

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

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

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

注冊中心的分組group和服務的不同實現group

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

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

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

5、dubbo的容錯方案

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

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

先說一下各節點關系：

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

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

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

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

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

集群容錯模式： Failover Cluster

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

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

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

Failfast Cluster

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

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

Failsafe Cluster

失敗安全，出現異常時，直接忽略。

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

Failback Cluster

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

通常用于消息通知操作。

Forking Cluster

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

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

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

Broadcast Cluster

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

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

重試次數配置如：(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

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

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

RoundRobinLoadBalance

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

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

LeastActiveLoadBalance

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

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

ConsistentHashLoadBalance

一致性Hash，相同參數的請求總是發到同一提供者。

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

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

7、服務之間如何實現通信

1)同步調用

REST(JAX-RS，Spring Boot)

RPC(Thrift,Dubbo,HSF)

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

RESTFUL和RPC比較：

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

RPC:傳輸協議更高效，安全更可控

特別在一個公司內部，如果有統一的開發規范和統一的服務框架時，開發效率優勢更明顯

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

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

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

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

總結

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

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