?1、前言

配置中心的誕生和項目架構(gòu)的演進(jìn)有著密切的聯(lián)系。傳統(tǒng)單體應(yīng)用存在一些潛在缺陷，如隨著規(guī)模的擴(kuò)大，部署效率降低，團(tuán)隊協(xié)作效率差，系統(tǒng)可靠性變差，維護(hù)困難，新功能上線周期長等，所以迫切需要一種新的架構(gòu)去解決這些問題，而微服務(wù)（ microservices ）架構(gòu)正是當(dāng)下一種流行的解決方案。不過，解決一個問題的同時，往往會面臨很多新的問題，所以微服務(wù)化的過程中伴隨著很多的挑戰(zhàn)，其中一個挑戰(zhàn)就是有關(guān)服務(wù)（應(yīng)用）配置的。

（1）當(dāng)系統(tǒng)從一個單體應(yīng)用，被拆分成分布式系統(tǒng)上一個個服務(wù)節(jié)點后，配置文件也必須跟著遷移（分割），這樣配置就分散了，各個服務(wù)都有自己的配置，隨著項目需求的不斷壯大發(fā)展，配置會越來越多，到最后繁瑣的配置文件會讓你越來越崩潰，稍不注意出個錯配置錯了就得修改配置重新打包部署，特別麻煩。

（2）在集群部署的情況下，如果新版本的配置會給系統(tǒng)帶來很大的影響，我們往往會選擇灰度發(fā)布，即先發(fā)布部分服務(wù)器，進(jìn)行測試，穩(wěn)定后再將配置同步到所有服務(wù)器，如果說還用傳統(tǒng)的方式，那么我們就需要將配置文件一個個的修改然后重啟服務(wù)，雖然不需要我們開發(fā)自己去做，有運(yùn)維，那也挺煩人的，運(yùn)維發(fā)布完了，我們還得檢查他改的是不是正確，費時費力。

（3）而且在系統(tǒng)不斷的迭代的過程中有些配置在多個服務(wù)之間都是相同或相近的，就會有很大的冗余。

所以在分布式、微服務(wù)這種大環(huán)境下，傳統(tǒng)的項目配置方式的弊端就慢慢的凸顯出來了，這個問題變得非常棘手，亟待一種管理配置、治理配置的解決方案。這時，配置中心就應(yīng)運(yùn)而生了。

2、配置中心v1（Config）

自2017年B站開始著手配置中心的研發(fā)工作。希望能解決配置的統(tǒng)一管理，配置的訂閱與熱更，業(yè)務(wù)的透明接入等問題。

 2.1 統(tǒng)一管理頁面

配置中心v1提供一個統(tǒng)一的配置管理后臺，對不同環(huán)境、不同應(yīng)用進(jìn)行權(quán)限隔離，實現(xiàn)操作配置方便和安全。在功能方面提供了公共配置和配置搜索等功能。

2.2 高可用

Config 在可用性上采用 Admin 廣播的形式進(jìn)行集群中各個節(jié)點的數(shù)據(jù)同步；在性能上采用 MySQL 存儲和磁盤存儲兩種存儲方式，MySQL 做持久化儲存，磁盤主要加快訪問速度。配置讀取時服務(wù)首先讀取本地磁盤數(shù)據(jù)，如果未命中，則直接讀取數(shù)據(jù)庫并緩存到內(nèi)存中。

2.3 配置訂閱

配置中心v1在配置訂閱時采用長輪詢（long polling）方式實時監(jiān)聽配置變更通知，如果沒有變更則30秒后返回304，如果有變更立即返回。具體流程如下：

2.4 業(yè)務(wù)透明

配置中心對外提供統(tǒng)一的 SDK，用戶可以直接通過 SDK 接入配置中心。同時也對外提供 SDK 的訂閱和讀取接口，用戶可以根據(jù)需求自行實現(xiàn)各個接口。

2.5 局限性

