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: 服務運行容器。
調用關系說明：
-
服務容器負責啟動，加載，運行服務提供者。
-
服務提供者在啟動時，向注冊中心注冊自己提供的服務。
-
服務消費者在啟動時，向注冊中心訂閱自己所需的服務。
-
注冊中心返回服務提供者地址列表給消費者，如果有變更，注冊中心將基於長連接推送變更數據給消費者。
-
服務消費者，從提供者地址列表中，基於軟負載均衡算法，選一台提供者進行調用，如果調用失敗，再選另一台調用。
-
服務消費者和提供者，在內存中累計調用次數和調用時間，定時每分鍾發送一次統計數據到監控中心。
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 消費者和提供者的調用關系），如果調用失敗，再選另一台調用