dubbo詳解

一、dubbo是什麼

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

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

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

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

dubbo能夠和spring無縫集成

二、dubbo能幹什麼

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

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

3)服務自動註冊與發現，再也不須要寫死服務提供方地址，註冊中心基於接口名查詢服務提供者的IP地址，而且可以平滑添加或刪除服務提供者

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

三、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.服務消費者和服務提供者，在內存中累計調用次數和調用時間，定時每分鐘發送一次統計數據到監控中心

四、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纔會被發現，還有前文提到的分組合並結果也是用的這個。

五、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"/

六、dubbo負載均衡策略

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

RandomLoadBalance

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

在一個截面上碰撞的機率高，但調用量越大分佈越均勻，並且按機率使用權重後也比較均勻，有利於動態調整提供者權重。

RoundRobinLoadBalance

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

存在慢的提供者累積請求問題，好比：第二臺機器很慢，但沒掛，當請求調到第二臺時就卡在那，長此以往，全部請求都卡在調到第二臺上。

LeastActiveLoadBalance

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

使慢的提供者收到更少請求，由於越慢的提供者的調用先後計數差會越大。

ConsistentHashLoadBalance

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

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

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

七、服務之間如何實現通訊

1)同步調用

REST(JAX-RS，Spring Boot)

RPC(Thrift,Dubbo,HSF)

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

RESTFUL和RPC比較：

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

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

特別在一個公司內部，若是有統一的開發規範和統一的服務框架時，開發效率優點更明顯

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

異步：減低調用服務之間的耦合，調用之間的緩衝，確保消息擠壓不會沖垮被調用方，同時保證調用方的服務體驗，繼續幹本身該乾的活，不至於被後臺性能拖慢，付出的代價是一致性的減弱，須要接受數據最終一致性，後臺服務通常要實現冪等性，由於消息發送處於性能的考慮通常會有重複；必須引入一個獨立的broker。

有興趣的朋友們能夠前往球球：1903832579