v1通過 Redis 記錄 client 請求信息，供用戶查看用戶的訂閱情況，由于有些業(yè)務(wù) client 端較多，如果出現(xiàn)大量請求將會增大返回時間；

OpenAPI 對外開放，致使很多不在管理范圍內(nèi)的 SDK 不受控，對后續(xù)接口升級帶來很大的阻力；

v1的配置采用廣播的方式發(fā)布數(shù)據(jù)，如果有節(jié)點宕機(jī)，很難保證各個節(jié)點間數(shù)據(jù)的一致性；

配置中心v1是集中式集群，不支持多活部署，沒有降級方案，可靠性低；

v1也沒有對配置進(jìn)行校驗，經(jīng)常會出現(xiàn)用戶配置格式問題，導(dǎo)致版本發(fā)布后解析報錯，業(yè)務(wù)服務(wù)無法啟動問題。

3、配置中心v2（Paladin）

在配置中心v1使用多年情況下，隨著公司的規(guī)模不斷擴(kuò)大，業(yè)務(wù)不斷擴(kuò)展，越來越多的業(yè)務(wù)形態(tài)出現(xiàn)，原來的配置中心已經(jīng)不能很好的滿足當(dāng)前的業(yè)務(wù)需求，且配置中心v1版本也存在一定的局限性，所以配置中心v2便應(yīng)運(yùn)而生。

v2主要解決了以下幾個問題：

 3.1 配置生命周期的管理和配置簡化

Config將配置與版本獨立管理，變更發(fā)布和管理難度大，配置的生命周期很難管理，且新用戶學(xué)習(xí)成本高。Paladin 將配置直接綁定到分組中，配置不在擁有獨立的版本。配置的變更只有在發(fā)布后才會有變更記錄，其版本的迭代和回滾以分組維度進(jìn)行，不在分組版本中的配置即生命周期終止。同時也極大的簡化了配置變更和發(fā)布的流程，降低了用戶的使用成本。

3.2 配置隔離

在 Config 中，配置的隔離不明顯，很容易因為變更一個區(qū)域的配置導(dǎo)致所有區(qū)域的配置全部改變。在 Paladin 中配置隔離分為租戶（Tenant）隔離、命名空間（Namespace）隔離和分組（Group）隔離。用戶可以根據(jù)自己業(yè)務(wù)為維度做租戶進(jìn)行配置的隔離，如：直播業(yè)務(wù)，電商業(yè)務(wù)，游戲業(yè)務(wù)等等均可以作為獨立的租戶。命名空間的隔離是在租戶隔離的基礎(chǔ)上業(yè)務(wù)根據(jù)不同環(huán)境，區(qū)域和功能做第二級別隔離，用戶只需保證同租戶下命名空間全局唯一即可保證配置隔離，如：電商業(yè)務(wù)：測試環(huán)境-上海區(qū)域-支付功能。分組隔離是在租戶和命名空間基礎(chǔ)上做的第三級隔離，用戶可以根據(jù)自己的需求使用不同的分組，分組之間的自定義配置是相互獨立相互隔離的，不會因為改動一個配置而導(dǎo)致其他分組配置的變化。如下圖，Tenant為默認(rèn)public，Namespace為Env，Zone和App的組合，Group即為分組；業(yè)務(wù)可以據(jù)此做不同隔離。

3.3 增量發(fā)布與讀取

對于大多數(shù)情況下應(yīng)用的配置變更都是部分文件的變更，以及大文件變更和多客戶端訂閱，如果全量推送會占用大量的帶寬。Paladin 中采用了版本信息與配置信息獨立存儲的方式進(jìn)行，版本信息 Message 中保存該版本的所有配置文件信息列表，其中配置文件信息包括配置的ID，變更狀態(tài)，配置內(nèi)容的校驗信息（Checksum）以及配置信息的存儲Key（KeyLink）。配置發(fā)布時 Portal 將變更的配置與最近一次發(fā)布生效的配置 merge，做到增量發(fā)布。SDK 可以根據(jù)各個配置文件的變更狀態(tài)信息或者根據(jù)本地緩存對比最新的 Checksum 判斷配置是否需要更新，做到讀增量。

 3.4 提高QPS和推送延遲 

