Apollo-原理以及架構圖分析

核心組件

ConfigService

AdminService

Client

Portal

Eureka

MetaServer

NginxLB

技術架構

Apollo的技術架構是完全的微服務部署架構，但是和apollo的創始人溝通之後,發現其實apollo技術架構一直在不斷的升級，下面就把Apollo的架構版本演變之路通過圖形展示出來，這樣可以更加容易理解Apollo的技術架構

1.0版本

ConfigService是一個獨立的微服務，服務於Client進行配置獲取。
Client和ConfigService保持長連接，通過一種推拉結合(push & pull)的模式，在實現配置實時更新的同時，保證配置更新不丟失。
AdminService是一個獨立的微服務，服務於Portal進行配置管理。Portal通過調用AdminService進行配置管理和發佈。
ConfigService和AdminService共享ConfigDB，ConfigDB中存放項目在某個環境中的配置信息。ConfigService/AdminService/ConfigDB三者在每個環境(DEV/FAT/UAT/PRO)中都要部署一份。
Protal有一個獨立的PortalDB，存放用戶權限、項目和配置的元數據信息。Protal只需部署一份，它可以管理多套環境。

2.0版本

Config/AdminService啓動後都會註冊到Eureka服務註冊中心，並定期發送保活心跳。 Eureka採用集羣方式部署，使用分佈式一致性協議保證每個實例的狀態最終一致。

3.0版本

基於Eureka實現服務註冊發現+客戶端Ribbon配合實現軟路由

4.0版本

引入了MetaServer這個角色，它其實是一個Eureka的Proxy，將Eureka的服務發現接口以更簡單明確的HTTP接口的形式暴露出來，方便Client/Protal通過簡單的HTTPClient就可以查詢到Config/AdminService的地址列表

5.0版本

Apollo當前完整的技術架構

客戶端推送更新架構

客戶端和服務端保持了一個長連接，從而能第一時間獲得配置更新的推送。
客戶端還會定時從Apollo配置中心服務端拉取應用的最新配置。
- 這是一個fallback機制，爲了防止推送機制失效導致配置不更新
- 客戶端定時拉取會上報本地版本，所以一般情況下，對於定時拉取的操作，服務端都會返回304 - Not Modified
- 定時頻率默認爲每5分鐘拉取一次，客戶端也可以通過在運行時指定System Property: apollo.refreshInterval來覆蓋，單位爲分鐘。
客戶端從Apollo配置中心服務端獲取到應用的最新配置後，會保存在內存中
客戶端會把從服務端獲取到的配置在本地文件系統緩存一份
- 在遇到服務不可用，或網絡不通的時候，依然能從本地恢復配置
應用程序從Apollo客戶端獲取最新的配置、訂閱配置更新通知

服務端機制

服務端會保持住這個連接60秒
- 如果在60秒內有客戶端關心的配置變化，被保持住的客戶端請求會立即返回，並告知客戶端有配置變化的namespace信息，客戶端會據此拉取對應namespace的最新配置
- 如果在60秒內沒有客戶端關心的配置變化，那麼會返回Http狀態碼304給客戶端
客戶端在收到服務端請求後會立即重新發起連接，回到第一步

核心原理

服務端Spring DeferredResult來服務Http Long Polling請求