Dubbo 框架

Dubbo是Alibaba開源的分佈式服務框架，它最大的特色是按照分層的方式來架構，使用這種方式可使各個層之間解耦合（或者最大限度地鬆耦合）。從服務模型的角度來看，Dubbo採用的是一種很是簡單的模型，要麼是提供方提供服務，要麼是消費方消費服務，因此基於這一點能夠抽象出服務提供方（Provider）和服務消費方（Consumer）兩個角色。

總體架構：


各層說明：
    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

關係說明：
    1. 在RPC中，Protocol是核心層，也就是隻要有Protocol + Invoker + Exporter就能夠完成非透明的RPC調用，而後在Invoker的主過程上Filter攔截點。
    2. 圖中的Consumer和Provider是抽象概念，只是想讓看圖者更直觀的瞭解哪些類分屬於客戶端與服務器端，不用Client和Server的緣由是Dubbo在不少場景下都使用Provider, Consumer, Registry, Monitor劃分邏輯拓普節點，保持統一律念。
    3. Cluster是外圍概念，因此Cluster的目的是將多個Invoker假裝成一個Invoker，這樣其它人只要關注Protocol層Invoker便可，加上Cluster或者去掉Cluster對其它層都不會形成影響，由於只有一個提供者時，是不須要Cluster的。
    4. Proxy層封裝了全部接口的透明化代理，而在其它層都以Invoker爲中心，只有到了暴露給用戶使用時，才用Proxy將Invoker轉成接口，或將接口實現轉成Invoker，也就是去掉Proxy層RPC是能夠Run的，只是不那麼透明，不那麼看起來像調本地服務同樣調遠程服務。
    5. Remoting實現是Dubbo協議的實現，若是你選擇RMI協議，整個Remoting都不會用上，Remoting內部再劃爲Transport傳輸層和Exchange信息交換層，Transport層只負責單向消息傳輸，是對Mina,Netty,Grizzly的抽象，它也能夠擴展UDP傳輸，而Exchange層是在傳輸層之上封裝了Request-Response語義。
    6. 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模塊中，以便更大程度複用。

依賴關係：

    1. 節點角色說明：
    Provider: 暴露服務的服務提供方。
    Consumer: 調用遠程服務的服務消費方。
    Registry: 服務註冊與發現的註冊中心。
    Monitor: 統計服務的調用次數和調用時間的監控中心。
    Container: 服務運行容器。

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

暴露服務
時序如圖所示：


引用服務
時序如圖所示：


Dubbo做爲一個分佈式服務框架，主要具備以下幾個核心的要點：

1. 服務定義
   服務是圍繞服務提供方和服務消費方的，服務提供方實現服務，而服務消費方調用服務。
2. 服務註冊
   對於服務提供方，它須要發佈服務，並且因爲應用系統的複雜性，服務的數量、類型也不斷膨脹；對於服務消費方，它最關心如何獲取到它所須要的服務，而面對複雜的應用系統，須要管理大量的服務調用。並且，對於服務提供方和服務消費方來講，他們還有可能兼具這兩種角色，即既須要提供服務，有須要消費服務。經過將服務統一管理起來，能夠有效地優化內部應用對服務發佈/使用的流程和管理。服務註冊中心能夠經過特定協議來完成服務對外的統一。Dubbo提供的註冊中心有以下幾種類型可供選擇：Multicast, Zookeeper, Redis, Simple。
3. 服務監控
   不管是服務提供方，仍是服務消費方，他們都須要對服務調用的實際狀態進行有效的監控，從而改進服務質量。
4. 遠程通訊與信息交換
   遠程通訊須要指定通訊雙方所約定的協議，在保證通訊雙方理解協議語義的基礎上，還要保證高效、穩定的消息傳輸。Dubbo繼承了當前主流的網絡通訊框架，主要包括以下幾個：Mina, Netty, Grizzly。
5. 協議支持
   Dubbo支持多種協議，在通訊過程當中，不一樣的服務等級通常對應着不一樣的服務質量，那麼選擇合適的協議即是一件很是重要的事情。你能夠根據你應用的建立來選擇。例如，使用RMI協議，通常會受到防火牆的限制，因此對於外部與內部進行通訊的場景，就不要使用RMI協議，而是基於HTTP協議或者Hessian協議以下所示：Dubbo, Hessian, HTTP, RMI, WebService, Thrift, Memcached, Redis

具體可參考dubbo官方文檔：
用戶指南：http://dubbo.io/User+Guide-zh.htm
開發指南：http://dubbo.io/Developer+Guide-zh.htm
管理指南：http://dubbo.io/Administrator+Guide-zh.htm