Paladin 采用緩存的方式提高QPS和推送延遲。如下圖，緩存層分為兩個部分，一部分為存儲配置內(nèi)容的 LRU 緩存，主要是用來加速配置的讀取。另一部是通知的緩存，為了提高通知性能，Paladin 不在使用 Redis 做推送緩存，而是采用的是 HashMap 的形式做緩存，將各個 Namespace 下的配置存儲到同一個 Key 下，如果更新將會通知該租戶和命名空間下的所有分組，服務(wù)根據(jù)訂閱的 Labels 判斷是否通知 Client，這樣極大的提高了通知的效率和擴(kuò)展性。

3.5 同集群中各個節(jié)點數(shù)據(jù)一致性

Paladin 不在像v1一樣使用廣播的形式進(jìn)行數(shù)據(jù)同步，而是采用Raft協(xié)議[1,2]保證集群中各節(jié)點數(shù)據(jù)的一致性和集群的高可用行。保證一半以上節(jié)點正常情況下數(shù)據(jù)讀寫正常。如下圖復(fù)制狀態(tài)機(jī)體系結(jié)構(gòu)

3.6 高可用

為了實現(xiàn)多活部署，Paladin 在模塊設(shè)計方面：

（1）將基礎(chǔ)數(shù)據(jù)層（Node）獨立成服，并將其與數(shù)據(jù)庫以及其他基礎(chǔ)組建解耦，全量保存所有用戶配置（一定的歷史版本），對外僅提供 Clients 的配置獲取和變更監(jiān)聽。

（2）將 Portal 定位為業(yè)務(wù)邏輯層，保存有配置的歷史數(shù)據(jù)，用戶信息，權(quán)限等。同時也統(tǒng)一對接公司內(nèi)部的其他三方系統(tǒng)，提供了配置管理需要的所有元信息；

（3）Admin 組件僅封裝核心配置的修改、發(fā)布等接口以及權(quán)限管理的支持，提供了統(tǒng)一對外的 OpenAPIs。

數(shù)據(jù)同步方面：Paladin 采用單數(shù)據(jù)庫中心，多集群部署的方案。持久化數(shù)據(jù)保存在數(shù)據(jù)庫中，在配置發(fā)布時 Portal 將同步發(fā)布數(shù)據(jù)到各個Node集群中，保證各個集群數(shù)據(jù)同步。通過 anycast 保證各個機(jī)房的服務(wù)就近讀取該機(jī)房的配置中心配置。在某機(jī)房配置中心宕機(jī)后可以切換到其他機(jī)房讀取相應(yīng)的配置，保證容災(zāi)降級。

這樣可以保證：

（1）如果 Admin 故障，前端只需連接到其他的 Admin 服務(wù)即可保證業(yè)務(wù)繼續(xù)。

（2）如果 Portal 故障，Admin 可以重新連接其他的 Portal 服務(wù)也可以對外服務(wù)。

（3）如果某臺 Node 故障，每個節(jié)點都有完整的配置副本，客戶端重新連接到該區(qū)域其他節(jié)點即可。

（4）如果某個 Node 集群故障，服務(wù)將會自動降級到其他的配置中心集群讀取配置。

3.7 客戶端訂閱連接復(fù)用

在新的業(yè)務(wù)使用中，會遇到用戶單個服務(wù)監(jiān)聽多個分組或者多個應(yīng)用的情況。所以 SDK 支持連接復(fù)用有助于簡化用戶操作。同時為了避免像v1一樣出現(xiàn) SDK 不可控的情況，Paladin 團(tuán)隊將維護(hù)所有語言的 SDK，對于不支持的語言 Paladin 提供物理機(jī)的 Agent 和 K8s的 Sidecar 等方式將配置寫入服務(wù)自定義目錄下。這樣可以有效的控制 SDK 的版本以及后續(xù) Paladin 的迭代升級。

