B站配置中心架構(gòu)的演進(jìn)

作者：王宗寶&陳碧仁 2023-02-09 07:38:39

配置中心是微服務(wù)基礎(chǔ)架構(gòu)中不可或缺的核心組件，未來我們將繼續(xù)研究配置中心的應(yīng)用模式與場(chǎng)景。

?1、前言

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

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

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

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

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

2、配置中心v1（Config）

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

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

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

2.2 高可用

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

2.3 配置訂閱

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

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

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

2.5 局限性

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

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

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

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

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

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主要解決了以下幾個(gè)問題：

3.1 配置生命周期的管理和配置簡(jiǎn)化

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

3.2 配置隔離

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

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

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

3.4 提高QPS和推送延遲

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

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

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

3.6 高可用

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

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

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

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

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

這樣可以保證：

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

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

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

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

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

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

4、功能特性

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

4.1 無感知接入

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

4.2 平臺(tái)空間

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

4.3 Keyspace配置

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

4.4 配置格式校驗(yàn)

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

4.5 權(quán)限管理

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

4.6 版本控制與回滾

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

4.7 染色發(fā)布

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

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

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

4.9 模版配置

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

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

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

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

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

5、性能

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

6、展望

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