?1、前言

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

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

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

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

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

2、配置中心v1（Config）

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

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

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

2.2 高可用

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

2.3 配置訂閱

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

2.4 業(yè)務透明

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

2.5 局限性

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

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

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

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

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

3、配置中心v2（Paladin）

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

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

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

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

3.2 配置隔離

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

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

對于大多數(shù)情況下應用的配置變更都是部分文件的變更，以及大文件變更和多客戶端訂閱，如果全量推送會占用大量的帶寬。Paladin 中采用了版本信息與配置信息獨立存儲的方式進行，版本信息 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 下，如果更新將會通知該租戶和命名空間下的所有分組，服務根據(jù)訂閱的 Labels 判斷是否通知 Client，這樣極大的提高了通知的效率和擴展性。

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

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

3.6 高可用

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

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

（2）將 Portal 定位為業(yè)務邏輯層，保存有配置的歷史數(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 保證各個機房的服務就近讀取該機房的配置中心配置。在某機房配置中心宕機后可以切換到其他機房讀取相應的配置，保證容災降級。

這樣可以保證：

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

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

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

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

3.7 客戶端訂閱連接復用

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

4、功能特性

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

4.1 無感知接入

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

4.2 平臺空間

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

4.3 Keyspace配置

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

4.4 配置格式校驗

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

 4.5 權(quán)限管理

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

4.6 版本控制與回滾

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

4.7 染色發(fā)布

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

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

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

 4.9 模版配置

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

4.10 復制與導入

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

4.11 命令行運維工具

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

5、性能

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

6、展望

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

參考文獻

[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ā)工程師