4、功能特性

在借鑒 Config 的反饋之后，Paladin 提供更多的功能和特性以滿足新的業(yè)務(wù)需求，包括：

4.1 無感知接入

Paladin 提供了應(yīng)用配置，這也是配置中心針對B站業(yè)務(wù)形態(tài)做的無感知接入。應(yīng)用在滿足相應(yīng)條件的情況下，業(yè)務(wù)可以在 PaaS 平臺直接創(chuàng)建和部署自己的業(yè)務(wù)，無須關(guān)心配置中心的存在，方便業(yè)務(wù)的使用。Paladin 是怎么做到的？配置中心的應(yīng)用配置規(guī)定了一套使用標(biāo)準(zhǔn)，而 PaaS 平臺按照該標(biāo)準(zhǔn)將相應(yīng)的應(yīng)用參數(shù)直接注入應(yīng)用容器的環(huán)境變量中，業(yè)務(wù)在使用相應(yīng)的默認(rèn)配置參數(shù)時即無須關(guān)心配置中心和 PaaS 的聯(lián)動做到開箱即使用。

4.2 平臺空間

Paladin 支持平臺空間能力，允許不同平臺利用配置中心高可用、高容災(zāi)能力以及穩(wěn)定的配置下發(fā)通道，構(gòu)建相應(yīng)的平臺空間。平臺空間不能直接被普通業(yè)務(wù)直接感知，以一種類似于可擴(kuò)展插件的方式提供。現(xiàn)在 B 站新一代的 ABTest 平臺以及服務(wù)治理平臺均已接入。我們以 ABTest 平臺為例，業(yè)務(wù)可以根據(jù)自己的產(chǎn)品試驗需求，在 ABTest 平臺配置 A/B 測試配置，并在該平臺進(jìn)行配置發(fā)布，業(yè)務(wù)即可在其 ABTest 的平臺空間獲取到 A/B 配置，可以有效的降低業(yè)務(wù)對不同平臺的感知和接入復(fù)雜度。

4.3 Keyspace配置

配置中心針對中間件如網(wǎng)關(guān)等，會涉及到各式各樣的應(yīng)用，如果每一個應(yīng)用在使用網(wǎng)關(guān)等中間件時都需要配置或者針對相應(yīng)的SDK做大量的配置，將會極大的增加了業(yè)務(wù)的接入復(fù)雜度，同時如果中間件升級也需要所有接入業(yè)務(wù)做相應(yīng)的大的變更，增大的非必須的成本。Paladin 針對該問題推出了 Keyspace 配置。該配置不在涉及到應(yīng)用問題，可以集成到中間件的SDK中，業(yè)務(wù)應(yīng)用只需引用相應(yīng)的SDK既可以接入。同時中間件也可以根據(jù)不同需求或者功能對指定的配置做變更，作用與指定的業(yè)務(wù)。這將極大的降低接入和迭代的困難。

4.4 配置格式校驗

Paladin支持如xml，toml，yaml，json等10余種格式極其校驗。配置解析時如果配置格式錯誤將會導(dǎo)致客戶端解析失敗，所以配置中心會配置進(jìn)行格式校驗，可以有效的防止因人為操作導(dǎo)致的配置問題。

 4.5 權(quán)限管理

配置的變更是會直接影響應(yīng)用服務(wù)，對于重要的服務(wù)因配置的變更可能會帶來不可估量的后果。Paladin 在權(quán)限管理方面支持用戶權(quán)限管理，OpenAPI 權(quán)限管理，同時還支持變更通知與發(fā)布審核通知。

4.6 版本控制與回滾

當(dāng)用戶需要對配置進(jìn)行復(fù)盤時可以通過版本歷史和版本對比查看各個歷史上各個版本的配置，并能通過對比功能查看各個版本直接的差異。如果配置變更未達(dá)到預(yù)期也可以通過回滾操作將配置回滾到指定版本。

