專案地址：http://code.alibabatech.com/wiki/display/dubbo/Home-zh

自開源後，已有不少非阿里系公司在使用Dubbo，參見：已知使用者

那麼，Dubbo是什麼？

Dubbo[]是一個分散式服務框架，致力於提供高效能和透明化的RPC遠端服務呼叫方案，以及SOA服務治理方案。

其核心部分包含:

• 遠端通訊: 提供對多種基於長連線的NIO框架抽象封裝，包括多種執行緒模型，序列化，以及“請求-響應”模式的資訊交換方式。
• 叢集容錯: 提供基於介面方法的透明遠端過程呼叫，包括多協議支援，以及軟負載均衡，失敗容錯，地址路由，動態配置等叢集支援。
• 自動發現: 基於註冊中心目錄服務，使服務消費方能動態的查詢服務提供方，使地址透明，使服務提供方可以平滑增加或減少機器。

Dubbo能做什麼？

• 透明化的遠端方法呼叫，就像呼叫本地方法一樣呼叫遠端方法，只需簡單配置，沒有任何API侵入。
• 軟負載均衡及容錯機制，可在內網替代F5等硬體負載均衡器，降低成本，減少單點。
• 服務自動註冊與發現，不再需要寫死服務提供方地址，註冊中心基於介面名查詢服務提供者的IP地址，並且能夠平滑新增或刪除服務提供者。

背景

