dubbo與zookeeper的關系

 

Dubbo建議使用Zookeeper作為服務的注冊中心。

 

 

1.   Zookeeper的作用：

 

        zookeeper用來注冊服務和進行負載均衡，哪一個服務由哪一個機器來提供必需讓調用者知道，簡單來說就是ip地址和服務名稱的對應關系。當然也可以 通過硬編碼的方式把這種對應關系在調用方業務代碼中實現，但是如果提供服務的機器掛掉調用者無法知曉，如果不更改代碼會繼續請求掛掉的機器提供服務。 zookeeper通過心跳機制可以檢測掛掉的機器並將掛掉機器的ip和服務對應關系從列表中刪除。至於支持高並發，簡單來說就是橫向擴展，在不更改代碼 的情況通過添加機器來提高運算能力。通過添加新的機器向zookeeper注冊服務，服務的提供者多了能服務的客戶就多了。

 

 

 

 

2.  dubbo：

 

      是管理中間層的工具，在業務層到數據倉庫間有非常多服務的接入和服務提供者需要調度，dubbo提供一個框架解決這個問題。

 

      注意這里的dubbo只是一個框架，至於你架子上放什么是完全取決於你的，就像一個汽車骨架，你需要配你的輪子引擎。這個框架中要完成調度必須要有一個分布式的注冊中心，儲存所有服務的元數據，你可以用zk，也可以用別的，只是大家都用zk。

　　Dubbo致力於提供高性能和透明化的RPC遠程服務調用方案，以及SOA服務治理方案。簡單的說，dubbo就是個服務框架，如果沒有分布式的需求，其實是不需要用的，只有在分布式的時候，才有dubbo這樣的分布式服務框架的需求，並且本質上是個服務調用的東東，說白了就是個遠程服務調用的分布式框架。

 

3. zookeeper和dubbo的關系：

      Dubbo的將注冊中心進行抽象，是得它可以外接不同的存儲媒介給注冊中心提供服務，有ZooKeeper，Memcached，Redis等。

      引入了ZooKeeper作為存儲媒介，也就把ZooKeeper的特性引進來。首先是負載均衡，單注冊中心的承載能力是有限的，在流量達到一定程度的時 候就需要分流，負載均衡就是為了分流而存在的，一個ZooKeeper群配合相應的Web應用就可以很容易達到負載均衡；資源同步，單單有負載均衡還不 夠，節點之間的數據和資源需要同步，ZooKeeper集群就天然具備有這樣的功能；命名服務，將樹狀結構用於維護全局的服務地址列表，服務提供者在啟動 的時候，向ZK上的指定節點/dubbo/${serviceName}/providers目錄下寫入自己的URL地址，這個操作就完成了服務的發布。 其他特性還有Mast選舉，分布式鎖等。

 

 

節點角色說明：

· Provider: 暴露服務的服務提供方。

· Consumer: 調用遠程服務的服務消費方。

· Registry: 服務注冊與發現的注冊中心。

· Monitor: 統計服務的調用次調和調用時間的監控中心。

· Container: 服務運行容器。

調用關系說明：

· 0. 服務容器負責啟動，加載，運行服務提供者。

· 1. 服務提供者在啟動時，向注冊中心注冊自己提供的服務。

· 2. 服務消費者在啟動時，向注冊中心訂閱自己所需的服務。

· 3. 注冊中心返回服務提供者地址列表給消費者，如果有變更，注冊中心將基於長連接推

送變更數據給消費者。

· 4. 服務消費者，從提供者地址列表中，基於軟負載均衡算法，選一台提供者進行調用，

如果調用失敗，再選另一台調用。

· 5. 服務消費者和提供者，在內存中累計調用次數和調用時間，定時每分鍾發送一次統計

數據到監控中心。

 

相似框架SpringCloud：

springcloud是基於springboot的，另外springcloud的更新也要比dubbo更新快的多，相比較dubbo：開發簡潔 支持restful開發 。

而現如今國內還是使用dubbo的比較多、有中文文檔、技術比較成熟了，國外使用springcloud比較多

springcloud整合了大量的第三方組件、但是優點在於springboot的自動化配置

dubbo提供的rpc調用，springcloud支持restful調用：

兩種的區別：

dubbo服務提供方與調用方接口依賴方式太強：我們為每個微服務定義了各自的service抽象接口，並通過持續集成發布到私有倉庫中，調用方應用對微服務提供的抽象接口存在強依賴關系，因此不論開發、測試、集成環境都需要嚴格的管理版本依賴，才不會出現服務方與調用方的不一致導致應用無法編譯成功等一系列問題，以及這也會直接影響本地開發的環境要求，往往一個依賴很多服務的上層應用，每天都要更新很多代碼並install之后才能進行后續的開發。若沒有嚴格的版本管理制度或開發一些自動化工具，這樣的依賴關系會成為開發團隊的一大噩夢。而springcloud REST調用方式相比RPC更為輕量化，服務提供方和調用方的依賴只是依靠一紙契約，不存在代碼級別的強依賴，當然REST接口也有痛點，因為接口定義過輕，很容易導致定義文檔與實際實現不一致導致服務集成時的問題，但是該問題很好解決，只需要通過每個服務整合swagger，讓每個服務的代碼與文檔一體化，就能解決。所以在分布式環境下，REST方式的服務依賴要比RPC方式的依賴更為靈活。

dubbo服務對平台敏感，難以簡單復用：通常我們在提供對外服務時，都會以REST的方式提供出去，這樣可以實現跨平台的特點，任何一個語言的調用方都可以根據接口定義來實現。那么在Dubbo中我們要提供REST接口時，不得不實現一層代理，用來將RPC接口轉換成REST接口進行對外發布。若我們每個服務本身就以REST接口方式存在，當要對外提供服務時，主要在API網關中配置映射關系和權限控制就可實現服務的復用了。

相信這些痛點也是為什么當當網在dubbox（基於Dubbo的開源擴展）中增加了對REST支持的原因之一。