dubbo學習 一 dubbo概述

1，背景

 

 

1，網站剛開時候的時候可能全部的功能業務都在一個應用裏面

2，當業務不斷複雜，流量不斷增多的時候，就須要將原先的一個應用劃分紅多個獨立的應用。

3，當分出來的業務愈來愈多的時候，應用也變的多而複雜，各個應用之間的交互也必不可少，就須要進行遠程服務調用RPC，使用哪一個找哪一個，調用哪一個。

4，當服務愈來愈多的時候，上面那種用一個找一個的方法，不只管理混亂並且資源浪費，這時就須要一個服務調度中心來管理全部的服務信息，作爲一個服務中心，全部使用者都只要關注服務中心便可。而且還須要不一樣服務 不一樣集羣不一樣路由不一樣容錯等等資源合理 運用起來才行。

而dubbo正好解決這樣的一系列問題。

 

2，dubbo大致的架構

個人理解

dubbo大致上就是有三個部分，服務提供者，服務消費者，監控中心。服務提供者開發好服務以後，將調用這個服務的地址等信息都註冊到一個服務註冊中心去（經常使用zookeeper），通一個服務能夠有多個提供者，服務消費者要消費的時候，就從註冊中心拿過來本身要消費的服務的多個地址列表（有多個提供者的話），而後按照dobbo本身的軟負載均衡算法，來選出一個提供者，去調用。這樣，消費者不用去關心誰提供的服務，只須要找服務註冊中心便可，而提供者也不須要將配置文件告訴全部消費者，只須要註冊到註冊中心便可。而且服務的集羣負載均衡都是在消費端的，也保證了服務的乾淨，隨時均可以增長減小服務提供者。

官方文字

 

 

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

調用關係說明：
0. 服務容器負責啓動，加載，運行服務提供者。
1. 服務提供者在啓動時，向註冊中心註冊本身提供的服務。
2. 服務消費者在啓動時，向註冊中心訂閱本身所需的服務。
3. 註冊中心返回服務提供者地址列表給消費者，若是有變動，註冊中心將基於長鏈接推送變動數據給消費者。
4. 服務消費者，從提供者地址列表中，基於軟負載均衡算法，選一臺提供者進行調用，若是調用失敗，再選另外一臺調用。

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

 

dubbo的多樣化方式

1，支持協議多樣化

不一樣的服務，不一樣的場景，不一樣的消費者，可能適合的服務協議不同，這裏，dubbo已經實現了多種協議的提供和調用

     dubbo協議：使用mina,netty,grizzy三種之一來實現。

        rmi協議：使用jdk標準的java.rmi.*來實現

        hessian協議：採用Servlet暴露服務，Dubbo缺省內嵌Jetty做爲服務器實現。

        http協議：採用Spring的HttpInvoker實現

        webservice協議：基於apache的cxf來實現

        thrift協議，memcached協議，redis協議     

而且dubbo也支持協議的擴展。

 

2，註冊中心多樣化

註冊中心也實現了多種方式

Multicast註冊中心：不須要啓動任何中心節點，只要廣播地址同樣，就能夠互相發現，可是組播受網絡結構限制，只適合小規模應用或開發階段使用。

Zookeeper註冊中心：Zookeeper是Apacahe Hadoop的子項目，是一個樹型的目錄服務，支持變動推送，適合做爲Dubbo服務的註冊中心，工業強度較高，可用於生產環境，並推薦使用

Redis註冊中心

Simple註冊中心

 

3，dubbo也支持各類擴展

1，協議的擴展，能夠根據本身的業務需求來擴展對應的協議，不過通常上也夠用， 

2，負載均衡的擴展，若是以爲dubbo的集中負載均衡不夠的話，能夠本身擴展。

3，註冊中心擴展，通常上用zookeeper也行了。

4，序列化的擴展，dubbo默認使用的是 hessian2（阿里修改了下）序列化方法，可擴展成kryo等更高效的。

等等

 

由此來講，dubbo的實現已經能夠知足服務集中化管理的多種場景了。能夠學學。

 

dubbo的具體使用方法細節參考：http://dubbo.io/Home-zh.htm  寫的很是詳細。