Apollo工作原理
Apollo架構模塊的概覽
上圖簡要描述了Apollo的總體設計，我們可以從下往上看：
- Config Service提供配置的讀取、推送等功能，服務對象是Apollo客戶端
- Admin Service提供配置的修改、發佈等功能，服務對象是Apollo Portal（管理界面）
- Eureka提供服務註冊和發現，爲了簡單起見，目前Eureka在部署時和Config Service是在一個JVM進程中的
- Config Service和Admin Service都是多實例、無狀態部署，所以需要將自己註冊到Eureka中並保持心跳
在Eureka之上架了一層Meta Server用於封裝Eureka的服務發現接口 - Client通過域名訪問Meta Server獲取Config Service服務列表（IP+Port），而後直接通過IP+Port訪問服務，
同時在Client側會做load balance、錯誤重試 - Portal通過域名訪問Meta Server獲取Admin Service服務列表（IP+Port），而後直接通過IP+Port訪問服務，
同時在Portal側會做load balance、錯誤重試爲了簡化部署，我們實際上會把Config Service、Eureka和Meta Server三個邏輯角色部署在同一個JVM進程中
分步執行流程
- Apollo啓動後，Config/Admin Service會自動註冊到Eureka服務註冊中心，並定期發送保活心跳。
- Apollo Client和Portal管理端通過配置的Meta Server的域名地址經由Software Load Balancer(軟件負載均衡
器)進行負載均衡後分配到某一個Meta Server - Meta Server從Eureka獲取Config Service和Admin Service的服務信息，相當於是一個Eureka Client
- Meta Server獲取Config Service和Admin Service（IP+Port）失敗後會進行重試
- 獲取到正確的Config Service和Admin Service的服務信息後，Apollo Client通過Config Service爲應用提供配
置獲取、實時更新等功能；Apollo Portal管理端通過Admin Service提供配置新增、修改、發佈等功能
核心概念
- application (應用)
這個很好理解，就是實際使用配置的應用，Apollo客戶端在運行時需要知道當前應用是誰，從而可以去獲取
對應的配置
關鍵字：appId - environment (環境)
配置對應的環境，Apollo客戶端在運行時需要知道當前應用處於哪個環境，從而可以去獲取應用的配置
關鍵字：env - cluster (集羣)
一個應用下不同實例的分組，比如典型的可以按照數據中心分，把上海機房的應用實例分爲一個集羣，把北
京機房的應用實例分爲另一個集羣。
關鍵字：cluster - namespace (命名空間)
一個應用下不同配置的分組，可以簡單地把namespace類比爲文件，不同類型的配置存放在不同的文件中，
如數據庫配置文件，RPC配置文件，應用自身的配置文件等
關鍵字：namespaces
它們的關係如下圖所示：
