爲何要用dubbo，dubbo是什麼，爲何要和zk結合使用？

目錄

　　爲何要用dubbo

　　dubbo是什麼

　　dubbo架構

　　dubbo和zk關係

爲何要用dubbo？

　隨着互聯網的發展，網站的應用規模不斷擴大，常規的垂直架構已經沒法應，分佈式服務架構勢在必行，亟需一個治理系統架構的方案。

　　1)單一架構，當網站流量很小，咱們將全部的功能都部署到一塊兒，減小部署節點和成本。此時，用於簡化增刪改工做量，ORM是關鍵

　　2)垂直架構，當訪問逐漸增大，單一機器的速度顯然不理想，將應用拆成幾個不相干的應用，以便提高效率。此時，用於加速前端訪問，MVC是關鍵。

　　3)分佈式服務架構，當垂直應用愈來愈多，應用之間的交互不可避免。將核心的業務抽取出來，做爲獨立的服務，使前端應用能夠快速響應多變的市場需求。此時，提升業務的複用整合的RPC框架是關鍵。

　　4)當咱們服務愈來愈多，容量評估以及小服務資源浪費的問題逐漸展示出來。此時就須要一個調度中心基於訪問壓力實時的去管理集羣容量，提升集羣利用率。此時用於提升集羣利用率和資源問題soa是關鍵。

dubbo是什麼？

　　Dubbo是 阿里巴巴公司開源的一個高性能優秀的服務框架，使得應用可經過高性能的 RPC 實現服務的輸出和輸入功能，能夠和Spring框架無縫集成。

　　Dubbo是一個分佈式服務框架，致力於提供高性能和透明化的RPC遠程服務調用方案，以及SOA服務治理方案。簡單的說，dubbo就是個服務框架，若是沒有分佈式的需求，實際上是不須要用的，只有在分佈式的時候，纔有dubbo這樣的分佈式服務框架的需求。其本質上是個遠程服務調用的分佈式框架（告別Web Service模式中的WSdl，以服務者與消費者的方式在dubbo上註冊）

　　其核心部分包含:　

　　　Remoting: 網絡通訊框架，實現了 sync-over-async 和 request-response 消息機制
　　　RPC: 一個遠程過程調用的抽象，支持負載均衡、容災和集羣功能
　　　Registry: 服務目錄框架用於服務的註冊和服務事件發佈和訂閱

　　　遠程通信: 提供對多種基於長鏈接的NIO框架抽象封裝，包括多種線程模型，序列化，以及「請求-響應」模式的信息交換方式。
　　　集羣容錯: 提供基於接口方法的透明遠程過程調用，包括多協議支持，以及負載均衡、失敗容錯、地址路由、動態配置等集羣支持。
　　　自動發現: 基於註冊中心目錄服務，使服務消費方能動態的查找服務提供方，使地址透明，使服務提供方能夠平滑增長或減小機器。

dubbo架構

各個節點角色說明：

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

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

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

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

       Container: 服務運行容器。

 

調用關係說明：

　　1. 服務容器負責啓動，加載，運行服務提供者。
　　2. 服務提供者在啓動時，向註冊中心註冊本身提供的服務。
　　3. 服務消費者在啓動時，向註冊中心訂閱本身所需的服務。
　　4. 註冊中心返回服務提供者地址列表給消費者，若是有變動，註冊中心將基於長鏈接推送變動數據給消費者。
　　5. 服務消費者，從提供者地址列表中，基於軟負載均衡算法，選一臺提供者進行調用，若是調用失敗，再選另外一臺調用。
　　6. 服務消費者和提供者，在內存中累計調用次數和調用時間，定時每分鐘發送一次統計數據到監控中心。

dubbo爲何須要和zookeeper結合使用，zookeeper在dubbo體系中起到什麼做用？   

　　dubbo是一個prc遠程服務調用框架，須要一個註冊中心去管理每一個服務的集羣。zookeeper在dubbo中扮演一個註冊中心的角色（固然也能夠不選擇zookeeper）,zookeeper用來註冊服務和進行負載均衡。

　　詳述：哪個服務由哪個機器來提供，必須讓調用者知道。也就是ip地址和服務名對應關係。也能夠把這種對應關係經過硬編碼的方式加在調用者的業務中，可是一旦提供的服務掛掉調用者沒法知曉。zookeeper經過心跳機制來檢測並將掛掉的機器從列表中刪除。能夠在不更改代碼的狀況下經過添加機器來解決高併發。