Dubbo知識整理

原理

基礎概念

Dubbo就是SOA服務治理方案的核心框架。用於分佈式調用，其重點在於分佈式的治理。

Dubbo是Alibaba開源的分佈式服務框架，它最大的特色是按照分層的方式來架構，使用這種方式可使各個層之間解耦合（或者最大限度地鬆耦合），好比表現層和業務層就須要解耦合。

從面向服務的角度來看，Dubbo採用的是一種很是簡單的模型，要麼是提供方提供服務，要麼是消費方消費服務，因此基於這一點能夠抽象出服務提供方（Provider）和服務消費方（Consumer）兩個角色。

除了以上兩個角色，它還有註冊中心和監控中心。它能夠經過註冊中心對服務進行註冊和訂閱；能夠經過監控中心對服務進行監控，這樣的話，就能夠知道哪些服務使用率高、哪些服務使用率低。對使用率高的服務增長機器，對使用率低的服務減小機器，達到合理分配資源的目的。

Dubbo核心功能

一、Remoting：遠程通信，提供對多種NIO框架抽象封裝，包括「同步轉異步」和「請求-響應」模式的信息交換方式。
二、Cluster：服務框架，提供基於接口方法的透明遠程過程調用，包括多協議支持，以及軟負載均衡，失敗容錯，地址路由，動態配置等集羣支持。
三、Registry：服務註冊，基於註冊中心目錄服務，使服務消費方能動態的查找服務提供方，使地址透明，使服務提供方能夠平滑增長或減小機器。

Dubbo組件角色

Provider: 暴露服務的服務提供方。
Consumer: 調用遠程服務的服務消費方。
Registry: 服務註冊與發現的註冊中心。
Monitor: 統計服務的調用次調和調用時間的監控中心。
Container: 服務運行容器，常見的容器有Spring容器。

調用關係說明：

1. 服務容器負責啓動，加載，運行服務提供者。
2. 服務提供者在啓動時，向註冊中心註冊本身提供的服務。
3. 服務消費者在啓動時，向註冊中心訂閱本身所需的服務。
4. 註冊中心返回服務提供者地址列表給消費者，若是有變動，註冊中心將基於長鏈接推送變動數據給消費者。
5. 服務消費者，從提供者地址列表中，基於軟負載均衡算法，選一臺提供者進行調用，若是調用失敗，再選另外一臺調用。
6. 服務消費者和提供者，在內存中累計調用次數和調用時間，定時每分鐘發送一次統計數據到監控中心Monitor。

Dubbo整體架構

上面介紹給出的都是抽象層面的組件關係，能夠說是縱向的以服務模型的組件分析，其實Dubbo最大的特色是按照分層的方式來架構，使用這種方式可使各個層之間解耦合（或者最大限度地鬆耦合）。因此，咱們橫向以分層的方式來看下Dubbo的架構，如圖所示：

Dubbo框架設計一共劃分了10個層，而最上面的Service層是留給實際想要使用Dubbo開發分佈式服務的開發者實現業務邏輯的接口層。圖中左邊淡藍背景的爲服務消費方使用的接口，右邊淡綠色背景的爲服務提供方使用的接口， 位於中軸線上的爲雙方都用到的接口。

下面，結合Dubbo官方文檔，咱們分別理解一下框架分層架構中，各個層次的設計要點：

服務接口層（Service）：與實際業務邏輯相關的，根據服務提供方和服務消費方的 業務設計對應的接口和實現。
配置層（Config）：對外配置接口，以ServiceConfig和ReferenceConfig爲中心，能夠直接new配置類，也能夠經過Spring解析配置生成配置類。
服務代理層（Proxy）：服務接口透明代理，生成服務的客戶端Stub和服務器端Skeleton，以ServiceProxy爲中心，擴展接口爲ProxyFactory。
服務註冊層（Registry）：封裝服務地址的註冊與發現，以服務URL爲中心，擴展接口爲RegistryFactory、Registry和RegistryService。可能沒有服務註冊中心，此時服務提供方直接暴露服務。
集羣層（Cluster）：封裝多個提供者的路由及負載均衡，並橋接註冊中心，以Invoker爲中心，擴展接口爲Cluster、Directory、Router和LoadBalance。將多個服務提供方組合爲一個服務提供方，實現對服務消費方來透明，只須要與一個服務提供方進行交互。
監控層（Monitor）：RPC調用次數和調用時間監控，以Statistics爲中心，擴展接口爲MonitorFactory、Monitor和MonitorService。
遠程調用層（Protocol）：封將RPC調用，以Invocation和Result爲中心，擴展接口爲Protocol、Invoker和Exporter。Protocol是服務域，它是Invoker暴露和引用的主功能入口，它負責Invoker的生命週期管理。Invoker是實體域，它是Dubbo的核心模型，其它模型都向它靠擾，或轉換成它，它表明一個可執行體，可向它發起invoke調用，它有多是一個本地的實現，也多是一個遠程的實現，也可能一個集羣實現。
信息交換層（Exchange）：封裝請求響應模式，同步轉異步，以Request和Response爲中心，擴展接口爲Exchanger、ExchangeChannel、ExchangeClient和ExchangeServer。
網絡傳輸層（Transport）：抽象mina和netty爲統一接口，以Message爲中心，擴展接口爲Channel、Transporter、Client、Server和Codec。
數據序列化層（Serialize）：可複用的一些工具，擴展接口爲Serialization、 ObjectInput、ObjectOutput和ThreadPool。
從上圖能夠看出，Dubbo對於服務提供方和服務消費方，從框架的10層中分別提供了各自須要關心和擴展的接口，構建整個服務生態系統（服務提供方和服務消費方自己就是一個以服務爲中心的）。

