Dubbo 學習

Dubbo概念： 

  Dubbo是一個分佈式服務框架，致力於提供高性能和透明化的RPC遠程服務調用方案，以及SOA服務治理方案。簡單的說，dubbo就是個服務框架，若是沒有分佈式的需求，實際上是不須要用的，只有在分佈式的時候，纔有dubbo這樣的分佈式服務框架的需求。Dubbo缺省協議採用單一長鏈接和NIO異步通信，適合於小數據量大併發的服務調用，以及服務消費者機器數遠大於服務提供者機器數的狀況。

其核心部分包含：

  1》遠程通信：提供對多種基於長鏈接的NIO框架抽象封裝，包括多種線程模型，序列化，以及「請求-響應」模式的信息交換方式。

  2》集羣容錯： 提供基於接口方法的透明遠程過程調用，包括多協議支持，以及軟負載均衡，失敗容錯，地址路由，動態配置等集羣支持。

  3》自動發現：基於註冊中心目錄服務，使服務消費方能動態的查找服務提供方，使地址透明，使服務提供方能夠平滑增長或減小機器。

 Dubbo原理：

  初始化過程細節： 第一步，就是將服務裝載容器中，而後準備註冊服務。和spring中啓動過程相似，spring啓動時，將bean裝載進容器中的時候，首先要解析bean。因此dubbo也是先讀配置文件解析服務。

解析服務：

  1）基於dubbo.jar內的Meta-inf/spring.handlers配置，spring在遇到dubbo名稱空間時，會回調DubboNamespaceHandler類。

  2）全部的dubbo標籤，都統一用DubboBeanDefinitionParser進行解析，基於一對一屬性映射，將XML標籤解析爲Bean對象。生產者或者消費者初始化的時候，會將Bean對象轉會爲url格式，將全部Bean屬性轉成url的參數。 而後將URL傳給Protocol擴展點，基於擴展點的Adaptive機制，根據URL的協議頭，進行不一樣協議的服務暴露和引用。

暴露服務：

  a、 直接暴露服務端口

  在沒有使用註冊中心的狀況，這種狀況通常適用在開發環境下，服務的調用這和提供在同一個IP上，只須要打開服務的端口便可。 即，當配置 or ServiceConfig解析出的URL的格式爲： Dubbo：//service-host/com.xxx.TxxService?version=1.0.0 基於擴展點的Adaptiver機制，經過URL的「dubbo：//」協議頭識別，直接調用DubboProtocol的export（）方法，打開服務端口。

  b、向註冊中心暴露服務：

  和上一種的區別：須要將服務的IP和端口一同暴露給註冊中心。 ServiceConfig解析出的url格式爲：registry://registry-host/com.alibaba.dubbo.registry.RegistryService?export=URL.encode(「dubbo://service-host/com.xxx.TxxService?version=1.0.0 」)

基於擴展點的Adaptive機制，經過URL的「registry：//」協議頭識別，調用RegistryProtocol的export方法，將export參數中的提供者URL先註冊到註冊中心，再從新傳給Protocol擴展點進行暴露： Dubbo：//service-host/com.xxx.TxxService?version=1.0.0

引用服務：

  a、直接引用服務：

   在沒有註冊中心的，直連提供者狀況下， ReferenceConfig解析出的URL格式爲： Dubbo：//service-host/com.xxx.TxxService?version=1.0.0

   基於擴展點的Adaptive機制，經過url的「dubbo：//」協議頭識別，直接調用DubboProtocol的refer方法，返回提供者引用。

  b、從註冊中心發現引用服務：

   此時，ReferenceConfig解析出的URL的格式爲：registry://registry-host/com.alibaba.dubbo.registry.RegistryService?refer=URL.encode(「consumer://consumer-host/com.foo.FooService?version=1.0.0)

  基於擴展點的Apaptive機制，經過URL的「registry：//」協議頭識別，就會調用RegistryProtocol的refer方法，基於refer參數總的條件，查詢提供者URL，如： Dubbo：//service-host/com.xxx.TxxService?version=1.0.0

  基於擴展點的Adaptive機制，經過提供者URL的「dubbo：//」協議頭識別，就會調用DubboProtocol的refer（）方法，獲得提供者引用。 而後RegistryProtocol將多個提供者引用，經過Cluster擴展點，假裝成單個提供這引用返回。

分佈式服務框架：

高性能和透明化的RPC遠程服務調用方案

SOA服務治理方案

Apache MINA 框架基於Reactor模型通訊框架，基於tcp長鏈接

Dubbo缺省協議採用單一長鏈接和NIO異步通信，適合於小數據量大併發的服務調用，以及服務消費者機器數遠大於服務提供者機器數的狀況分析源代碼，基本原理以下：

  client一個線程調用遠程接口，生成一個惟一的ID（好比一段隨機字符串，UUID等），Dubbo是使用AtomicLong從0開始累計數字的

  將打包的方法調用信息（如調用的接口名稱，方法名稱，參數值列表等），和處理結果的回調對象callback，所有封裝在一塊兒，組成一個對象object

  向專門存放調用信息的全局ConcurrentHashMap裏面put(ID, object)

  將ID和打包的方法調用信息封裝成一對象connRequest，使用IoSession.write(connRequest)異步發送出去

  當前線程再使用callback的get()方法試圖獲取遠程返回的結果，在get()內部，則使用synchronized獲取回調對象callback的鎖， 再先檢測是否已經獲取到結果，若是沒有，而後調用callback的wait()方法，釋放callback上的鎖，讓當前線程處於等待狀態。

  服務端接收到請求並處理後，將結果（此結果中包含了前面的ID，即回傳）發送給客戶端，客戶端socket鏈接上專門監聽消息的線程收到消息，分析結果，取到ID，再從前面的ConcurrentHashMap裏面get(ID)，從而找到callback，將方法調用結果設置到callback對象裏。

  監聽線程接着使用synchronized獲取回調對象callback的鎖（由於前面調用過wait()，那個線程已釋放callback的鎖了），再notifyAll()，喚醒前面處於等待狀態的線程繼續執行（callback的get()方法繼續執行就能拿到調用結果了），至此，整個過程結束。