Dubbo簡單介紹及其和zookeeper的關係

何爲Dubbo

​　　Dubbox 是一個分佈式服務框架，其前身是阿里巴巴開源項目Dubbo ，被國內電商及互聯網項目中使用，後期阿里巴巴中止了該項目的維護，噹噹網便在Dubbo基礎上進行優化，並繼續維護，爲了與原有的Dubbo區分，故將其命名爲Dubbox。

​　　Dubbox 致力於提供高性能和透明化的RPC遠程服務調用方案，以及SOA服務治理方案。簡單的說，dubbox就是個服務框架，若是沒有分佈式的需求，實際上是不須要用的，只有在分佈式的時候，纔有dubbox這樣的分佈式服務框架的需求，而且本質上是個服務調用的東西，說白了就是個遠程服務調用的分佈式框架。

　　SOA是Service-Oriented Architecture的首字母簡稱，它是一種支持面向服務的架構樣式。從服務、基於服務開發和服務的結果來看，面向服務是一種思考方式。

 

Dubbo能作什麼？

最簡單直接的說法就是：dubbo自己是一個程序，在開發中做爲jar包供咱們使用，dubbo爲咱們作的就是根據服務的url去調用服務（基於rpc協議的調用）。

透明化的遠程方法調用，就像調用本地方法同樣調用遠程方法，只需簡單配置，沒有任何API侵入。      
軟負載均衡及容錯機制，可在內網替代F5等硬件負載均衡器，下降成本，減小單點。
服務自動註冊與發現，再也不須要寫死服務提供方地址，註冊中心基於接口名查詢服務提供者的IP地址，而且可以平滑添加或刪除服務提供者。

 

Dubbo基於RPC（Remote Procedure Call 遠程過程調用）協議，服務提供方和服務消費方之間的調用關係：

節點角色說明：

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

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

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

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

• Container: 服務運行容器。

調用關係說明：

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

1. 服務提供者在啓動時，向註冊中心註冊本身提供的服務。

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

3. 註冊中心返回服務提供者地址列表給消費者，若是有變動，註冊中心將基於長鏈接推送變動數據給消費者。

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

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

 

Dubbo 屬於 RPC 框架，鏈接消費者和生產者，註冊中心 監控被調用對象的運行狀態

Dubbo提供的註冊中心有以下幾種類型可供選擇：

• Multicast註冊中心
• Zookeeper註冊中心
• Redis註冊中心
• Simple註冊中心

 

dubbo和zookeeper的關係：

對於註冊中心的選擇，咱們通常用Zookeeper，那麼zookeeper和dubbo的關係是怎麼樣的

上面這個圖若是看不太懂的話，建議看一下 ZooKeeper的數據模型 ，這裏簡單解釋一下：

zookeeper的數據模型跟咱們windows系統下的文件模型類似，都是樹形結構的;

　　windows下的文件系統有文件夾和文件兩種，文件夾只是路徑，文件纔是存儲體；

　　而zookeeper的數據模型也是樹結構的，每一個節點叫作znode，每一個znode既能夠存儲數據也能夠當作路徑

 

樹形結構的節點都是惟一的，而上面這個圖上的綠色圓點都是zookeeper中的一個znode，每一個znode都有本身的路徑和本身的值，存儲着咱們dubbo註冊的service信息，而上面這張圖的znode分爲4級（root、service、type、url）：

• 一級節點root內存儲着dubbo，表明這個znode下的全部znode都是dubbo相關的
• 二級節點service存儲着咱們dubbo註冊到zk中的service名稱，每多註冊一個service服務，就會在dubbo這個znode下添加一個新的service節點
• 三級節點type存儲着service類型，是提供者仍是消費者
• 四級節點url存儲着咱們所註冊的服務的具體地址

dubbo就是經過這一層層的節點找到咱們須要調用的url而後進行調用的。

 

zookeeper做爲dubbo的註冊中心的角色使用

咱們把提供者和消費者經過dubbo註冊到zookeeper這個註冊中內心，zookeeper中存儲的是服務的url的列表

經過消費者調用提供者服務的時候，會根據接口的名稱類型經過dubbo到zookeeper中找到對應的服務的url列表，zookeeper返回服務提供者地址列表給消費者

消費者從提供者地址列表中，基於軟負載均衡算法，選一臺提供者進行調用（這個調用就是圖1 消費者和提供者的調用關係），若是調用失敗，再選另外一臺調用