4.7 染色發(fā)布

Paladin 提供染色發(fā)布的能力，當(dāng)配置變更影響較大時，用戶可以通過染色發(fā)布在部分實例上發(fā)布最新配置測試是否符合預(yù)期。如果符合則全量所有實例，如果不符合則可以直接取消染色回歸到之前的配置。配置中心的染色發(fā)布和公司服務(wù)治理平臺進(jìn)行了完全打通，支持了相關(guān)多泳道能力的建設(shè)。如配置中心和 PaaS 平臺的聯(lián)動，做到發(fā)布染色服務(wù)讀取染色配置等一整套流程。

4.8 增量發(fā)布與讀取

Paladin 提供對配置的增量讀，一個配置版本的可能含有多個未變化配置，客戶端只需要加載變化的配置。

 4.9 模版配置

Paladin 還支持模板配置，對于中間件或者其他公共服務(wù)的 SDK 需要的配置格式是固定的，絕大部分的Value也是固定的，這個時候中間件可以創(chuàng)建相應(yīng)的模板，其他使用該中間件應(yīng)用只需引用該模板從而可以降低因各個用戶的理解不同導(dǎo)致的配置問題。

4.10 復(fù)制與導(dǎo)入

Paladin 對不同區(qū)域的之間的配置可以使用導(dǎo)入或者復(fù)制功能直接操作，可以有效防止因人為操作問題導(dǎo)致的配置出錯。

4.11 命令行運(yùn)維工具

為了更好的提供運(yùn)維服務(wù)，Paladin 可以在僅有 Node 組件的情況下運(yùn)維操作，即有助于運(yùn)維，也可以在 Admin 和 Portal 均不能有效提供服務(wù)的情況下做緊急操作。

5、性能

作為基礎(chǔ)服務(wù)，Paladin 的性能也是考察服務(wù)的關(guān)鍵點。配置中心本身是一個多讀的服務(wù)，在服務(wù)器48核2.8GHZ，單節(jié)點30萬條配置的情況下，可以同時連接6.5萬個客戶端，平均推送耗時在40毫秒以下。在同樣服務(wù)器和配置的前提下，有一萬個客戶端同時監(jiān)聽一個配置文件的變更，所需的推送時間也在600毫秒以內(nèi)。

6、展望

配置中心是微服務(wù)基礎(chǔ)架構(gòu)中不可或缺的核心組件，未來我們將繼續(xù)研究配置中心的應(yīng)用模式與場景。Paladin 在功能上基本覆蓋了配置的大部分使用方式，后續(xù)我們將進(jìn)一步優(yōu)化用戶的使用體驗，抽象出 feature/vars 等場景化能力，并對大模型的數(shù)據(jù)的分發(fā)性能進(jìn)行進(jìn)一步的優(yōu)化，以及結(jié)合公司的容器平臺研究適配 K8s 替代相應(yīng)的 ETCD 提高相應(yīng)的性能方面做努力。現(xiàn)代微服務(wù)架構(gòu)和云原生環(huán)境，對應(yīng)用配置管理提出了更高的要求。配置驅(qū)動資源正在成為云計算的一個重要技術(shù)趨勢，云計算相關(guān)的所有資源都可以通過配置去驅(qū)動[3]，未來也將研究如何在云服務(wù)平臺上與其他服務(wù)整合。

參考文獻(xiàn)

[1]https://github.com/hashicorp/raft

[2]https://pages.cs.wisc.edu/~remzi/Classes/739/Spring2004/Papers/raft.pdf

[3]https://aws.amazon.com/cn/blogs/china/technical-selection-and-landing-practice-for-building-a-cloud-native-configuration-center

本期作者

王宗寶

嗶哩嗶哩資深開發(fā)工程師

陳碧仁

嗶哩嗶哩資深開發(fā)工程師