apollo配置中心初探

近在搞微服務框架的開發，需要有一個配置中心來滿足統一管理業務應用以及組件的配置，在此期間也使用了多個配置中心比如：spring cloud config，自研的配置中心，當然還有apollo。

springcloud config需要依托svn等代碼托管工具，而且沒有統一管理頁面；自研的配置中心最燃功能健全，也能夠支持動態獲取配置，但是不能夠使用多種格式的配置文件，也不支持動態更新客戶端配置。所以經過對比，apollo雖然有需要改進的地方，但是基本滿足現有階段的開發使用需求。所以選擇了apollo作為微服務框架的配置中心。

下面對apollo做個簡單的介紹，然后介紹一下apollo架構、部署方法、源碼初步解讀等。

一 apollo簡介

1.介紹

apollo是攜程的開源配置管理中心，可以從應用、環境、集群、命名空間4個維度集中的管理配置，並能夠夠實施的推送至客戶端。

2.優點：

 

• 統一管理不同環境、不同集群的配置

  • 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架構解析

1.基礎模型

 

如上圖所示，用戶在配置中心配置/修改並發布配置，然后apollo通知客戶端有配置更新，最后客戶端向apollo配置中心請求最新配置。

2.總體設計

2.1各模塊介紹

2.1.1 config Service

 

• 提供配置獲取接口
• 提供配置更新推送接口（基於Http long polling）
  • 服務端使用Spring DeferredResult實現異步化，從而大大增加長連接數量
  • 目前使用的tomcat embed默認配置是最多10000個連接（可以調整），使用了4C8G的虛擬機實測可以支撐10000個連接，所以滿足需求（一個應用實例只會發起一個長連接）。
• 接口服務對象為Apollo客戶端

2.1.2 Admin Service

 

 

• 提供配置管理接口
• 提供配置修改、發布等接口
• 接口服務對象為Portal

 

2.1.3 Meta Server

 

• Portal通過域名訪問Meta Server獲取Admin Service服務列表（IP+Port）
• Client通過域名訪問Meta Server獲取Config Service服務列表（IP+Port）
• Meta Server從Eureka獲取Config Service和Admin Service的服務信息，相當於是一個Eureka Client
• 增設一個Meta Server的角色主要是為了封裝服務發現的細節，對Portal和Client而言，永遠通過一個Http接口獲取Admin Service和Config Service的服務信息，而不需要關心背后實際的服務注冊和發現組件
• Meta Server只是一個邏輯角色，在部署時和Config Service是在一個JVM進程中的

 

2.1.4 Eureka

 

• 基於Eureka和Spring Cloud Netflix提供服務注冊和發現
• Config Service和Admin Service會向Eureka注冊服務，並保持心跳
• 為了簡單起見，目前Eureka在部署時和Config Service是在一個JVM進程中的（通過Spring Cloud Netflix）

 

2.1.5 Portal

 

• 提供Web界面供用戶管理配置
• 通過Meta Server獲取Admin Service服務列表（IP+Port），通過IP+Port訪問服務
• 在Portal側做load balance、錯誤重試

 

2.1.6 Client

 

• Apollo提供的客戶端程序，為應用提供配置獲取、實時更新等功能
• 通過Meta Server獲取Config Service服務列表（IP+Port），通過IP+Port訪問服務
• 在Client側做load balance、錯誤重試

2.2 服務端設計

 

 

上圖簡要描述了配置發布的大致過程：

1. 用戶在Portal操作配置發布
2. Portal調用Admin Service的接口操作發布
3. Admin Service發布配置后，發送ReleaseMessage給各個Config Service
4. Config Service收到ReleaseMessage后，通知對應的客戶端

2.3 客戶端設計

 

上圖簡要描述了Apollo客戶端的實現原理：

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

目前先寫到這，部署方法和源碼解讀見下一篇。