dubbo 初識(1)

• 參考dubbo 中文官方文檔：http://dubbo.apache.org/zh-cn/docs/user/preface/architecture.html
• 分佈式架構的發展過程

 

　　

　　1.初始小型的項目採用單體結構，一臺服務器部署多個應用，關注點主要在ORM(對象關係模型)。

　　2.隨着業務的增多，訪問的數據增大開始用多臺服務器部署多個應用，將大業務拆分紅小業務模塊，關注點在MVC(開發模式業務分層)。

　　3.當業務更多的時候，不少核心業務能夠服用，而且想要穩定核心業務，此時RPC(遠程服務)成爲關注點。

　　4.全部的業務模塊互相調用，交叉很嚴重，此時須要一個調度中心，統一管理服務的註冊與監聽,此時SOA(服務治理解決方案)成爲關注點

 

• dubbo 出現的意義

　　基於上面第四點，亟需一個服務註冊與發現管理中心，統一管理全部的服務。dubbo 解決如下需求：

　　

當服務愈來愈多時，服務 URL 配置管理變得很是困難，F5 硬件負載均衡器的單點壓力也愈來愈大。

　　 此時須要一個服務註冊中心，動態地註冊和發現服務，使服務的位置透明。並經過在消費方獲取服務提供方地址列表，實現軟負載均衡和 Failover，下降對 F5 硬件負載均衡器的依賴，也能減小部分紅本。

當進一步發展，服務間依賴關係變得錯蹤複雜，甚至分不清哪一個應用要在哪一個應用以前啓動，架構師都不能完整的描述應用的架構關係。 

　　這時，須要自動畫出應用間的依賴關係圖，以幫助架構師理清理關係。

接着，服務的調用量愈來愈大，服務的容量問題就暴露出來，這個服務須要多少機器支撐？何時該加機器？ 

　　爲了解決這些問題，第一步，要將服務如今天天的調用量，響應時間，都統計出來，做爲容量規劃的參考指標。其次，要能夠動態調整權重，在線上，將某臺機器的權重一直加大，並在加大的過程當中記錄響應時間的變化，直到響應時間到達閾值，記錄此時的訪問量，再以此訪問量乘以機器數反推總容量。

 

• dubbo 的架構

　角色說明：

 

節點	角色說明
Provider	暴露服務的服務提供方
Consumer	調用遠程服務的服務消費方
Registry	服務註冊與發現的註冊中心
Monitor	統計服務的調用次數和調用時間的監控中心
Container	服務運行容器

　　

調用關係說明

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