核心概念
application(應用)
實際使用配置的應用，Apollo客戶端在運行時需要知道當前應用是誰，從而可以去獲取對應的配置，每個應用都需要有一個唯一的身份標識——appId。
environment(環境)
配置對應的環境，比如開發環境、測試環境、生產環境等，Apollo客戶端在運行時需要知道當前應用處於哪個環境，從而獲取相應的配置。同一份代碼部署在不同的環境就應該能夠獲取到不同環境的配置。一般通過server.properties中的env屬性指定。
cluster(集羣)
一個應用下不同實例的分組，對不同的cluster，同一個配置可以有不一樣的值。
namespace(命令空間)
一個應用下不同配置的分組，可以把namespace類比爲文件，不同類型的配置存放在不同的文件中，比如數據庫文件、RPC配置文件等。應用可以直接讀取到公共組件的配置namespace，也可以通過集成公共組件的配置namespace對組件配置做調整。
整體架構
Config Service
給客戶端Client提供配置的獲取、推送等功能；
Admin service
給管理界面Portal提供配置的修改、發佈等功能。相當於Portal的後臺管理系統。
Meta Server
用於封裝Eureka的服務發現接口。
Meta Server從Eureka獲取Config Service和Admin Service的服務信息，然後Client和Portal通過http接口獲取服務信息。
- Client通過域名訪問Meta Server獲取Config Service服務列表，而後直接通過IP+Port訪問服務，同時在Client側會做負載均衡、錯誤重試。
- Portal通過域名訪問Meta Server獲取Admin Service服務列表。
Eureka
提供服務註冊和服務發現
- Config Service和Admin Service會向Eureka註冊服務，並保持心跳；
- Eureka和Config Service時在一個JVM進程中的。
Portal
- 提供Web界面供用戶管理配置
Client
- Apollo提供的客戶端程序，爲應用提供配置獲取、實時更新等功能；
配置發佈的大致過程
1、用戶在Portal操作配置發佈；
2、Portal調用Admin Service的接口操作發佈；
3、Admin Service發佈配置後，發送ReleaseMessage給各個Config Service；
4、Config Service收到ReleaseMessage後，通知對應的客戶端。
發送ReleaseMessage的實現方式
Admin Service 在配置發佈之後，需要通知所有的Config Service有配置發佈。這個過程是一個典型的消息使用場景，爲了儘可能減少外部依賴，沒有采用外部消息中間件，而是通過數據庫實現了一個簡單的消息隊列。
1、Admin Service在配置發佈之後會往ReleaseMessage表中插入一條消息記錄，內容就是配置發佈的AppId+Cluster+Namespace。
2、Config Service每秒掃描一次ReleaseMessage表，看看是否有新的消息記錄。
3、如果發現有新的記錄，那麼就會通知到所有的消息監聽器。
4、消息監聽器得到發佈的ReleaseMessage後，會通知對應客戶端。
Config Service通知客戶端的實現方式
- 客戶端會發起一個Http請求到Config Service的消息監聽器；
- 消息監聽器不會立即返回結果，而是通過長連接把請求掛起；
- 如果60秒內沒有改客戶端關心的配置發佈，那麼會返回304給客戶端；
- 如果有該客戶端關心的配置發佈，消息監聽器會調用方法傳入有配置變化的namespace信息，同時該請求立即返回，客戶端從所返回的結果中獲取到namespace後，立即請求Config Service獲取該namespace最新配置。