Apollo配置中心介紹

一、Apollo配置中心介紹

1.1 背景

随着程式功能的日益複雜，程式的配置日益增多：各種功能的開關、參數的配置、伺服器的位址……

對程式配置的期望值也越來越高：配置修改後實時生效，灰階釋出，分環境、分叢集管理配置，完善的權限、稽核機制……

在這樣的大環境下，傳統的通過配置檔案、資料庫等方式已經越來越無法滿足開發人員對配置管理的需求。

Apollo配置中心應運而生！

1.2 Apollo簡介

Apollo（阿波羅）是攜程架構部門研發的開源配置管理中心，能夠集中化管理應用不同環境、不同叢集的配置，配置修改後能夠實時推送到應用端，并且具備規範的權限、流程治理等特性。

Apollo支援4個次元管理Key-Value格式的配置：

• application (應用)
• environment (環境)
• cluster (叢集)
• namespace (命名空間)

二、Apollo的優勢

• 統一管理不同環境、不同叢集的配置
  • Apollo提供了一個統一界面集中式管理不同環境（environment）、不同叢集（cluster）、不同命名空間（namespace）的配置。
  • 同一份代碼部署在不同的叢集，可以有不同的配置，比如zookeeper的位址等
  • 通過命名空間（namespace）可以很友善地支援多個不同應用共享同一份配置，同時還允許應用對共享的配置進行覆寫
• 配置修改實時生效（熱釋出）
  • 使用者在Apollo修改完配置并釋出後，用戶端能實時（1秒）接收到最新的配置，并通知到應用程式
• 版本釋出管理
  • 所有的配置釋出都有版本概念，進而可以友善地支援配置的復原
• 灰階釋出
  • 支援配置的灰階釋出，比如點了釋出後，隻對部分應用執行個體生效，等觀察一段時間沒問題後再推給所有應用執行個體
• 權限管理、釋出稽核、操作審計
  • 應用和配置的管理都有完善的權限管理機制，對配置的管理還分為了編輯和釋出兩個環節，進而減少人為的錯誤。
  • 所有的操作都有審計日志，可以友善地追蹤問題
• 用戶端配置資訊監控
  • 可以在界面上友善地看到配置在被哪些執行個體使用
• 提供Java和.Net原生用戶端
  • 提供了Java和.Net的原生用戶端，友善應用內建
  • 支援Spring Placeholder, Annotation和Spring Boot的ConfigurationProperties，友善應用使用（需要Spring 3.1.1+）
  • 同時提供了Http接口，非Java和.Net應用也可以友善地使用
• 提供開放平台API
  • Apollo自身提供了比較完善的統一配置管理界面，支援多環境、多資料中心配置管理、權限、流程治理等特性。不過Apollo出于通用性考慮，不會對配置的修改做過多限制，隻要符合基本的格式就能儲存，不會針對不同的配置值進行針對性的校驗，如資料庫使用者名、密碼，Redis服務位址等
  • 對于這類應用配置，Apollo支援應用方通過開放平台API在Apollo進行配置的修改和釋出，并且具備完善的授權和權限控制
• 部署簡單
  • 配置中心作為基礎服務，可用性要求非常高，這就要求Apollo對外部依賴盡可能地少
  • 目前唯一的外部依賴是MySQL，是以部署非常簡單，隻要安裝好Java和MySQL就可以讓Apollo跑起來
  • Apollo還提供了打包腳本，一鍵就可以生成所有需要的安裝包，并且支援自定義運作時參數

三、Apollo at a glance

3.1 基礎模型

如下即是Apollo的基礎模型：

1. 使用者在配置中心對配置進行修改并釋出
2. 配置中心通知Apollo用戶端有配置更新
3. Apollo用戶端從配置中心拉取最新的配置、更新本地配置并通知到應用

3.2 總體設計

上圖簡要描述了Apollo的總體設計，我們可以從下往上看：

• Config Service提供配置的讀取、推送等功能，服務對象是Apollo用戶端
• Admin Service提供配置的修改、釋出等功能，服務對象是Apollo Portal（管理界面）
• 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程序中

3.3用戶端設計

上圖簡要描述了Apollo用戶端的實作原理：

1. 用戶端和服務端保持了一個長連接配接，進而能第一時間獲得配置更新的推送。
2. 用戶端還會定時從Apollo配置中心服務端拉取應用的最新配置。
   • 這是一個fallback機制，為了防止推送機制失效導緻配置不更新
   • 用戶端定時拉取會上報本地版本，是以一般情況下，對于定時拉取的操作，服務端都會傳回304 - Not Modified
   • 定時頻率預設為每5分鐘拉取一次，用戶端也可以通過在運作時指定System Property: 

     apollo.refreshInterval

     來覆寫，機關為分鐘。
3. 用戶端從Apollo配置中心服務端擷取到應用的最新配置後，會儲存在記憶體中
4. 用戶端會把從服務端擷取到的配置在本地檔案系統緩存一份
   • 在遇到服務不可用，或網絡不通的時候，依然能從本地恢複配置
5. 應用程式從Apollo用戶端擷取最新的配置、訂閱配置更新通知

轉載