dubbo是阿里的一個開源soa框架，詳細介紹http://code.alibabatech.com/wiki/display/dubbo/Home-zh

zookeeper是Hadoop的子專案，主要功能基於paxos演算法對分散式系統的請求進行排程，詳細介紹http://www.ibm.com/developerworks/cn/opensource/os-cn-zookeeper/

考慮到單機部署執行，在此文件中RegisterGroup 是單例的Zookeeper，部署叢集模式的registerGroup請參考Zookeeper叢集 http://wenku.baidu.com/view/641998d649649b6648d747a7.html

程式碼下載[不含 app的lib]http://download.csdn.net/detail/goliathray/5048969

需要的工具 eclipse tomcat

ProviderGroup：可以存在多個ProviderGroup，每個Group由多臺Node組成，每個Node需要保證以下配置

1.      採用相同的application name

2.      保證provider的連線地址互不相同（在單機上部署多個provider需要保證埠不同）

3.      註冊中心地址一致

ConsumerGroup：可以存在多個ConsumerGroup，每個Group由多臺Node組成，每個Node需要保證能網路連線到所需業務的Provider並保證以下配置

1.      採用相同的application name

2.      註冊中心地址一致

ProviderNode可以作為ConsumerNode呼叫別的ProviderGroup組的業務，相對的ConsumerNode也可以作為ProviderNode

RegisterGroup：註冊中心組作為服務呼叫的分配者，每個RegisterNode監聽除自身以外所有節點是否存活和健康（包括其RegisterGroup），本文件以Zookeeper單例部署為例子說明。

DubboAdmin：管理節點，可選節點，只作為一個管理者和觀察者。

部署說明：

1.      在Eclipse中引入DubboConsumerNode1 - 3 和DubboProviderNode1 -3 共6個專案

2.      將DubboAdmin中的檔案複製到apache-tomcat\webapps\ROOT下

3.      Zookeeper已經做了基礎配置，只需在 \zookeeper-3.4.4\bin啟動 zkServer.cmd

Zoo.cfg配置說明

#tickTime：這個時間是作為 Zookeeper 伺服器之間或客戶端與伺服器之間維持心跳的時間間隔，也就是每個 tickTime 毫秒時間就會發送一個心跳。

tickTime=2000

#dataDir：Zookeeper 儲存資料的目錄，預設情況下，Zookeeper 將寫資料的日誌檔案也儲存在這個目錄裡。

dataDir=/tmp/zookeeper

#dataLogDir:日誌檔案儲存的位置（未配置）

dataLogDir=/tmp/zookeeper/log

#clientPort：這個埠就是客戶端連線Zookeeper 伺服器的埠，Zookeeper 會監聽這個埠，接受客戶端的訪問請求。

clientPort=2181

#initLimit：這個配置項是用來配置 Zookeeper接受客戶端（這裡所說的客戶端不是使用者連線 Zookeeper 伺服器的客戶端，而是 Zookeeper 伺服器叢集中連線到 Leader 的 Follower 伺服器）初始化連線時最長能忍受多少個心跳時間間隔數。

#當已經超過 10 個心跳的時間（也就是tickTime）長度後 Zookeeper 伺服器還沒有收到客戶端的返回資訊，那麼表明這個客戶端連線失敗。總的時間長度就是 10*2000=20 秒。

initLimit=10 

啟動順序：

這個部署並不嚴格要求啟動的前後順序，建議啟動順序

1.      啟動Zookeeper ，顯示

2.      啟動Tomcat，若先啟動Tomcat則會一直監聽Zookeeper服務是否啟動，當Zookeeper啟動後才會載入完成，啟動完成後訪問127.0.0.1:8080，以root/root 登陸，顯示

3.      啟動Provider，在eclipse中找到Provider1-3.java,直接執行main方法，每啟動一個節點，顯示

同時在提供者列表中會增加一個節點資訊

3個Provider全啟動後

4.      啟動Consumer, 在eclipse中找到Consumer1-3.java,直接執行main方法，每啟動一個節點，可以見到console有輸出

在Provider的Console中有顯示

同時在消費者列表有新增節點資訊

3個Consumer全啟動後

節點的異常：

ProviderNode異常：當某臺ProviderNode宕機後，Register無法再獲取此Provider的資訊，但是在進行initLimit個心跳連線之前，Register會認為這個Node只是暫時出錯，並不會把他剔除出Provider的列表，Consumer的呼叫會報錯（在未配置容錯的情況下），某臺Consumer可能會顯示

但是在經過initLimit次的心跳後，此節點會被剔除出Provider列表，訪問恢復

ConsumerNode異常：除非存在P-C-P的迴圈，不會對此部署產生影響，在經過initLimit次的心跳後，在Consumer列表中被剔除

RegisterNode異常：參考Zookeeper叢集異常

異常恢復：對於每個ProviderNode和ConsumerNode，只需要重啟動後連線上Register，既可以恢復原有的服務狀態。

DubboAdmin管理：

DubboAdmin本身的配置採用的是檔案的方式儲存配置資訊，配置的結果資訊會由各個節點儲存到臨時檔案，以保證在重啟服務後恢復到原有狀態

權重負載均衡：預設採用的是隨機權重的負載均衡，對於第一次載入的Provider服務，權重為100，服務的訪問率為（節點服務權重/服務重權重）*100%，可以通過增減權重的方式改變節點的訪問機率，在對1號節點增加4倍權重後，1號節點的訪問概率變為66.7%，可以在3個Provider節點的Console中看到資訊的增幅速度明顯改變，1號節點的速度遠大於其他2個節點。

自定義的負載均衡：可以新增負載均衡的規則，優先於預設的負載均衡，有隨機，倫循，按最小併發3種規則，可以細化到方法。

消費者的容錯：在Provider端出現異常時，可以預設返回一個容錯值，預設為Null，可以自己配置，通過對Provider的Service設定mock類

啟動容錯後若Provider端出錯，返回Null，優先於禁用

可以看到Consumer的Console報錯

消費者的禁用：對於ConsumerNode，禁用後則不能訪問任何Provider

若設定了容錯，則返回NULL

若無容錯，則返回呼叫異常

恢復後顯示資料可以正常訪問

提供者的禁用：禁止此Provider提供服務，（對下次啟動生效），在重啟動這個服務後顯示

服務無法被訪問，在點選啟用後服務恢復

--------------------- 
作者：goliathray 
來源：CSDN 
原文：https://blog.csdn.net/goliathray/article/details/8565801 
版權宣告：本文為博主原創文章，轉載請附上博文連結！