1.Dubbo的作用
Dubbo是管理中間層的工具,在業務層到數據倉庫間有非常多服務的接入和服務提供者需要調度，dubbo提供一個框架解決這個問題。
Dubbo基於RPC（Remote Procedure Call 遠程過程調用）協議，服務提供方和服務消費方之間的調用關系：
節點角色說明：
Provider: 暴露服務的服務提供方。
Consumer: 調用遠程服務的服務消費方。
Registry: 服務注冊與發現的注冊中心。
Monitor: 統計服務的調用次調和調用時間的監控中心。
Container: 服務運行容器。
調用關系說明：
- 0服務容器負責啟動，加載，運行服務提供者。
- 1服務提供者在啟動時，向注冊中心注冊自己提供的服務。
- 2服務消費者在啟動時，向注冊中心訂閱自己所需的服務。
- 3注冊中心返回服務提供者地址列表給消費者，如果有變更，注冊中心將基於長連接推送變更數據給消費者。
- 4服務消費者，從提供者地址列表中，基於軟負載均衡算法，選一台提供者進行調用，如果調用失敗，再選另一台調用。
- 5服務消費者和提供者，在內存中累計調用次數和調用時間，定時每分鍾發送一次統計數據到監控中心。
這個框架要完成調度必須要有一個分布式的注冊中心,存儲所有服務的元數據,用到zookeeper。
2.Zookeeper的作用
zookeeper用來注冊服務和負載均衡。
哪一個服務由哪一個機器來提供必須讓調用者知道,簡單來說就是ip地址和服務器名稱的對應關系。 當然也可以將這種對應關系通過硬編碼在調用方業務代碼中實現，但是如果提供服務的機器掛掉調用方無法知曉，如果不更改代碼會繼續請求掛掉的機器提供服務。zookeeper可以通過心跳機制檢測掛掉的服務器並將掛掉的服務器的ip和服務器對應的關系從列表中刪除。
至於支持高並發，就是橫向擴展，在不更改代碼的情況通過添加機器來提高運算能力。
3.Zookeeper和Dubbo的關系
- Dubbo將注冊中心進行抽象，使得它可以外接不同的存儲媒介給注冊中心提供服務。
- 引入zookeeper作為存儲媒介，也就把zookeeper的特性引了進來。
- 首先是負載均衡：單注冊中心的承載能力是有限的，在流量達到一定程度的時候需要分流，負載均衡就是為了分流而存在的，一個zookeeper集群配合相應的web應用就很容易達到負載均衡；
- 資源同步：單單有負載均衡還不夠，節點之間的數據和資源是需要同步，zookeeper集群就天然具備有這樣的功能；
- 命名服務：將樹狀結構用於維護全局的服務地址列表，服務提供者在啟動的時候，向zookeeper上的指定節點目錄下寫入自己的URL地址，這個操作就完成了服務的發布
- Mast：ZooKeeper能會保證客戶端無法創建一個已經存在的ZNode。也就是說，如果同時有多個客戶端請求創建同一個臨時節點，那么最終一定只有一個客戶端請求能夠創建成功。利用這個特性，就能很容易地在分布式環境中進行Master選舉了。
-
分布式鎖：分布式鎖是控制分布式系統之間同步訪問共享資源的一種方式。當前獲得鎖的客戶端機器發生宕機或重啟，那么該臨時節點就會被刪除，釋放鎖。正常執行完業務邏輯后，客戶端就會主動將自己創建的臨時節點刪除，釋放鎖。
4.dubbo的優點 缺點
優點:
- 透明化的遠程方法調用
像調用本地方法一樣調用遠程方法；只需簡單配置，沒有任何API侵入。
- 軟負載均衡及容錯機制
可在內網替代nginx lvs等硬件負載均衡器。
- 服務注冊中心自動注冊 & 配置管理
不需要寫死服務提供者地址，注冊中心基於接口名自動查詢提供者ip。
使用類似zookeeper等分布式協調服務作為服務注冊中心，可以將絕大部分項目配置移入zookeeper集群。
- 服務接口監控與治理
Dubbo-admin與Dubbo-monitor提供了完善的服務接口管理與監控功能，針對不同應用的不同接口，可以進行 多版本，多協議，多注冊中心管理。
缺點：
- 只支持JAVA語言
5.Dubbo中Zookeeper作為注冊中心,如果zookeeper注冊中心集群都掛掉,服務的發布方和調用方還能通信嗎?
啟動dubbo時,消費者會從zookeeper中拉去注冊的生產者的地址接口等數據,緩存在本地.每次調用時,按照本地存儲的地址進行調用.但是在注冊中心全部掛掉后增加新的提供者,則不能被消費者發現
健壯性:
- 監控中心宕掉不影響使用，只是丟失部分采樣數據
- 數據庫宕掉后，注冊中心仍能通過緩存提供服務列表查詢，但不能注冊新服務
- 注冊中心對等集群，任意一台宕掉后，將自動切換到另一台
- 注冊中心全部宕掉后，服務提供者和服務消費者仍能通過本地緩存通訊
- 服務提供者無狀態，任意一台宕掉后，不影響使用
- 服務提供者全部宕掉后，服務消費者應用將無法使用，並無限次重連等待服務提供者恢復