(#)

隨著網際網路的發展，網站應用的規模不斷擴大，常規的垂直應用架構已無法應對，分散式服務架構以及流動計算架構勢在必行，亟需一個治理系統確保架構有條不紊的演進。

• 單一應用架構
  • 當網站流量很小時，只需一個應用，將所有功能都部署在一起，以減少部署節點和成本。
  • 此時，用於簡化增刪改查工作量的 資料訪問框架(ORM)
    是關鍵。
• 垂直應用架構
  • 當訪問量逐漸增大，單一應用增加機器帶來的加速度越來越小，將應用拆成互不相干的幾個應用，以提升效率。
  • 此時，用於加速前端頁面開發的 Web框架(MVC) 是關鍵。
• 分散式服務架構
  • 當垂直應用越來越多，應用之間互動不可避免，將核心業務抽取出來，作為獨立的服務，逐漸形成穩定的服務中心，使前端應用能更快速的響應多變的市場需求。
  • 此時，用於提高業務複用及整合的 分散式服務框架(RPC) 是關鍵。
• 流動計算架構
  • 當服務越來越多，容量的評估，小服務資源的浪費等問題逐漸顯現，此時需增加一個排程中心基於訪問壓力實時管理叢集容量，提高叢集利用率。
  • 此時，用於提高機器利用率的 資源排程和治理中心(SOA)
    是關鍵。

需求

(#)

在大規模服務化之前，應用可能只是通過RMI或Hessian等工具，簡單的暴露和引用遠端服務，通過配置服務的URL地址進行呼叫，通過F5等硬體進行負載均衡。

(1) 當服務越來越多時，服務URL配置管理變得非常困難，F5硬體負載均衡器的單點壓力也越來越大。

此時需要一個服務註冊中心，動態的註冊和發現服務，使服務的位置透明。

並通過在消費方獲取服務提供方地址列表，實現軟負載均衡和Failover，降低對F5硬體負載均衡器的依賴，也能減少部分成本。

(2) 當進一步發展，服務間依賴關係變得錯蹤複雜，甚至分不清哪個應用要在哪個應用之前啟動，架構師都不能完整的描述應用的架構關係。

這時，需要自動畫出應用間的依賴關係圖，以幫助架構師理清理關係。

(3) 接著，服務的呼叫量越來越大，服務的容量問題就暴露出來，這個服務需要多少機器支撐？什麼時候該加機器？

為了解決這些問題，第一步，要將服務現在每天的呼叫量，響應時間，都統計出來，作為容量規劃的參考指標。

其次，要可以動態調整權重，在線上，將某臺機器的權重一直加大，並在加大的過程中記錄響應時間的變化，直到響應時間到達閥值，記錄此時的訪問量，再以此訪問量乘以機器數反推總容量。

以上是Dubbo最基本的幾個需求，更多服務治理問題參見：

架構

(#)

節點角色說明：

• Provider: 暴露服務的服務提供方。
• Consumer: 呼叫遠端服務的服務消費方。
• Registry: 服務註冊與發現的註冊中心。
• Monitor: 統計服務的呼叫次調和呼叫時間的監控中心。
• Container: 服務執行容器。

呼叫關係說明：

• 0. 服務容器負責啟動，載入，執行服務提供者。
• 1. 服務提供者在啟動時，向註冊中心註冊自己提供的服務。
• 2. 服務消費者在啟動時，向註冊中心訂閱自己所需的服務。
• 3. 註冊中心返回服務提供者地址列表給消費者，如果有變更，註冊中心將基於長連線推送變更資料給消費者。
• 4. 服務消費者，從提供者地址列表中，基於軟負載均衡演算法，選一臺提供者進行呼叫，如果呼叫失敗，再選另一臺呼叫。
• 5. 服務消費者和提供者，在記憶體中累計呼叫次數和呼叫時間，定時每分鐘傳送一次統計資料到監控中心。

(1) 連通性：

• 註冊中心負責服務地址的註冊與查詢，相當於目錄服務，服務提供者和消費者只在啟動時與註冊中心互動，註冊中心不轉發請求，壓力較小
• 監控中心負責統計各服務呼叫次數，呼叫時間等，統計先在記憶體彙總後每分鐘一次傳送到監控中心伺服器，並以報表展示
• 服務提供者向註冊中心註冊其提供的服務，並彙報呼叫時間到監控中心，此時間不包含網路開銷
• 服務消費者向註冊中心獲取服務提供者地址列表，並根據負載演算法直接呼叫提供者，同時彙報呼叫時間到監控中心，此時間包含網路開銷
• 註冊中心，服務提供者，服務消費者三者之間均為長連線，監控中心除外
• 註冊中心通過長連線感知服務提供者的存在，服務提供者宕機，註冊中心將立即推送事件通知消費者
• 註冊中心和監控中心全部宕機，不影響已執行的提供者和消費者，消費者在本地快取了提供者列表
• 註冊中心和監控中心都是可選的，服務消費者可以直連服務提供者

(2) 健狀性：

• 監控中心宕掉不影響使用，只是丟失部分取樣資料
• 資料庫宕掉後，註冊中心仍能通過快取提供服務列表查詢，但不能註冊新服務
• 註冊中心對等叢集，任意一臺宕掉後，將自動切換到另一臺
• 註冊中心全部宕掉後，服務提供者和服務消費者仍能通過本地快取通訊
• 服務提供者無狀態，任意一臺宕掉後，不影響使用
• 服務提供者全部宕掉後，服務消費者應用將無法使用，並無限次重連等待服務提供者恢復

(3) 伸縮性：

• 註冊中心為對等叢集，可動態增加機器部署例項，所有客戶端將自動發現新的註冊中心
• 服務提供者無狀態，可動態增加機器部署例項，註冊中心將推送新的服務提供者資訊給消費者

(4) 升級性：

• 當服務叢集規模進一步擴大，帶動IT治理結構進一步升級，需要實現動態部署，進行流動計算，現有分散式服務架構不會帶來阻力：

• Deployer: 自動部署服務的本地代理。
• Repository: 倉庫用於儲存服務應用釋出包。
• Scheduler: 排程中心基於訪問壓力自動增減服務提供者。
• Admin: 統一管理控制檯。

Dubbo架構流程圖：

整體設計

圖例說明：

• 圖中左邊淡藍背景的為服務消費方使用的介面，右邊淡綠色背景的為服務提供方使用的介面， 位於中軸線上的為雙方都用到的介面。
• 圖中從下至上分為十層，各層均為單向依賴，右邊的黑色箭頭代表層之間的依賴關係，每一層都可以剝離上層被複用，其中，Service和Config層為API，其它各層均為SPI。
• 圖中綠色小塊的為擴充套件介面，藍色小塊為實現類，圖中只顯示用於關聯各層的實現類。
• 圖中藍色虛線為初始化過程，即啟動時組裝鏈，紅色實線為方法呼叫過程，即執行時調時鏈，紫色三角箭頭為繼承，可以把子類看作父類的同一個節點，線上的文字為呼叫的方法。

各層說明：

• 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
• exchange，資訊交換層，封裝請求響應模式，同步轉非同步，以Request, Response為中心，擴充套件介面為Exchanger, ExchangeChannel, ExchangeClient, ExchangeServer
• transport，網路傳輸層，抽象mina和netty為統一介面，以Message為中心，擴充套件介面為Channel, Transporter, Client, Server, Codec
• serialize，資料序列化層，可複用的一些工具，擴充套件介面為Serialization, ObjectInput, ObjectOutput, ThreadPool

關係說明：

• 在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實際上不算一層，而是一個獨立的節點，只是為了全域性概覽，用層的方式畫在一起。

模組分包

模組說明：

• dubbo-common 公共邏輯模組，包括Util類和通用模型。
• dubbo-remoting 遠端通訊模組，相當於Dubbo協議的實現，如果RPC用RMI協議則不需要使用此包。
• dubbo-rpc 遠端呼叫模組，抽象各種協議，以及動態代理，只包含一對一的呼叫，不關心叢集的管理。
• dubbo-cluster 叢集模組，將多個服務提供方偽裝為一個提供方，包括：負載均衡, 容錯，路由等，叢集的地址列表可以是靜態配置的，也可以是由註冊中心下發。
• dubbo-registry 註冊中心模組，基於註冊中心下發地址的叢集方式，以及對各種註冊中心的抽象。
• dubbo-monitor 監控模組，統計服務呼叫次數，呼叫時間的，呼叫鏈跟蹤的服務。
• dubbo-config 配置模組，是Dubbo對外的API，使用者通過Config使用Dubbo，隱藏Dubbo所有細節。
• dubbo-container 容器模組，是一個Standlone的容器，以簡單的Main載入Spring啟動，因為服務通常不需要Tomcat/JBoss等Web容器的特性，沒必要用Web容器去載入服務。

整體上按照分層結構進行分包，與分層的不同點在於：

• container為服務容器，用於部署執行服務，沒有在層中畫出。
• protocol層和proxy層都放在rpc模組中，這兩層是rpc的核心，在不需要叢集時(只有一個提供者)，可以只使用這兩層完成rpc呼叫。
• transport層和exchange層都放在remoting模組中，為rpc呼叫的通訊基礎。
• serialize層放在common模組中，以便更大程度複用。

依賴關係

圖例說明：

• 圖中小方塊Protocol, Cluster, Proxy, Service, Container, Registry, Monitor代表層或模組，藍色的表示與業務有互動，綠色的表示只對Dubbo內部互動。
• 圖中背景方塊Consumer, Provider, Registry, Monitor代表部署邏輯拓普節點。
• 圖中藍色虛線為初始化時呼叫，紅色虛線為執行時非同步呼叫，紅色實線為執行時同步呼叫。
• 圖中只包含RPC的層，不包含Remoting的層，Remoting整體都隱含在Protocol中。

呼叫鏈

展開總設計圖的紅色呼叫鏈，如下：

暴露服務時序

展開總設計圖左邊服務提供方暴露服務的藍色初始化鏈，時序圖如下：

引用服務時序

展開總設計圖右邊服務消費方引用服務的藍色初始化鏈，時序圖如下：

領域模型

在Dubbo的核心領域模型中：

• Protocol是服務域，它是Invoker暴露和引用的主功能入口，它負責Invoker的生命週期管理。
• Invoker是實體域，它是Dubbo的核心模型，其它模型都向它靠擾，或轉換成它，它代表一個可執行體，可向它發起invoke呼叫，它有可能是一個本地的實現，也可能是一個遠端的實現，也可能一個叢集實現。
• Invocation是會話域，它持有呼叫過程中的變數，比如方法名，引數等。

基本原則

• 採用Microkernel + Plugin模式，Microkernel只負責組將Plugin，Dubbo自身的功能也是通過擴充套件點實現的，也就是Dubbo的所有功能點都可被使用者自定義擴充套件所替換。
• 採用URL作為配置資訊的統一格式，所有擴充套件點都通過傳遞URL攜帶配置資訊。