Dubbo總架構：

Dubbo框架設計一共劃分了10個層，而最上面的Service層是留給實際想要使用Dubbo開發分散式服務的開發者實現業務邏輯的介面層。圖中左邊淡藍背景的為服務消費方使用的介面，右邊淡綠色背景的為服務提供方使用的介面， 位於中軸線上的為雙方都用到的介面。
下面，結合Dubbo官方文件，我們分別理解一下框架分層架構中，各個層次的設計要點：

服務介面層（Service）：該層是與實際業務邏輯相關的，根據服務提供方和服務消費方的業務設計對應的介面和實現。
配置層（Config）：對外配置介面，以ServiceConfig和ReferenceConfig為中心，可以直接new配置類，也可以通過spring解析配置生成配置類。
服務代理層（Proxy）：服務介面透明代理，生成服務的客戶端Stub和伺服器端Skeleton，以ServiceProxy為中心，擴充套件介面為ProxyFactory。
服務註冊層（Registry）：封裝服務地址的註冊與發現，以服務URL為中心，擴充套件介面為RegistryFactory、Registry和RegistryService。可能沒有服務註冊中心，此時服務提供方直接暴露服務。
叢集層（Cluster）：封裝多個提供者的路由及負載均衡，並橋接註冊中心，以Invoker為中心，擴充套件介面為Cluster、Directory、Router和LoadBalance。將多個服務提供方組合為一個服務提供方，實現對服務消費方來透明，只需要與一個服務提供方進行互動。
監控層（Monitor）：RPC呼叫次數和呼叫時間監控，以Statistics為中心，擴充套件介面為MonitorFactory、Monitor和MonitorService。
遠端呼叫層（Protocol）：封將RPC呼叫，以Invocation和Result為中心，擴充套件介面為Protocol、Invoker和Exporter。Protocol是服務域，它是Invoker暴露和引用的主功能入口，它負責Invoker的生命週期管理。Invoker是實體域，它是Dubbo的核心模型，其它模型都向它靠擾，或轉換成它，它代表一個可執行體，可向它發起invoke呼叫，它有可能是一個本地的實現，也可能是一個遠端的實現，也可能一個叢集實現。
資訊交換層（Exchange）：封裝請求響應模式，同步轉非同步，以Request和Response為中心，擴充套件介面為Exchanger、ExchangeChannel、ExchangeClient和ExchangeServer。
網路傳輸層（Transport）：抽象mina和netty為統一介面，以Message為中心，擴充套件介面為Channel、Transporter、Client、Server和Codec。
資料序列化層（Serialize）：可複用的一些工具，擴充套件介面為Serialization、 ObjectInput、ObjectOutput和ThreadPool。
從上圖可以看出，Dubbo對於服務提供方和服務消費方，從框架的10層中分別提供了各自需要關心和擴充套件的介面，構建整個服務生態系統（服務提供方和服務消費方本身就是一個以服務為中心的）。

服務定義
服務是圍繞服務提供方和服務消費方的，服務提供方實現服務，而服務消費方呼叫服務。


服務註冊
對於服務提供方，它需要釋出服務，而且由於應用系統的複雜性，服務的數量、型別也不斷膨脹；對於服務消費方，它最關心如何獲取到它所需要的服務，而面對複雜的應用系統，需要管理大量的服務呼叫。而且，對於服務提供方和服務消費方來說，他們還有可能兼具這兩種角色，即既需要提供服務，有需要消費服務。
通過將服務統一管理起來，可以有效地優化內部應用對服務釋出/使用的流程和管理。服務註冊中心可以通過特定協議來完成服務對外的統一。Dubbo提供的註冊中心有如下幾種型別可供選擇：
Multicast註冊中心
Zookeeper註冊中心

Dubbo服務呼叫
下面從Dubbo官網直接拿來，看一下基於RPC層，服務提供方和服務消費方之間的呼叫關係，如圖所示：


上圖中，藍色的表示與業務有互動，綠色的表示只對Dubbo內部互動。上述圖所描述的呼叫流程如下：
1.服務提供方釋出服務到服務註冊中心；
2.服務消費方從服務註冊中心訂閱服務；
3.服務消費方呼叫已經註冊的可用服務

Zookeeper註冊中心安裝

建議使用dubbo-2.3.3以上版本的zookeeper註冊中心客戶端。
Zookeeper是Apache Hadoop的子專案，強度相對較好，建議生產環境使用該註冊中心。
Dubbo未對Zookeeper伺服器端做任何侵入修改，只需安裝原生的Zookeeper伺服器即可，
所有註冊中心邏輯適配都在呼叫Zookeeper客戶端時完成。


第一步安裝配置Zookeeper
準備安裝包網址
下載Zookeeper-3.4.6.tar.gz  地址http://www.apache.org/dist/zookeeper/
zookeeper-3.4.6.tar  zookeeper安裝包




安裝步驟：
建立資料夾 mkdir /usr/local/zookeeper
解壓： tar zxvf zookeeper-3.4.6.tar.gz -C /usr/local/zookeeper/
授權：chmod 777 /usr/local/zookeeper/
如圖1：



