【架構師視角系列】QConfig配置中心繫列之架構設計(一)

聲明

原創文章,轉載請標註。https://www.cnblogs.com/boycelee/p/17993697
《碼頭工人的一千零一夜》是一位專注於技術乾貨分享的博主,追隨博主的文章,你將深入瞭解業界最新的技術趨勢,以及在Java開發和安全領域的實用經驗分享。無論你是開發人員還是對逆向工程感興趣的愛好者,都能在《碼頭工人的一千零一夜》找到有價值的知識和見解。

配置中心繫列文章

《【架構師視角系列】Apollo配置中心之架構設計(一)》https://www.cnblogs.com/boycelee/p/17967590
《【架構師視角系列】Apollo配置中心之Client端(二)》https://www.cnblogs.com/boycelee/p/17978027
《【架構師視角系列】Apollo配置中心之Server端(ConfigSevice)(三)》https://www.cnblogs.com/boycelee/p/18005318
《【架構師視角系列】QConfig配置中心繫列之架構設計(一)》https://www.cnblogs.com/boycelee/p/18013653

一、架構

基礎模型

架構圖

架構分層

架構分層可以分爲四層,分別是客戶端層、網絡層、服務層以及數據層,其中客戶端層包括Client模塊和Admin模塊,網絡層包括Server模塊中的EntryPoint部分和NginxLB以及Eureka,服務層僅包括Server模塊。

運行規則

(1)Server將自己註冊到註冊中心Eureka中,

(2)當三方應用拉取配置時,Client端通過訪問域名的方式,請求經過NginxLB訪問到EntryPoint並從Eureka中獲取到已註冊的Server列表及其對應IP、端口信息,這時Client端就可以通過ip+port的形式直接訪問到已註冊的某個Server實例,獲取到對應配置信息。

(3)當管理人員操作配置時,可以通過獨立部署的Admin模塊(管理平臺)直接訪問數據庫,對配置數據進行增刪查改操作。

(4)當管理人員發佈配置時,Client端通過訪問域名的方式,請求經過NginxLB訪問到EntryPoint並從Eureka中獲取到已註冊的Server列表及其對應IP、端口信息,這時Admin端就可以通過ip+port的形式直接訪問到所有已註冊的Server實例,獲取到對應配置信息。

模塊劃分

相對於Apollo的分層,Qconfig的分層相對更簡單一些,大致分爲三個模塊分別是Admin模塊、Client模塊、Server模塊。

Admin模塊

提供web界面用於配置管理。但與Apollo配置中心不同的地方在於Qconfig的模塊劃分並沒有Apollo這麼明確,所有與配置操作相關的邏輯都在Admin模塊中。

其中包括:

  • 應用創建、查看、修改、發佈以及回滾等功能
  • 提供修改、發佈配置等接口。
  • 配置變更時通知Server

Client模塊

提供實時配置獲取與更新。其與Apollo中的模塊職責是一樣的。

其中包括:

  • 客戶端負責從Config Service獲取應用的配置信息;
  • 監聽配置變化。當配置發生更新時,Config Service會通知Client,並出發其進行配置刷新;
  • 通過ip + port的方式遠程調用Config Service,以獲取配置數據。

Server模塊

服務於Client端,爲客戶端提供獲取配置的接口。

其中包括:

  • 基於長輪詢,提供配置更新接口;
  • 提供配置獲取接口。

二、總結

(1)Apollo和QConfig都是攜程集團的配置中心項目,Apollo主要在攜程內部使用,而Qconfig主要去哪兒內部使用;

(2)從開源社區維護角度上,相對而言Apollo的開源工作要做得好很多;

(3)從架構設計和代碼整潔這兩個維度上,個人覺得QConfig要做得更優秀一些。

三、最後

《碼頭工人的一千零一夜》是一位專注於技術乾貨分享的博主,追隨博主的文章,你將深入瞭解業界最新的技術趨勢,以及在Java開發和安全領域的實用經驗分享。無論你是開發人員還是對逆向工程感興趣的愛好者,都能在《碼頭工人的一千零一夜》找到有價值的知識和見解。

懂得不多,做得太少。歡迎批評、指正。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章