阿里架構之旅（二）——Dubbo解析

      上次我們簡單介紹了一下Dubbo，知道了Dubbo是一個分佈式服務框架，將複雜的調用關係簡單的管理起來，不管是從設計思路，還是性能提升上，它都是一個優秀的產品。如果我們不知道它的工作原理，那麼我就相當於沒接觸過Dubbo，而且我們可以發現它的原理會更有趣。既然是這樣，那我們就趕緊開始吧。

一、架構圖解

1、架構圖

2、角色

Provider: 暴露服務的服務提供方。

Consumer: 調用遠程服務的服務消費方。

Registry: 服務註冊與發現的註冊中心。

Monitor: 統計服務的調用次調和調用時間的監控中心。

Container: 服務運行容器。

3、調用關係

0 服務容器負責啓動，加載，運行服務提供者。

1 服務提供者在啓動時，向註冊中心註冊自己提供的服務。

2 服務消費者在啓動時，向註冊中心訂閱自己所需的服務。

3 註冊中心返回服務提供者地址列表給消費者，如果有變更，註冊中心將基於長連接推送變更數據給消費者。

4 服務消費者，從提供者地址列表中，基於軟負載均衡算法，選一臺提供者進行調用，如果調用失敗，再選另一臺調用。

5 服務消費者和提供者，在內存中累計調用次數和調用時間，定時每分鐘發送一次統計數據到監控中心

二、重點解析

      這裏我們可能最不明白的還是生產這和消費者。那麼服務的提供方就是生產者，服務的調用方就是消費者。
      當別人需要調用我們的服務（方法）的時候，我們在服務方的提供方Provider寫一個來提供該服務；當我們需要調用其他服務時，需要在Consumer來調用一個服務。

1、服務提供者暴露一個服務的詳細過程

      具體服務到Invoker的轉化
      首先ServiceConfig類拿到對外提供服務的實際類ref(如：HelloWorldImpl),然後通過ProxyFactory類的getInvoker方法使用ref生成一個AbstractProxyInvoker實例.
      Invoker轉換到Exporter
      Dubbo的實現:Dubbo協議的Invoker轉爲Exporter發生在DubboProtocol類的export方法，它主要是打開socket偵聽服務，並接收客戶端發來的各種請求，通訊細節由Dubbo自己實現。
      RMI的實現:RMI協議的Invoker轉爲Exporter發生在RmiProtocol類的export方法，它通過Spring或Dubbo或JDK來實現RMI服務，通訊細節這一塊由JDK底層來實現，這就省了不少工作量。

2、服務消費者消費一個服務的詳細過程

      首先ReferenceConfig類的init方法調用Protocol的refer方法生成Invoker實例(如上圖中的紅色部分)，這是服務消費的關鍵。接下來把Invoker轉換爲客戶端需要的接口(如：HelloWorld)。

3、詳解Invoker

      由於Invoker是Dubbo領域模型中非常重要的一個概念，很多設計思路都是向它靠攏。這就使得Invoker滲透在整個實現代碼裏，對於剛開始接觸Dubbo的人，確實容易給搞混了。

      上圖中的具體服務類會被封裝成爲一個AbstractProxyInvoker實例，並新生成一個Exporter實例。
      這樣當我們調用服務消費時，用戶代碼通過上圖中服務消費端的proxy調用其對應的Invoker(DubboInvoker、 HessianRpcInvoker、 InjvmInvoker、 RmiInvoker、 WebServiceInvoker中的任何一個)，而該Invoker通過網絡通訊層的傳輸，會找到對應的Exporter實例，並調用它所對應的AbstractProxyInvoker實例，從而真正調用了服務提供者的代碼，實現了遠程服務調用。

總結：

      通過此次學習，我們知道了Dubbo架構的工作原理，知道了服務如何提供並消費，但是什麼是註冊，爲什麼要註冊我們還不太明白，後邊我們在介紹zookeeper的時候會一一講解。