目錄
Dubbo框架
1.1 Dubbo是什么
1.2 Dubbo企業級應用示例（略）
1.3 Dubbo實現原理及架構剖析
1.4 Dubbo+Spring集成
Dubbo框架
1.1 Dubbo是什么：Dubbo是一個分布式服務框架，致力於提高性能和透明化的RPC遠程服務調用方案，以及SOA服務治理方案。簡單的說，dubbo就是個服務框架，如果沒有分布式的需求，其實是不需要用的。告別web service模式中的WSdl，以服務者與消費者的方式在dubbo上注冊。
dubbo可滿足的基本需求：
- 服務多，壓力大：一個服務注冊中心，動態的注冊和發現服務，使服務的位置透明。並通過在消費方獲取服務提供方地址列表，實現軟負載均衡和 Failover，降低對 F5 硬件負載均衡器的依賴，也能減少部分成本。
- 服務依賴復雜：需要自動畫出應用間的依賴關系圖，以幫助架構師理清理關系。
- 服務調用量變大，服務容量不夠：第一步，要將服務現在每天的調用量，響應時間，都統計出來，作為容量規划的參考指標。其次，要可以動態調整權重，在線上，將某台機器的權重一直加大，並在加大的過程中記錄響應時間的變化，直到響應時間到達閥值，記錄此時的訪問量，再以此訪問量乘以機器數反推總容量。
1.3 Dubbo實現原理及架構剖析：（轉自 http://dubbo.apache.org/books/dubbo-dev-book/）
Dubbo的最大特點是按照分層的方式來架構，使用這種方式可以使各層之間解耦和（或大程度的松耦合）。從服務模型的角度來看，dubbo采用的是一種非常簡單的模型，要么使提供方提供服務，要么使消費方消費服務，所以基於這一點可以抽象出服務提供方Provider和服務消費方consumer兩個角色。
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。
-
關系說明
-
-
在 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作為一個分布式服務框架，主要具有如下幾個核心的要點：
服務定義
服務是圍繞服務提供方和服務消費方的，服務提供方實現服務，而服務消費方調用服務。
服務注冊
對於服務提供方，它需要發布服務，而且由於應用系統的復雜性，服務的數量、類型也不斷膨脹；對於服務消費方，它最關心如何獲取到它所需要的服務，而面對復雜的應用系統，需要管理大量的服務調用。而且，對於服務提供方和服務消費方來說，他們還有可能兼具這兩種角色，即既需要提供服務，有需要消費服務。
通過將服務統一管理起來，可以有效地優化內部應用對服務發布/使用的流程和管理。服務注冊中心可以通過特定協議來完成服務對外的統一。Dubbo提供的注冊中心有如下幾種類型可供選擇：
-
- Multicast注冊中心
- Zookeeper注冊中心
- Redis注冊中心
- Simple注冊中心
遠程通信與信息交換
遠程通信需要指定通信雙方所約定的協議，在保證通信雙方理解協議語義的基礎上，還要保證高效、穩定的消息傳輸。Dubbo繼承了當前主流的網絡通信框架，主要包括如下幾個：
-
- Mina
- Netty
- Grizzly
服務調用
下面從Dubbo官網直接拿來，看一下基於RPC層，服務提供方和服務消費方之間的調用關系，如圖所示：
調用鏈
展開總設計圖的紅色調用鏈，如下：
暴露服務時序
展開總設計圖左邊服務提供方暴露服務的藍色初始化鏈，時序圖如下：
引用服務時序
展開總設計圖右邊服務消費方引用服務的藍色初始化鏈，時序圖如下：
領域模型
在 Dubbo 的核心領域模型中：
-
-
- Protocol 是服務域，它是 Invoker 暴露和引用的主功能入口，它負責 Invoker 的生命周期管理。
- Invoker 是實體域，它是 Dubbo 的核心模型，其它模型都向它靠擾，或轉換成它，它代表一個可執行體，可向它發起 invoke 調用，它有可能是一個本地的實現，也可能是一個遠程的實現，也可能一個集群實現。
- Invocation 是會話域，它持有調用過程中的變量，比如方法名，參數等。
-