一、Dubbo架構詳解
1. Dubbo是什麼？ Dubbo是一個分佈式服務框架，致力於提供高性能和透明化的RPC遠程服務調用方案，以及SOA服務治理方案。簡單的說，dubbo就是個服務框架，如果沒有分佈式的需求，其實是不需要用的，只有在分佈式的時候，纔有dubbo這樣的分佈式服務框架的需求，並且本質上是個服務調用的東東，說白了就是個遠程服務調用的分佈式框架 其核心部分包含: 1. 遠程通訊: 提供對多種基於長連接的NIO框架抽象封裝，包括多種線程模型，序列化，以及“請求-響應”模式的信息交換方式。 2. 集羣容錯: 提供基於接口方法的透明遠程過程調用，包括多協議支持，以及軟負載均衡，失敗容錯，地址路由，動態配置等集羣支持。 3. 自動發現: 基於註冊中心目錄服務，使服務消費方能動態的查找服務提供方，使地址透明，使服務提供方可以平滑增加或減少機器。
2. Dubbo能做什麼？ 1.透明化的遠程方法調用，就像調用本地方法一樣調用遠程方法，只需簡單配置，沒有任何API侵入。 2.軟負載均衡及容錯機制，可在內網替代F5等硬件負載均衡器，降低成本，減少單點。 3. 服務自動註冊與發現，不再需要寫死服務提供方地址，註冊中心基於接口名查詢服務提供者的IP地址，並且能夠平滑添加或刪除服務提供者。 Dubbo採用全Spring配置方式，透明化接入應用，對應用沒有任何API侵入，只需用Spring加載Dubbo的配置即可，Dubbo基於Spring的Schema擴展進行加載
1、Dubbo出現得背景：
（1）、框架的發展趨勢
隨着互聯網的發展，網站應用的規模不斷擴大，常規的垂直應用架構已無法應對，分佈式服務架構以及流動計算架構勢在必行，亟需一個治理系統確保架構有條不紊的演進。
單一應用架構
當網站流量很小時，只需一個應用，將所有功能都部署在一起，以減少部署節點和成本。 此時，用於簡化增刪改查工作量的數據訪問框架(ORM)是關鍵。
垂直應用架構``
當訪問量逐漸增大，單一應用增加機器帶來的加速度越來越小，將應用拆成互不相干的幾個應用，以提升效率。 此時，用於加速前端頁面開發的Web框架(MVC)是關鍵。
分佈式服務架構
當垂直應用越來越多，應用之間交互不可避免，將核心業務抽取出來，作爲獨立的服務，逐漸形成穩定的服務中心，使前端應用能更快速的響應多變的市場需求。 此時，用於提高業務複用及整合的分佈式服務框架(RPC)是關鍵。
流動計算架構
當服務越來越多，容量的評估，小服務資源的浪費等問題逐漸顯現，此時需增加一個調度中心基於訪問壓力實時管理集羣容量，提高集羣利用率。 此時，用於提高機器利用率的資源調度和治理中心(SOA)是關鍵。
（2）、Dubbo出現的契機
在大規模服務化之前，應用可能只是通過RMI或Hessian等工具，簡單的暴露和引用遠程服務，通過配置服務的URL地址進行調用，通過F5等硬件進行負載均衡。
(1) 當服務越來越多時，服務URL配置管理變得非常困難，F5硬件負載均衡器的單點壓力也越來越大。
此時需要一個服務註冊中心，動態的註冊和發現服務，使服務的位置透明。 並通過在消費方獲取服務提供方地址列表，實現軟負載均衡和Failover，降低對F5硬件負載均衡器的依賴，也能減少部分成本。
(2) 當進一步發展，服務間依賴關係變得錯蹤複雜，甚至分不清哪個應用要在哪個應用之前啓動，架構師都不能完整的描述應用的架構關係。
這時，需要自動畫出應用間的依賴關係圖，以幫助架構師理清理關係。
(3) 接着，服務的調用量越來越大，服務的容量問題就暴露出來，這個服務需要多少機器支撐？什麼時候該加機器？
爲了解決這些問題，第一步，要將服務現在每天的調用量，響應時間，都統計出來，作爲容量規劃的參考指標。 其次，要可以動態調整權重，在線上，將某臺機器的權重一直加大，並在加大的過程中記錄響應時間的變化，直到響應時間到達閥值，記錄此時的訪問量，再以此訪問量乘以機器數反推總容量。
以上是Dubbo最基本的幾個需求，更多服務治理問題參見： http://code.alibabatech.com/blog/experience_1402/service-governance-process.html
（3）、Dubbo隆重登場
節點角色說明：
Provider: 暴露服務的服務提供方
Consumer: 調用遠程服務的服務消費方。
Registry: 服務註冊與發現的註冊中心。
Monitor: 統計服務的調用次調和調用時間的監控中心。
Container: 服務運行容器。
調用關係說明：
服務容器負責啓動，加載，運行服務提供者。
服務提供者在啓動時，向註冊中心註冊自己提供的服務。
服務消費者在啓動時，向註冊中心訂閱自己所需的服務。
註冊中心返回服務提供者地址列表給消費者，如果有變更，註冊中心將基於長連接推送變更數據給消費者。
服務消費者，從提供者地址列表中，基於軟負載均衡算法，選一臺提供者進行調用，如果調用失敗，再選另一臺調用。
服務消費者和提供者，在內存中累計調用次數和調用時間，定時每分鐘發送一次統計數據到監控中心。
(1) 連通性： 註冊中心負責服務地址的註冊與查找，相當於目錄服務，服務提供者和消費者只在啓動時與註冊中心交互，註冊中心不轉發請求，壓力較小 監控中心負責統計各服務調用次數，調用時間等，統計先在內存彙總後每分鐘一次發送到監控中心服務器，並以報表展示 服務提供者向註冊中心註冊其提供的服務，並彙報調用時間到監控中心，此時間不包含網絡開銷 服務消費者向註冊中心獲取服務提供者地址列表，並根據負載算法直接調用提供者，同時彙報調用時間到監控中心，此時間包含網絡開銷 註冊中心，服務提供者，服務消費者三者之間均爲長連接，監控中心除外 註冊中心通過長連接感知服務提供者的存在，服務提供者宕機，註冊中心將立即推送事件通知消費者 註冊中心和監控中心全部宕機，不影響已運行的提供者和消費者，消費者在本地緩存了提供者列表 註冊中心和監控中心都是可選的，服務消費者可以直連服務提供者
(2) 健狀性： 監控中心宕掉不影響使用，只是丟失部分採樣數據 數據庫宕掉後，註冊中心仍能通過緩存提供服務列表查詢，但不能註冊新服務 註冊中心對等集羣，任意一臺宕掉後，將自動切換到另一臺 註冊中心全部宕掉後，服務提供者和服務消費者仍能通過本地緩存通訊 服務提供者無狀態，任意一臺宕掉後，不影響使用 服務提供者全部宕掉後，服務消費者應用將無法使用，並無限次重連等待服務提供者恢復
(3) 伸縮性： 註冊中心爲對等集羣，可動態增加機器部署實例，所有客戶端將自動發現新的註冊中心 服務提供者無狀態，可動態增加機器部署實例，註冊中心將推送新的服務提供者信息給消費者
(4) 升級性： 當服務集羣規模進一步擴大，帶動IT治理結構進一步升級，需要實現動態部署，進行流動計算，現有分佈式服務架構不會帶來阻力：
Deployer: 自動部署服務的本地代理。
Repository: 倉庫用於存儲服務應用發佈包。
Scheduler: 調度中心基於訪問壓力自動增減服務提供者。
Admin: 統一管理控制檯。
Dubbo Framework：
2、Dubbo總設計圖：
圖例說明
圖中左邊淡藍背景的爲服務消費方使用的接口，右邊淡綠色背景的爲服務提供方使用的接口，位於中軸線上的爲雙方都用到的接口。
圖中從下至上分爲十層，各層均爲單向依賴，右邊的黑色箭頭代表層之間的依賴關係，每一層都可以剝離上層被複用，其中，Service和Config層爲API，其它各層均爲SPI。
圖中綠色小塊的爲擴展接口，藍色小塊爲實現類，圖中只顯示用於關聯各層的實現類。
圖中藍色虛線爲初始化過程，即啓動時組裝鏈，紅色實線爲方法調用過程，即運行時調時鏈，紫色三角箭頭爲繼承，可以把子類看作父類的同一個節點，線上的文字爲調用的方法。
各層說明
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
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實際上不算一層，而是一個獨立的節點，只是爲了全局概覽，用層的方式畫在一起。
（1）、模塊劃分：
源碼包結構
模塊調用圖
模塊說明
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模塊中，以便更大程度複用。
（2）、依賴關係：
圖例說明
圖中小方塊Protocol, Cluster, Proxy, Service, Container, Registry, Monitor代表層或模塊，藍色的表示與業務有交互，綠色的表示只對Dubbo內部交互。
圖中背景方塊Consumer, Provider, Registry, Monitor代表部署邏輯拓普節點。
圖中藍色虛線爲初始化時調用，紅色虛線爲運行時異步調用，紅色實線爲運行時同步調用。
圖中只包含RPC的層，不包含Remoting的層，Remoting整體都隱含在Protocol中。
（3）、調用鏈
展開總設計圖的紅色調用鏈，如下：
（4）、暴露服務時序
展開總設計圖右邊服務提供方暴露服務的藍色初始化鏈，時序圖如下：
（5）、引用服務時序
展開總設計圖左邊服務消費方引用服務的藍色初始化鏈，時序圖如下：
（6）、領域模型
在Dubbo的核心領域模型中：
Protocol是服務域，它是Invoker暴露和引用的主功能入口，它負責Invoker的生命週期管理。
Invoker是實體域，它是Dubbo的核心模型，其它模型都向它靠擾，或轉換成它，它代表一個可執行體，可向它發起invoke調用，它有可能是一個本地的實現，也可能是一個遠程的實現，也可能一個集羣實現。
Invocation是會話域，它持有調用過程中的變量，比如方法名，參數等。
基本原則
採用Microkernel + Plugin模式，Microkernel只負責組裝Plugin，Dubbo自身的功能也是通過擴展點實現的，也就是Dubbo的所有功能點都可被用戶自定義擴展所替換。
採用URL作爲配置信息的統一格式，所有擴展點都通過傳遞URL攜帶配置信息。
———————-Dubbo Github源碼下載地址——————————