Dubbo+Zookeeper(二)Dubbo架構
- 2021 年 1 月 14 日
- 筆記
- [09]Dubbo+Zookeeper, dubbo架構
上次更新博客已經是一年前,這一年發生了很多事,並不順利,甚至有些痛苦,不過不管怎樣,不要停止學習,只有學習才能讓你變強,應對更多不安定。
一、RPC概念
Dubbo服務是一個RPC框架,那我們首先就要先理解什麼叫做RPC, Remote Procedure Call 即遠程過程調用。
遠程過程調用相對的是本地過程調用,本地過程調用就不用說了,簡單理解成本地方法調用函數即可,而遠程調用是指調用另一個地址空間(通常是共享網絡的另一台機器上)的過程或函數。而不用程序員顯式編碼這個遠程調用的細節。即程序員無論是調用本地的還是遠程的函數,本質上編寫的調用代碼基本相同。
RPC的基本架構圖如下:
RPC框架就是圖中的client stub 和說server stub,服務間要相互調用,需要先建立連接。當客戶端調用client stub,可能需要傳遞參數,而在網絡間傳遞,需要進行序列化,序列化完全後將需要調用的消息發送給server stub,服務端收到信息後,先反序列化,然後再調用本地服務,調用完本地服務後,返回處理結果,結果也需要進行序列化,序列化完成之後再返回消息,而client stub 收到消息,也需要再次反序列化,再轉換成調用結果,這就是一個完整的RPC過程,如圖所示:
RPC 框架就是要實現像那小助手一樣的東西,目的就是讓我們使用遠程調用像本地調用一樣簡單方便,並且解決一些遠程調用會發生的一些問題 ,對於我們來說是無感知的。
在示例圖中我們也可以看出,RPC的核心模塊就是通訊,序列化。
那如果讓我們來設計一個RPC框架,我們的設計思路應該是怎麼樣的呢?
首先從服務調用者開始,這是一個消費方,我們要消費一個服務,那麼這種服務應該是一個接口形式的,這個接口一般是一個公用jar包來定義,當我知道需要調用什麼接口時,具體的實現不需要清楚,這些都應該是框架代理來做的,我只需要帶接口和參數即可。
消費方不需要知道其中細節,不需要知道要調用那台服務器上的服務,這個時候應該有一個註冊中心,這個註冊中心有點類似公司大樓的前台物業,他負責指引來客人找到找入駐本棟大樓的公司,每個公司類似服務提供者,公司入駐大大樓後,將自己的樓層和門牌號告訴前台,前台把公司的情況貼在前台指引,那麼當有人要找到公司提供服務時,可以直接通過門牌找到想要去的公司,而這個公司搬走後,前台物業又將此公司去掉,消費者需要的服務器是可以直接找到對應公司。
當然,如果你直接告訴了客戶你的具體位置,那麼客戶可以不需要去註冊中心找你,也就是註冊中心可以不需要。
那作為服務提供者,你要告訴別人你公司能提供的服務器,去實現對應的接口 ,然後暴露出去,也就是去向註冊中心註冊自己,暴露自己所能提供的服務。 然後有消費者請求過來需要處理,提供者需要用和消費者協商好的協議來處理這個請求,然後做反序列化。
面對眾多的服務,精細化的監控和方便的運維必不可少。 這個時候我們需要監控運維 ,也就是監控中心,當然如果你要這麼莽,就是不需要監控,當然也是可以的。
到此,我們能想到的架構就是如此,接下里我們就來看看dubbo設計(當然,我是通過實際架構反推出來,手動狗頭)
二、
Dubbo 是阿里巴巴 2011年開源的一個基於 Java 的 RPC 框架,中間沉寂了一段時間,不過其他一些企業還在用 Dubbo 並自己做了擴展,比如噹噹網的 Dubbox,還有網易考拉的 Dubbok。
在 2018 年和 Dubbox 進行了合併,並且進入 Apache 孵化器,在 2019 年正式成為 Apache 頂級項目。
學習一門技術,如果有官網的話我們盡量從官網上學習://dubbo.apache.org/
首先我們要知道Dubbo有哪些特性:
-
面向接口代理的高性能RPC調用: 提供高性能的基於代理的遠程調用能力,服務以接口為粒度,為開發者屏蔽遠程調用底層細節。
-
智能負載均衡: 內置多種負載均衡策略,智能感知下游節點健康狀況,顯著減少調用延遲,提高系統吞吐量。
-
服務自動註冊與發現: 支持多種註冊中心服務,服務實例上下線實時感知。
-
高度可擴展能力: 遵循微內核+插件的設計原則,所有核心能力如Protocol、Transport、Serialization被設計為擴展點,平等對待內置實現和第三方實現。
-
運行期流量調度: 內置條件、腳本等路由策略,通過配置不同的路由規則,輕鬆實現灰度發佈,同機房優先等功能。
-
可視化的服務治理與運維: 提供豐富服務治理、運維工具:隨時查詢服務元數據、服務健康狀態及調用統計,實時下發路由策略、調整配置參數。
三、
架構分為5個節點:
服務提供者( Provider ):暴露服務的服務提供方,服務提供者在啟動時,向註冊中心註冊自己提供的服務。
服務消費者( Consumer ): 調用遠程服務的服務消費方,服務消費者在啟動時,向註冊中心訂閱自己所需的服務,服務消費者,從提供者地址列表中,基於軟負載均衡算法,選一台提供者進行調用,如果調用失敗,再選另一台調用。
註冊中心( Registry ):註冊中心返回服務提供者地址列表給消費者,如果有變更,註冊中心將基於長連接推送變更數據給消費者
監控中心( Monitor ):服務消費者和提供者,在內存中累計調用次數和調用時間,定時每分鐘發送一次統計數據到監控中心
服務運行容器 ( Container ) :負責啟動,加載,運行服務提供者
他們的調用關係如下:
-
服務容器負責啟動,加載,運行服務提供者。
-
服務容器負責啟動,加載,運行服務提供者。
-
服務消費者在啟動時,向註冊中心訂閱自己所需的服務。
-
註冊中心返回服務提供者地址列表給消費者,如果有變更,註冊中心將基於長連接推送變更數據給消費者。
-
服務消費者,從提供者地址列表中,基於軟負載均衡算法,選一台提供者進行調用,如果調用失敗,再選另一台調用。
-
服務消費者和提供者,在內存中累計調用次數和調用時間,定時每分鐘發送一次統計數據到監控中心。
dubbo的架構非常清晰,也很容易理解,我們在學習的時候,先了解清楚架構情況,然後學會使用,然後再去看源碼,了解基礎的代碼結構。
四、特性
Dubbo 架構具有以下幾個特點,分別是連通性、健壯性、伸縮性。
連通性:
-
註冊中心負責服務地址的註冊與查找,相當於目錄服務,服務提供者和消費者只在啟動時與註冊中心交互,註冊中心不轉發請求,壓力較小
-
監控中心負責統計各服務調用次數,調用時間等,統計先在內存匯總後每分鐘一次發送到監控中心服務器,並以報表展示
-
服務提供者向註冊中心註冊其提供的服務,並彙報調用時間到監控中心,此時間不包含網絡開銷
-
服務消費者向註冊中心獲取服務提供者地址列表,並根據負載算法直接調用提供者,同時彙報調用時間到監控中心,此時間包含網絡開銷
-
註冊中心,服務提供者,服務消費者三者之間均為長連接,監控中心除外
-
註冊中心通過長連接感知服務提供者的存在,服務提供者宕機,註冊中心將立即推送事件通知消費者
-
註冊中心和監控中心全部宕機,不影響已運行的提供者和消費者,消費者在本地緩存了提供者列表
-
註冊中心和監控中心都是可選的,服務消費者可以直連服務提供者
健壯性:
-
監控中心宕掉不影響使用,只是丟失部分採樣數據
-
數據庫宕掉後,註冊中心仍能通過緩存提供服務列表查詢,但不能註冊新服務
-
註冊中心對等集群,任意一台宕掉後,將自動切換到另一台
-
註冊中心全部宕掉後,服務提供者和服務消費者仍能通過本地緩存通訊
-
服務提供者無狀態,任意一台宕掉後,不影響使用
-
服務提供者全部宕掉後,服務消費者應用將無法使用,並無限次重連等待服務提供者恢復
伸縮性:
-
註冊中心為對等集群,可動態增加機器部署實例,所有客戶端將自動發現新的註冊中心
-
服務提供者無狀態,可動態增加機器部署實例,註冊中心將推送新的服務提供者信息給消費者
好了,Dubbo架構我們有了基礎的了解,接下來,我們開始實際例子的開發。