1.引言
dubbo是開發分佈式系統
所常用的RPC框架
1.1 分佈式系統
分佈式系統是若干獨立計算機的集合,這些計算機對於用戶來說就像是單個系統
簡單來說就是"很多個計算機(服務)合起來爲用戶提供系統服務,用戶在使用時感覺在用單個完整的系統"
1.2 RPC
遠程過程調用,一種進程間的通信方式
2.dubbo架構
2.1 系統架構演變
2.1.1 階段1:集中式架構
一個應用中包含所有的功能,例如訂單,用戶等
缺陷:
1.擴展不容易,如果要修改應用中某一個功能都會導致把整個應用重新打包
2.協同開發不容易,大家都去改同一個應用,可能會改亂,不利於維護
3.應用規模不大擴大後(功能越來越多),單體壓力很大,光靠增加服務器的部署不能提升性能
2.1.2 階段2:分佈式系統
將一個單體的應用,根據功能拆分成多個小應用,將各個應用獨立部署到服務器上
按功能進行垂直拆分
每一個應用都有三層架構
缺點:
1.頁面和業務邏輯的分離, 因爲在實際開發中,頁面可能天天都需要改動,改一下頁面就要重新對所有項目打包(服務層)部署,不合理,所以我們需要將頁面和業務拆分
2.多個系統間,會有交互,例如在訂單模塊中可能要使用用戶模塊的功能查詢用戶信息(應用不可能完全獨立),大量的應用之間需要交互
2.1.3 階段3:分佈式架構,共享服務
形成分佈式架構,把 核心業務 抽取成服務,形成服務中心
存在的問題:當服務越來越多,容量的評估,小服務資源的浪費等問題逐漸顯現,此時需增加一個調度中心基於訪問壓力實時管理集羣容量,提高集羣利用率。 此時,用於提高機器利用率的資源調度和治理中心
缺點:調用關係太複雜
2.1.4 階段4:服務治理
Dubbo就是資源調度和治理中心,用來解決這些問題的
2.2 dubbo架構
架構圖:
調用關係說明:
- 服務容器負責啓動,加載,運行服務提供者。
- 服務提供者在啓動時,向註冊中心註冊自己提供的服務
- 服務消費者在啓動時,向註冊中心訂閱自己所需的服務。
- 註冊中心返回服務提供者地址列表給消費者,如果有變更,註冊中心將基於長連接推送變更數據給消費者。
- 服務消費者,從提供者地址列表中,基於軟負載均衡算法,選一臺提供者進行調用,如果調用失敗,再選另一臺調用。
- 服務消費者和提供者,在內存中累計調用次數和調用時間,定時每分鐘發送一次統計數據到監控中心。