隨着互聯網的發展，網站應用的規模不斷擴大，常規的垂直應用架構已無法應對，分佈式服務架構以及流動計算架構勢在必行。Dubbo就是其中一種分佈式服務架構，在使用Dubbo之前，我們有必要了解一下Dubbo的基本概念。
Dubbo是Alibaba開源的分佈式服務框架，它最大的特點是按照分層的方式來架構，使用這種方式可以使各個層之間解耦合。它致力於提供高性能和透明化的RPC遠程調用方案，以及SOA服務治理方案，因此得到衆多企業的青睞。
總體架構：
從上圖可以看出，Dubbo框架設計分了10層，其最上面的Service層是開發者實現業務邏輯的接口層。下面根據Dubbo文檔來介紹一下各個層的設計要點：
1、服務接口層（Service）：該層是與實際業務邏輯相關的，根據服務提供方和服務消費方的業務設計對應的接口和實現。
2、配置層（Config）：對外配置接口，以 ServiceConfig 和 ReferenceConfig 爲中心，可以直接new 配置類，也可以通過 spring 解析配置生成配置類。
3、服務代理層（Proxy）：服務接口透明代理，生成服務的客戶端 Stub 和服務器端 Skeleton，以ServiceProxy 爲中心，擴展接口爲 ProxyFactory。
4、服務註冊層（Registry）：封裝服務地址的註冊與發現，以服務 URL 爲中心，擴展接口爲RegistryFactory、Registry 和 RegistryService。可能沒有服務註冊中心，此時服務提供方直接暴露服務。
5、集羣層（Cluster）：封裝多個提供者的路由及負載均衡，並橋接註冊中心，以 Invoker 爲中心，擴展接口爲 Cluster、Directory、Router 和 LoadBalance。將多個服務提供方組合爲一個服務提供方，實現對服務消費方來透明，只需要與一個服務提供方進行交互。
6、監控層（Monitor）：RPC 調用次數和調用時間監控，以 Statistics 爲中心，擴展接口爲
MonitorFactory、Monitor 和 MonitorService。
7、遠程調用層 （Protocol） ： 封將 RPC 調用， 以 Invocation 和 Result 爲中心， 擴展接口爲 Protocol、Invoker 和 Exporter。Protocol 是服務域，它是 Invoker 暴露和引用的主功能入口，它負責 Invoker的生命週期管理。Invoker 是實體域，它是 Dubbo 的核心模型，其它模型都向它靠擾，或轉換成它，它代表一個可執行體，可向它發起 invoke 調用，它有可能是一個本地的實現，也可能是一個遠程的實現，也可能一個集羣實現。
8、信息交換層（Exchange）：封裝請求響應模式，同步轉異步，以 Request 和 Response 爲中心，擴展接口爲 Exchanger、ExchangeChannel、ExchangeClient 和 ExchangeServer。
9、網絡傳輸層（Transport）：抽象 mina 和 netty 爲統一接口，以 Message 爲中心，擴展接口爲Channel、Transporter、Client、Server 和 Codec。
10、數據序列化層（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的核心就是服務的調用，架構如下：
節點角色說明：
Provider: 暴露服務的服務提供方。
Consumer: 調用遠程服務的服務消費方。
Registry: 服務註冊與發現的註冊中心。
Monitor: 統計服務的調用次調和調用時間的監控中心。
Container: 服務運行容器。
調用關係說明：
0. 服務容器負責啓動，加載，運行服務提供者。
1. 服務提供者在啓動時，向註冊中心註冊自己提供的服務。
2. 服務消費者在啓動時，向註冊中心訂閱自己所需的服務。
3. 註冊中心返回服務提供者地址列表給消費者，如果有變更，註冊中心將基於長連接推送變更數據給消費者。
4. 服務消費者，從提供者地址列表中，基於軟負載均衡算法，選一臺提供者進行調用，如果調用失敗，再選另一臺調用。
5. 服務消費者和提供者，在內存中累計調用次數和調用時間，定時每分鐘發送一次統計數據到監控中心。
剛開始接觸Dubbo時，看到這些內容難免會感覺頭大，雖然內容很多，有種高大上的趕腳。但是，從這些內容上來看，其核心還是提供分佈式的服務，只要牢牢的抓住這個核心，再對比之前學習的分佈式架構，相信用不了多久就能完全掌握該框架。