根據官方提供的，對於上述各層之間關係的描述，以下所示：
一、在RPC中，Protocol是核心層，也就是隻要有Protocol + Invoker + Exporter就能夠完成非透明的RPC調用，而後在Invoker的主過程上Filter攔截點。

二、圖中的Consumer和Provider是抽象概念，只是想讓看圖者更直觀的瞭解哪些分類屬於客戶端與服務器端，不用Client和Server的緣由是Dubbo在不少場景下都使用Provider、Consumer、Registry、Monitor劃分邏輯拓普節點，保持概念統一。

三、而Cluster是外圍概念，因此Cluster的目的是將多個Invoker假裝成一個Invoker，這樣其它人只要關注Protocol層Invoker便可，加上Cluster或者去掉Cluster對其它層都不會形成影響，由於只有一個提供者時，是不須要Cluster的。

四、Proxy層封裝了全部接口的透明化代理，而在其它層都以Invoker爲中心，只有到了暴露給用戶使用時，才用Proxy將Invoker轉成接口，或將接口實現轉成Invoker，也就是去掉Proxy層RPC是能夠Run的，只是不那麼透明，不那麼看起來像調本地服務同樣調遠程服務。
五、而Remoting實現是Dubbo協議的實現，若是你選擇RMI協議，整個Remoting都不會用上，Remoting內部再劃爲Transport傳輸層和Exchange信息交換層，Transport層只負責單向消息傳輸，是對Mina、Netty、Grizzly的抽象，它也能夠擴展UDP傳輸，而Exchange層是在傳輸層之上封裝了Request-Response語義。

六、Registry和Monitor實際上不算一層，而是一個獨立的節點，只是爲了全局概覽，用層的方式畫在一塊兒。

服務調用流程

鏈接方式

一、直連：

不經過註冊中心，直接由消費者訪問提供者。

二、集羣：

提供者把服務註冊到註冊中心，而後消費者詢問註冊中心，請求對應的服務須要請求哪一個提供者，註冊中心返回結果，消費者根據結果向提供者請求服務。

三、超時和重連機制：

（1）dubbo超時，不會返回結果，直接報異常
（2）配置超時重試次數、超時時間：
    ```
        <!-- 服務調用超時設置爲5秒,超時不重試-->
        <dubbo:service interface="com.provider.service.DemoService" ref="demoService"  retries="0" timeout="5000"/>
    ```
（3）dubbo在調用服務不成功時，默認會重試2次。
    Dubbo的路由機制，會把超時的請求路由到其餘機器上，而不是本機嘗試，因此 dubbo的重試機器也能必定程度的保證服務的質量。可是若是不合理的配置重試次數，當失敗時會進行重試屢次，這樣在某個時間點出現性能問題，調用方再連續重複調用，系統請求變爲正常值的retries倍，系統壓力會大增，容易引發服務雪崩，須要根據業務狀況規劃好如何進行異常處理，什麼時候進行重試。

group及version

一、group：用於對服務進行隔離，這裏能夠實現灰度功能的做用。
二、version：當一個接口的實現，出現不兼容升級時，能夠用版本號過渡，版本號不一樣的服務相互間不引用

問題（走過的坑）

一、Dubbo調用接口，該接口拋出的運行時異常，在調用函數裏面沒法捕獲的
二、一個經典問題： Forbid consumer 127.0.0.1 access service com.mall.api.service.MallService from registry localhost:2181 use dubbo version 2.9.2-SNAPSHOT, Please check registry access list (whitelist/blacklist).

這個錯誤通常表面上說禁止消費服務，實際上開發人員並無作任何限制。其實，這個問題通常由兩種狀況引發的
（1）第一種狀況：沒有provider提供對應的服務
（2）第二種狀況：消費者消費的服務的「版本號 version」和生產者提供的服務的「版本號 version」不一致，或者沒有顯式說明版本號。

三、當dubbo超時，返回的結果會爲null四、dubbo若是報異常了，dubbo不會返回錯誤碼，所以須要在對外提供的接口處利用參數傳遞錯誤碼、錯誤信息五、在dubbo的provider和consumer的配置文件中，若是都配置了timeout的超時時間，dubbo默認以consumer中配置的時間爲準