配置中心：Apollo

來源：
《微服務架構實戰160講》

Apollo配置中心

1 解決的問題

2 場景

如AB測試：測試新功能時，少量beta用戶進行測試新功能，即走上面一條線的邏輯，如果反饋好，就將ab_test_flag設置爲false，所有用戶都可以在beta上進行，走新功能，即新功能正式啓用

開關驅動開發：

如Git flow：使用開關驅動開發，在主幹Trunk上提交代碼而不是開分支，減少分支數從而減少衝突（TBD開發），修改代碼則使用Branch by Abstraction：

3 核心概念

應用（application）：有唯一標識 appId

環境（environment）：配置對應的環境，如DEV,FAT,UAT,PRO

集羣（cluster）：一個應用下不同實例的分組

名字空間（namespace）：一個應用下不同配置的分組；會有不同的類型，進行私有或公有化，還可以繼承；

配置項（item）：表示可配置項，支持 properties/ json/xml格式，分爲私有配置和公有配置；

權限：分爲系統管理員、創建項目者、項目管理員、普通用戶

4 服務端架構

• 整體架構
  
  圖中紅框爲基本架構（Portal+PortalDB+Client+ConfigService+AdminService+ConfigDB），引入Eureka解決服務發現的問題，MetaServer是對Eureka簡單的封裝，解決跨語言的問題（Portal和Client直接去Eureka查詢的話，只能使用Java），NginxLB解決Client和Portal如何找到MetaServer的問題（MetaServer有多個，負載均衡），用戶只跟Portal交互

• 領域模型：一個APP可以有多個Cluster，一個Cluster可以有多個Namespace
  

• 權限模型
  

• 實時推送設計
  

• 上圖中的ReleaseMassage實現：數據庫充當隊列
  

5 客戶端架構

推拉結合雙保險（實時推送失效時還有定期拉配置作爲保障） 、在內存又配置了一份緩存、應用程序獲取配置、更新通知

6 高可用

從服務端架構圖可以看出SLB是關鍵，且每個組件都有多個實例，而DB出問題的話，ConfigService、AdminService、Portal做了一份緩存，達到高可用，一致性就無法保障了

7 監控

內置支持CAT，需要擴展的話可以使用InfluxDB、Prometheus

• 關鍵指標

接入應用數量
配置項數量
變更和發佈數量
推送拉取次數(success/failure)
ConfigConfig：接口性能、GC、CPU