前言
今天學習Spring Cloud的時候，看到目前主流的微服務架構有兩套解決方案：Dubbo + Zookeeper與SpringCloud。
兩種方案都可以很方便的進行微服務開發，其中的區別在於SpringCloud組件多，功能完備，全家桶式，基本微服務中會遇到的問題都有相應的解決方案，在通信方面SpringCloud使用的是http。
Dubbo+Zookeeper使用的是RPC，組件較少，功能非完備（但是可以自己去找相應的解決方案），並且現在交由Apache進行孵化，後面應該會實現功能的完備。就個人來說，認爲Dubbo+Zookeeper的侵入性更少，且調用過程更簡單，更加類似服務之間的調用，兩種方案後續就會進行學習。
回顧了一下，突然發現已經記不清Dubbox + Zookeeper了，於是藉此機會整理一下。
一、Dubbox 框架
1.1、Dubbox 簡介
Dubbox是一個分佈式服務框架，其前身是阿里巴巴開源項目Dubbo ，被國內電商及互聯網項目中使用，後期阿里巴巴停止了該項目的維護，噹噹網便在Dubbo基礎上進行優化，並繼續維護，爲了與原有的Dubbo 區分，故將其命名爲Dubbox。
Dubbox致力於提供高性能和透明化的RPC遠程服務調用方案，以及SOA服務治理方案。簡單的說，dubbox 就是個服務框架，如果沒有分佈式的需求，其實是不需要用的，只有在分佈式的時候，纔有 dubbox 這樣的分佈式服務框架的需求，本質上是個遠程服務調用的分佈式框架。
SOA 是 Service-Oriented Architecture的首字母簡稱，它是一種支持面向服務的架構樣式。
從服務、基於服務開發和服務的結果來看，面向服務是一種思考方式。SOA 架構多應用於互聯網項目開發。
節點角色說明：
Provider: 暴露服務的服務提供方。
Consumer: 調用遠程服務的服務消費方。
Registry: 服務註冊與發現的註冊中心。
Monitor: 統計服務的調用次調和調用時間的監控中心。
Container: 服務運行容器。
調用關係說明：
- 服務容器負責啓動，加載，運行服務提供者。
服務提供者在啓動時，服務運行容器Container會加載服務提供方以啓動它，服務提供方啓動後向註冊中心註冊自己所有能提供的服務。
IP PORT 協議dubbo 服務名稱 - 服務消費方在啓動時，向註冊中心訂閱自己所需的服務。
- 註冊中心返回服務提供方地址列表給消費方。如果服務提供方發生服務的修改變更，服務提供方會繼續註冊給註冊中心，註冊中心主動將基於長連接異步推送變更數據給消費方。
- 第一種情況，服務消費方直接調用服務提供方的服務，服務提供方將結果返回（同步的過程）
- 基於軟負載均衡算法，選一臺提供者進行調用，如果調用失敗，再選另一臺調用。
- 第二種情況，如果找不到需要的服務（如 網絡問題等），服務消費方默認會每個一秒重試一次，默認重試3次，如果還找不到服務報錯no server。
- 服務消費者和提供者，會將服務的健康狀態、調用次數等信息發送給監控中心。定時每分鐘發送一次統計數據到監控中心。
註冊中心宕機：
開發環境：現有的服務不會受影響，如果是新添加或者修改服務，無法完成註冊，有影響。
生產環境：宕機沒有影響，因爲生產環境所有服務已完成，已全部註冊到註冊中心，註冊中心會緩存服務信息。
二、註冊中心 Zookeeper
官方推薦使用 zookeeper 註冊中心。註冊中心負責服務地址的註冊與查找，相當於目錄服務，服務提供者和消費者只在啓動時與註冊中心交互，註冊中心不轉發請求，壓力較小。 Zookeeper 是 Apacahe Hadoop 的子項目，是一個樹型的目錄服務，支持變更推送，適合作爲 Dubbox 服務的註冊中心，工業強度較高，可用於生產環境。
dubbo原理圖：
三、 概念說明
1、RPC
2、分佈式和集羣