配置
然後在對應的zookeeper-3.4.6/conf 下有一個檔案zoo_sample.cfg的這個檔案裡面配置了監聽客戶端連線的埠等一些資訊，Zookeeper 在啟動時會找zoo.cfg這個檔案作為預設配置檔案,所以我們複製一個名稱為zoo.cfg的檔案，
如圖2所示：





我們檢視一下這個檔案的裡面的一些配置資訊，如圖3所示：

置檔案說明：
 clientPort：監聽客戶端連線的埠。
 tickTime：基本事件單元，以毫秒為單位。它用來控制心跳和超時，預設情況下最小的會話超時時間為兩倍的 tickTime。
 我們可以對配置檔案的埠等或者進行高階配置和叢集配置例如：maxClientCnxns：限制連線到 ZooKeeper 的客戶端的數量等。

啟動Zookeeper 的服務，如圖4所示：


到此Zookeeper的安裝和配置完成。




 第二步：配置dubbo-admin的管理頁面，方便我們管理頁面
配置dubbo-admin的管理頁面之前先安裝tomcat請參考http://blog.csdn.net/xingkong22star/article/details/44806887
    (1)下載dubbo-admin-2.5.3.war包，在Linux的tomcat部署，先把dubbo-admin-2.5.3放在tomcat的webapps/ROOT下，然後進行解壓解壓完成後刪除war包：
        cd webapps/ROOT/
jar -xvf dubbo-admin-2.5.3.war
rm dubbo-admin-2.5.3.war 
rm：是否刪除普通檔案 "dubbo-admin-2.5.3.war"？y

圖5所示：

    (2)然後到webapps/ROOT/WEB-INF下，有一個dubbo.properties檔案，裡面指向Zookeeper ，使用的是Zookeeper 的註冊中心，如圖6所示：


    (3)然後啟動tomcat服務，使用者名稱和密碼：root,並訪問服務，顯示登陸頁面，說明dubbo-admin部署成功，
[[email protected] /]#  /usr/local/zookeeper/zookeeper-3.4.6/bin/zkServer.sh start
JMX enabled by default
Using config: /usr/local/zookeeper/zookeeper-3.4.6/bin/../conf/zoo.cfg
Starting zookeeper ... already running as process 2407.
[[email protected] /]# /usr/local/tomcat/apache-tomcat-7.0.62/bin/startup.sh start
Using CATALINA_BASE:   /usr/local/tomcat/apache-tomcat-7.0.62
Using CATALINA_HOME:   /usr/local/tomcat/apache-tomcat-7.0.62
Using CATALINA_TMPDIR: /usr/local/tomcat/apache-tomcat-7.0.62/temp
Using JRE_HOME:        /usr/local/jdk/jdk1.7.0_79/jre
Using CLASSPATH:       /usr/local/tomcat/apache-tomcat-7.0.62/bin/bootstrap.jar:/usr/local/tomcat/apache-tomcat-7.0.62/bin/tomcat-juli.jar
Tomcat started.
進入瀏覽器輸入127.0.0.1:8080後會出現如圖7所示： 

登陸完成如圖8所示： 



如果出現如下錯誤如圖9：

原因是因為解壓dubbo後忘記刪除war包了






註冊中心抽象
Dubbo的將註冊中心進行抽象，是得它可以外接不同的儲存媒介給註冊中心提供服務，有ZooKeeper，Memcached，Redis等。
Dubbo抽象後，使用者可以進行擴充套件，我們通過分析ZooKeeper這個實現來了解註冊中心的低層。
進過抽象之後，使用者 只需要實現對應的Registry和RegistryFactory就可以了，ZooKeeper就是實現了ZookeeperRegistry，和ZookeeperRegistryFactory。
ZookeeperRegistryFactory的實現很簡單，就是返回一個ZookeeperRegistry例項，所以主要的東西是在ZookeeperRegistry中實現的，在ZookeeperRegistry使用者需要實現註冊URL，
登出URL，URL訂閱，URL登出訂閱和URL查詢，在這裡面設計到Zookeeper服務端的呼叫，都被封裝到ZookeeperClient中，ZookeeperClient服務進行Server連線，斷鏈；資源的CRUD。


ZooKeeper的價值
由於引入了ZooKeeper作為儲存媒介，也就把ZooKeeper的特性引進來。
首先是負載均衡，單註冊中心的承載能力是有限的，在流量達到一定程度的時候就需要分流，負載均衡就是為了分流而存在的，一個ZooKeeper群配合相應的Web應用就可以很容易達到負載均衡；
資源同步，單單有負載均衡還不夠，節點之間的資料和資源需要同步，ZooKeeper叢集就天然具備有這樣的功能；
命名服務，將樹狀結構用於維護全域性的服務地址列表，服務提供者在啟動的時候，向ZK上的指定節點/dubbo/${serviceName}/providers目錄下寫入自己的URL地址，這個操作就完成了服務的釋出。
其他特性還有Mast選舉，分散式鎖等。