1、概念
Dubbo是一個分布式服務架構，以及阿裡巴巴内部的SOA服務化治理方案的核心架構。其功能主要包含：高性能NIO通訊及多協定內建。服務動态尋址與路由。軟負載均衡與容錯，依賴分析與降級等。
說通俗點，就是首先将程式元件化成一個個相對獨立的服務，然後就能夠對服務進行分布式。并且，它有注冊中心通過監聽，實時發現着新服務，并部署。還能夠推送給client；它還內建了負載均衡的解決方式。利用随機算法來講各個服務科學地配置設定到多台server上；當然，它也內建了容錯機制，來提高叢集的穩定性。
2、架構
節點角色說明：
Ø Provider: 暴露服務的服務提供方。
Ø Consumer: 調用遠端服務的服務消費方。
Ø Registry: 服務注冊與發現的注冊中心。
Ø Monitor: 統計服務的調用次調和調用時間的監控中心。
Ø Container: 服務執行容器。
調用關系說明：
0. 服務容器負責啟動。載入，執行服務提供者。
1. 服務提供者在啟動時。向注冊中心注冊自己提供的服務。
2. 服務消費者在啟動時，向注冊中心訂閱自己所需的服務。
3. 注冊中心傳回服務提供者位址清單給消費者。假設有變更，注冊中心将基于長連接配接推送變更資料給消費者。
4. 服務消費者。從提供者位址清單中，基于軟負載均衡算法。選一台提供者進行調用，假設調用失敗，再選還有一台調用。
5. 服務消費者和提供者，在記憶體中累計調用次數和調用時間，定時每分鐘發送一次統計資料到監控中心。
注冊中心（Registry）說明：
對于Dubbo架構中的控制中心及Registry，阿裡提供了兩種方案：Zookeeper和Redis。生産環境建議大家都使用Zookeeper，推薦理由是：
1. Dubbo的官網上寫着，使用Dubbo-2.3.3及以上的版本号，推薦使用Zookeeper注冊中心。
2. Zookeeper是Apache Hadoop的子項目。強度相對較好。可以全然勝任生産環境的扮演穩定的角色。
3. Dubbo未對Zookeeper服務端做不論什麼侵入改動。僅僅需安裝原生的Zookeeperserver就可以，全部注冊中心邏輯适配都在調用Zookeeperclient完畢。
3、執行個體
為了簡單起見，這個執行個體中。我們沒有使用Zookeeper注冊中心暴露服務位址，而是使用外網的multicast廣播注冊中心暴露服務位址。這樣我們能夠高速的認識一下Dubbo的作用。
案例中。我們建立了兩個WebProject：dubboprovider和dubboconsumer，前者為服務提供方。後者作為client。我們将dubboprovider服務類的接口引入到dubboconsumer項目中（不能引用服務的實作類）。然後通過multicast廣播注冊中心（真實環境用Registry）來遠端調用dubboprovider服務的實作，假設能成功調到，就算成功。（項目中applicationContext.xml會報錯，是由