作者:李重,單位:中國移動智慧家庭運營中心
隨著程序功能的日益復雜,程序的配置日益增多。各種功能的開關(guān)、參數(shù)的配置、服務(wù)器的地址等,對程序的配置提出了更高的要求,比如,配置修改后實時生效,灰度發(fā)布,分環(huán)境、分集群管理配置,完善的權(quán)限、審核機制等。SpringBoot項目大多使用@Value注解或者@ConfigurationProperties注解讀取配置信息,線上項目經(jīng)常需要對某些配置進行調(diào)整,如果每次都需要修改配置文件再重新發(fā)布服務(wù),難免會導致服務(wù)中斷,尤其是在分布式系統(tǒng)中多個服務(wù)節(jié)點都需要修改配置文件的場景,基于此配置中心應(yīng)運而生。
為什么需要配置中心 ●
- 配置實時生效
傳統(tǒng)的靜態(tài)配置方式要想修改某個配置,只能修改之后重新發(fā)布應(yīng)用,要實現(xiàn)動態(tài)性,可以選擇使用數(shù)據(jù)庫,通過定時輪詢訪問數(shù)據(jù)庫來感知配置的變化。輪詢頻率低感知配置變化的延時就長,輪詢頻率高,感知配置的變化延時就短,但比較損耗性能,需要在實時性和性能之間做折中。配置中心專門針對這個業(yè)務(wù)場景,兼顧實時性和一致性來管理動態(tài)配置。
- 配置管理流程
配置的權(quán)限管理、灰度發(fā)布、版本管理、格式校驗和安全配置等一系列配置管理相關(guān)的特性也是配置中心不可或缺的一部分。
什么是Apollo?●
Apollo(阿波羅)是一款可靠的分布式配置管理中心,誕生于攜程框架研發(fā)部,能夠集中化管理應(yīng)用不同環(huán)境、不同集群的配置,配置修改后能夠?qū)崟r推送到應(yīng)用端,并且具備規(guī)范的權(quán)限、流程治理等特性,適用于微服務(wù)配置管理場景。
功能介紹?●
? 統(tǒng)一管理不同環(huán)境、不同集群的配置
Apollo提供了一個統(tǒng)一界面集中式管理不同環(huán)境(environment)、不同集群(cluster)、不同命名空間(namespace)的配置。
同一份代碼部署在不同的集群,可以有不同的配置,比如zk的地址等。
通過命名空間(namespace)可以很方便的支持多個不同應(yīng)用共享同一份配置,同時還允許應(yīng)用對共享的配置進行覆蓋。
配置界面支持多語言(中文,English)。
? 配置修改實時生效(熱發(fā)布)
用戶在Apollo修改完配置并發(fā)布后,客戶端能實時(1秒)接收到最新的配置,并通知到應(yīng)用程序。
? 版本發(fā)布管理
所有的配置發(fā)布都有版本概念,從而可以方便的支持配置的回滾。
? 灰度發(fā)布
支持配置的灰度發(fā)布,比如點了發(fā)布后,只對部分應(yīng)用實例生效,等觀察一段時間沒問題后再推給所有應(yīng)用實例。
? 權(quán)限管理、發(fā)布審核、操作審計
應(yīng)用和配置的管理都有完善的權(quán)限管理機制,對配置的管理還分為了編輯和發(fā)布兩個環(huán)節(jié),從而減少人為的錯誤。
所有的操作都有審計日志,可以方便的追蹤問題。
? 客戶端配置信息監(jiān)控
可以方便的看到配置在被哪些實例使用。
? 提供Java和.Net原生客戶端
提供了Java和.Net的原生客戶端,方便應(yīng)用集成。
支持Spring Placeholder,Annotation和Spring Boot的ConfigurationProperties,方便應(yīng)用使用(需要Spring 3.1.1+)。
同時提供了Http接口,非Java和.Net應(yīng)用也可以方便的使用。
? 提供開放平臺API
Apollo自身提供了比較完善的統(tǒng)一配置管理界面,支持多環(huán)境、多數(shù)據(jù)中心配置管理、權(quán)限、流程治理等特性。
不過Apollo出于通用性考慮,對配置的修改不會做過多限制,只要符合基本的格式就能夠保存。
在我們的調(diào)研中發(fā)現(xiàn),對于有些使用方,它們的配置可能會有比較復雜的格式,如xml, json,需要對格式做校驗。
還有一些使用方如DAL,不僅有特定的格式,而且對輸入的值也需要進行校驗后方可保存,如檢查數(shù)據(jù)庫、用戶名和密碼是否匹配。
對于這類應(yīng)用,Apollo支持應(yīng)用方通過開放接口在Apollo進行配置的修改和發(fā)布,并且具備完善的授權(quán)和權(quán)限控制。
? 部署簡單
配置中心作為基礎(chǔ)服務(wù),可用性要求非常高,這就要求Apollo對外部依賴盡可能地少。
目前唯一的外部依賴是MySQL,所以部署非常簡單,只要安裝好Java和MySQL就可以讓Apollo跑起來。
Apollo還提供了打包腳本,一鍵就可以生成所有需要的安裝包,并且支持自定義運行時參數(shù)。
架構(gòu)設(shè)計
4.1 基礎(chǔ)模型
如下即是Apollo的基礎(chǔ)模型:
用戶在配置中心對配置進行修改并發(fā)布。
配置中心通知Apollo客戶端有配置更新。
Apollo客戶端從配置中心拉取最新的配置、更新本地配置并通知到應(yīng)用。
4.2 架構(gòu)模塊
如下即是Apollo架構(gòu)模塊的概覽:
Portal:英文意思為門戶,在架構(gòu)中充當?shù)慕巧珵楣芾矶?,用戶通過該模塊對配置進行修改。
PortalDB:存儲一些環(huán)境變量、配置環(huán)境等信息的數(shù)據(jù)庫。注意,該庫不存儲配置信息。
Admin Service:負責接收Portal發(fā)送過來的配置信息,對配置信息進行修改。
ConfigDB:儲存配置信息的數(shù)據(jù)庫。
Client:配置信息使用者,通常為微服務(wù)。
Config Service:負責定期從數(shù)據(jù)庫(ConfigDB)中拉取配置信息,若有變化,推送給客服端?;蚴强蛻舳硕ㄆ诶迷摲?wù)拉取配置信息。
Eureka:注冊中心,無論Conifg Service還是Admin Service,在實際使用中都是部署在多臺服務(wù)器上的。因此,對于客戶端或者門戶管理端而言,建立兩個服務(wù)的連接都需要通過注冊中心發(fā)現(xiàn)服務(wù)地址后再連接。
Meta Service:從Eureka獲取Config Service和Admin Service的服務(wù)信息,相當于是一個Eureka Client,增設(shè)一個Meta Server的角色主要是為了封裝服務(wù)發(fā)現(xiàn)的細節(jié),對Portal和Client而言,永遠通過一個Http接口獲取Admin Service和Config Service的服務(wù)信息,而不需要關(guān)心背后實際的服務(wù)注冊和發(fā)現(xiàn)組件。
?服務(wù)端設(shè)計?●
在配置中心中,一個重要的功能就是配置發(fā)布后實時推送到客戶端。下圖即是配置發(fā)布后的實時推送設(shè)計:
1.用戶在Portal操作配置發(fā)布。
2.Portal調(diào)用Admin Service的接口操作發(fā)布。
3.Admin Service發(fā)布配置后,發(fā)送ReleaseMessage給各個Config Service。
4.Config Service收到ReleaseMessage后,通知對應(yīng)的客戶端。
客戶端設(shè)計?●
下圖描述了Apollo客戶端的實現(xiàn)原理:
1.客戶端和服務(wù)端保持了一個長連接,從而能第一時間獲得配置更新的推送(通過Http Long Polling實現(xiàn))。
2.客戶端還會定時從Apollo配置中心服務(wù)端拉取應(yīng)用的最新配置。
a.這是一個fallback機制,為了防止推送機制失效導致配置不更新。
b.客戶端定時拉取會上報本地版本,所以一般情況下,對于定時拉取的操作,服務(wù)端都會返回304 - Not Modified。
c.定時頻率默認為每5分鐘拉取一次,客戶端也可以通過在運行時指定System Property: apollo.refreshInterval來覆蓋,單位為分鐘。
3.客戶端從Apollo配置中心服務(wù)端獲取到應(yīng)用的最新配置后,會保存在內(nèi)存中。
4.客戶端會把從服務(wù)端獲取到的配置在本地文件系統(tǒng)緩存一份。
a.在遇到服務(wù)不可用,或網(wǎng)絡(luò)不通的時候,依然能從本地恢復配置。
5.應(yīng)用程序可以從Apollo客戶端獲取最新的配置、訂閱配置更新通知。
結(jié)束語?●
在“約定優(yōu)于配置,配置優(yōu)于編碼”的開發(fā)理念下,通過Apollo配置中心,程序員不需要每次更改線上配置都要重新發(fā)布服務(wù),成功實現(xiàn)了將配置與編碼解耦,為線上服務(wù)變更配置提供了解決方案。