最近在做項目中用的是阿里的框架Dubbo+zookeeper,可是並不知道什麼是dubbo,什麼是zookeeper，這一系列的問題，引導者我們去不斷的探索。今天我們來看看阿里的分佈式服務架構——Dubbo。
1、是什麼
Dubbo是一個分佈式服務框架，致力於提供高性能和透明化的RPC遠程服務調用方案，以及SOA服務治理方案。
簡單的說，dubbo就是個服務框架，如果沒有分佈式的需求，其實是不需要用的，只有在分佈式的時候，纔有dubbo這樣的分佈式服務框架的需求，並且本質上是個服務調用的東東
說白了就是個遠程服務調用的分佈式框架（告別Web Service模式中的WSdl，以服務者與消費者的方式在dubbo上註冊）
2、核心
（1）remoting：遠程通訊基礎，提供對多種基於長連接的NIO框架抽象封裝，包括多種線程模型，序列化，以及“請求-響應”模式的信息交換方式。
（2）Cluster:服務框架核心提供基於接口方法的透明遠程過程調用，包括多協議支持，以及軟負載均衡，失敗容錯，地址路由，動態配置等集羣支持。
（3）registry:自動發現: 基於註冊中心目錄服務，使服務消費方能動態的查找服務提供方，使地址透明，使服務提供方可以平滑增加或減少機器。
3、做什麼
透明化的遠程方法調用，就像調用本地方法一樣調用遠程方法，只需簡單配置，沒有任何API侵入。 軟負載均衡及容錯機制，可在內網替代F5等硬件負載均衡器，降低成本，減少單點。服務自動註冊與發現，不再需要寫死服務提供方地址，註冊中心基於接口名查詢服務提供者的IP地址，並且能夠平滑添加或刪除服務提供者。注： Dubbo採用全Spring配置方式，透明化接入應用，對應用沒有任何API侵入，只需用Spring加載Dubbo的配置即可，Dubbo基於Spring的Schema擴展進行加載。
4、產生背景
在大規模服務化之前，應用可能只是通過RMI或Hessian等工具，簡單的暴露和引用遠程服務，通過配置服務的URL地址進行調用，通過F5等硬件進行負載均衡。
傳統的遠程調用
dubbo服務治理
dubbo處理後的遠程調用
(1) 當服務越來越多時，服務URL配置管理變得非常困難，F5硬件負載均衡器的單點壓力也越來越大。此時需要一個服務註冊中心，動態的註冊和發現服務，使服務的位置透明。並通過在消費方獲取服務提供方地址列表，實現軟負載均衡和Failover，降低對F5硬件負載均衡器的依賴，也能減少部分成本。
(2) 當進一步發展，服務間依賴關係變得錯蹤複雜，甚至分不清哪個應用要在哪個應用之前啓動，架構師都不能完整的描述應用的架構關係。這時，需要自動畫出應用間的依賴關係圖，以幫助架構師理清理關係。
(3) 接着，服務的調用量越來越大，服務的容量問題就暴露出來，這個服務需要多少機器支撐？什麼時候該加機器？爲了解決這些問題，第一步，要將服務現在每天的調用量，響應時間，都統計出來，作爲容量規劃的參考指標。
其次，要可以動態調整權重，在線上，將某臺機器的權重一直加大，並在加大的過程中記錄響應時間的變化，直到響應時間到達閥值，記錄此時的訪問量，再以此訪問量乘以機器數反推總容量。
總結：
通過此次學習，我們簡單瞭解了一下dubbo,知道了dubbo是一個分佈式服務框架，下次，我們將dobbo的原理解析一下，希望大家繼續關注。
