來源B站技術團隊
配置中心的誕生和項目架構的演進有着密切的聯系。傳統單體應用存在一些潛在缺陷，如随着規模的擴大，部署效率降低，團隊協作效率差，系統可靠性變差，維護困難，新功能上線周期長等，是以迫切需要一種新的架構去解決這些問題，而微服務（ microservices ）架構正是當下一種流行的解決方案。不過，解決一個問題的同時，往往會面臨很多新的問題，是以微服務化的過程中伴随着很多的挑戰，其中一個挑戰就是有關服務（應用）配置的。
（1）當系統從一個單體應用，被拆分成分布式系統上一個個服務節點後，配置檔案也必須跟着遷移（分割），這樣配置就分散了，各個服務都有自己的配置，随着項目需求的不斷壯大發展，配置會越來越多，到最後繁瑣的配置檔案會讓你越來越崩潰，稍不注意出個錯配置錯了就得修改配置重新打包部署，特别麻煩。
（2）在叢集部署的情況下，如果新版本的配置會給系統帶來很大的影響，我們往往會選擇灰階釋出，即先釋出部分伺服器，進行測試，穩定後再将配置同步到所有伺服器，如果說還用傳統的方式，那麼我們就需要将配置檔案一個個的修改然後重新開機服務，雖然不需要我們開發自己去做，有運維，那也挺煩人的，運維釋出完了，我們還得檢查他改的是不是正确，費時費力。
（3）而且在系統不斷的疊代的過程中有些配置在多個服務之間都是相同或相近的，就會有很大的備援。是以在分布式、微服務這種大環境下，傳統的項目配置方式的弊端就慢慢的凸顯出來了，這個問題變得非常棘手，亟待一種管理配置、治理配置的解決方案。這時，配置中心就應運而生了。
2、配置中心v1（Config）
自2017年B站開始着手配置中心的研發工作。希望能解決配置的統一管理，配置的訂閱與熱更，業務的透明接入等問題。
2.1 統一管理頁面
配置中心v1提供一個統一的配置管理背景，對不同環境、不同應用進行權限隔離，實作操作配置友善和安全。在功能方面提供了公共配置和配置搜尋等功能。
2.2 高可用
Config 在可用性上采用 Admin 廣播的形式進行叢集中各個節點的資料同步；在性能上采用 MySQL 存儲和磁盤存儲兩種存儲方式，MySQL 做持久化儲存，磁盤主要加快通路速度。配置讀取時服務首先讀取本地磁盤資料，如果未命中，則直接讀取資料庫并緩存到記憶體中。
2.3 配置訂閱
配置中心v1在配置訂閱時采用長輪詢（long polling）方式實時監聽配置變更通知，如果沒有變更則30秒後傳回304，如果有變更立即傳回。具體流程如下：
2.4 業務透明
配置中心對外提供統一的 SDK，使用者可以直接通過 SDK 接入配置中心。同時也對外提供 SDK 的訂閱和讀取接口，使用者可以根據需求自行實作各個接口。
2.5 局限性
- v1通過 Redis 記錄 client 請求資訊，供使用者檢視使用者的訂閱情況，由于有些業務 client 端較多，如果出現大量請求将會增大傳回時間；
- OpenAPI 對外開放，緻使很多不在管理範圍内的 SDK 不受控，對後續接口更新帶來很大的阻力；
- v1的配置采用廣播的方式釋出資料，如果有節點當機，很難保證各個節點間資料的一緻性；
- 配置中心v1是集中式叢集，不支援多活部署，沒有降級方案，可靠性低；
- v1也沒有對配置進行校驗，經常會出現使用者配置格式問題，導緻版本釋出後解析報錯，業務服務無法啟動問題。
3、配置中心v2（Paladin）
在配置中心v1使用多年情況下，随着公司的規模不斷擴大，業務不斷擴充，越來越多的業務形态出現，原來的配置中心已經不能很好的滿足目前的業務需求，且配置中心v1版本也存在一定的局限性，是以配置中心v2便應運而生。v2主要解決了以下幾個問題：
3.1 配置生命周期的管理和配置簡化
Config将配置與版本獨立管理，變更釋出和管理難度大，配置的生命周期很難管理，且新使用者學習成本高。Paladin 将配置直接綁定到分組中，配置不在擁有獨立的版本。配置的變更隻有在釋出後才會有變更記錄，其版本的疊代和復原以分組次元進行，不在分組版本中的配置即生命周期終止。同時也極大的簡化了配置變更和釋出的流程，降低了使用者的使用成本。
3.2 配置隔離
在 Config 中，配置的隔離不明顯，很容易因為變更一個區域的配置導緻所有區域的配置全部改變。在 Paladin 中配置隔離分為租戶（Tenant）隔離、命名空間（Namespace）隔離和分組（Group）隔離。使用者可以根據自己業務為次元做租戶進行配置的隔離，如：直播業務，電商業務，遊戲業務等等均可以作為獨立的租戶。命名空間的隔離是在租戶隔離的基礎上業務根據不同環境，區域和功能做第二級别隔離，使用者隻需保證同租戶下命名空間全局唯一即可保證配置隔離，如：電商業務：測試環境-上海區域-支付功能。分組隔離是在租戶和命名空間基礎上做的第三級隔離，使用者可以根據自己的需求使用不同的分組，分組之間的自定義配置是互相獨立互相隔離的，不會因為改動一個配置而導緻其他分組配置的變化。如下圖，Tenant為預設public，Namespace為Env，Zone和App的組合，Group即為分組；業務可以據此做不同隔離。
3.3 增量釋出與讀取
對于大多數情況下應用的配置變更都是部分檔案的變更，以及大檔案變更和多用戶端訂閱，如果全量推送會占用大量的帶寬。Paladin 中采用了版本資訊與配置資訊獨立存儲的方式進行，版本資訊 Message 中儲存該版本的所有配置檔案資訊清單，其中配置檔案資訊包括配置的ID，變更狀态，配置内容的校驗資訊（Checksum）以及配置資訊的存儲Key（KeyLink）。配置釋出時 Portal 将變更的配置與最近一次釋出生效的配置 merge，做到增量釋出。SDK 可以根據各個配置檔案的變更狀态資訊或者根據本地緩存對比最新的 Checksum 判斷配置是否需要更新，做到讀增量。
3.4 提高QPS和推送延遲
Paladin 采用緩存的方式提高QPS和推送延遲。如下圖，緩存層分為兩個部分，一部分為存儲配置内容的 LRU 緩存，主要是用來加速配置的讀取。另一部是通知的緩存，為了提高通知性能，Paladin 不在使用 Redis 做推送緩存，而是采用的是 HashMap 的形式做緩存，将各個 Namespace 下的配置存儲到同一個 Key 下，如果更新将會通知該租戶和命名空間下的所有分組，服務根據訂閱的 Labels 判斷是否通知 Client，這樣極大的提高了通知的效率和擴充性。
3.5 同叢集中各個節點資料一緻性
Paladin 不在像v1一樣使用廣播的形式進行資料同步，而是采用Raft協定[1,2]保證叢集中各節點資料的一緻性和叢集的高可用行。保證一半以上節點正常情況下資料讀寫正常。如下圖複制狀态機體系結構
3.6 高可用
為了實作多活部署，Paladin 在子產品設計方面：（1）将基礎資料層（Node）獨立成服，并将其與資料庫以及其他基礎組建解耦，全量儲存所有使用者配置（一定的曆史版本），對外僅提供 Clients 的配置擷取和變更監聽。（2）将 Portal 定位為業務邏輯層，儲存有配置的曆史資料，使用者資訊，權限等。同時也統一對接公司内部的其他三方系統，提供了配置管理需要的所有元資訊；（3）Admin 元件僅封裝核心配置的修改、釋出等接口以及權限管理的支援，提供了統一對外的 OpenAPIs。資料同步方面：Paladin 采用單資料庫中心，多叢集部署的方案。持久化資料儲存在資料庫中，在配置釋出時 Portal 将同步釋出資料到各個Node叢集中，保證各個叢集資料同步。通過 anycast 保證各個機房的服務就近讀取該機房的配置中心配置。在某機房配置中心當機後可以切換到其他機房讀取相應的配置，保證容災降級。這樣可以保證：（1）如果 Admin 故障，前端隻需連接配接到其他的 Admin 服務即可保證業務繼續。（2）如果 Portal 故障，Admin 可以重新連接配接其他的 Portal 服務也可以對外服務。（3）如果某台 Node 故障，每個節點都有完整的配置副本，用戶端重新連接配接到該區域其他節點即可。（4）如果某個 Node 叢集故障，服務将會自動降級到其他的配置中心叢集讀取配置。
3.7 用戶端訂閱連接配接複用
在新的業務使用中，會遇到使用者單個服務監聽多個分組或者多個應用的情況。是以 SDK 支援連接配接複用有助于簡化使用者操作。同時為了避免像v1一樣出現 SDK 不可控的情況，Paladin 團隊将維護所有語言的 SDK，對于不支援的語言 Paladin 提供實體機的 Agent 和 K8s的 Sidecar 等方式将配置寫入服務自定義目錄下。這樣可以有效的控制 SDK 的版本以及後續 Paladin 的疊代更新。
4、功能特性
在借鑒 Config 的回報之後，Paladin 提供更多的功能和特性以滿足新的業務需求，包括：
4.1 無感覺接入
Paladin 提供了應用配置，這也是配置中心針對B站業務形态做的無感覺接入。應用在滿足相應條件的情況下，業務可以在 PaaS 平台直接建立和部署自己的業務，無須關心配置中心的存在，友善業務的使用。Paladin 是怎麼做到的？配置中心的應用配置規定了一套使用标準，而 PaaS 平台按照該标準将相應的應用參數直接注入應用容器的環境變量中，業務在使用相應的預設配置參數時即無須關心配置中心和 PaaS 的關聯做到開箱即使用。
4.2 平台空間
Paladin 支援平台空間能力，允許不同平台利用配置中心高可用、高容災能力以及穩定的配置下發通道，建構相應的平台空間。平台空間不能直接被普通業務直接感覺，以一種類似于可擴充插件的方式提供。現在 B 站新一代的 ABTest 平台以及服務治理平台均已接入。我們以 ABTest 平台為例，業務可以根據自己的産品試驗需求，在 ABTest 平台配置 A/B 測試配置，并在該平台進行配置釋出，業務即可在其 ABTest 的平台空間擷取到 A/B 配置，可以有效的降低業務對不同平台的感覺和接入複雜度。
4.3 Keyspace配置
配置中心針對中間件如網關等，會涉及到各式各樣的應用，如果每一個應用在使用網關等中間件時都需要配置或者針對相應的SDK做大量的配置，将會極大的增加了業務的接入複雜度，同時如果中間件更新也需要所有接入業務做相應的大的變更，增大的非必須的成本。Paladin 針對該問題推出了 Keyspace 配置。該配置不在涉及到應用問題，可以內建到中間件的SDK中，業務應用隻需引用相應的SDK既可以接入。同時中間件也可以根據不同需求或者功能對指定的配置做變更，作用與指定的業務。這将極大的降低接入和疊代的困難。
4.4 配置格式校驗
Paladin支援如xml，toml，yaml，json等10餘種格式極其校驗。配置解析時如果配置格式錯誤将會導緻用戶端解析失敗，是以配置中心會配置進行格式校驗，可以有效的防止因人為操作導緻的配置問題。
4.5 權限管理
配置的變更是會直接影響應用服務，對于重要的服務因配置的變更可能會帶來不可估量的後果。Paladin 在權限管理方面支援使用者權限管理，OpenAPI 權限管理，同時還支援變更通知與釋出稽核通知。
4.6 版本控制與復原
當使用者需要對配置進行複盤時可以通過版本曆史和版本對比檢視各個曆史上各個版本的配置，并能通過對比功能檢視各個版本直接的差異。如果配置變更未達到預期也可以通過復原操作将配置復原到指定版本。
4.7 染色釋出
Paladin 提供染色釋出的能力，當配置變更影響較大時，使用者可以通過染色釋出在部分執行個體上釋出最新配置測試是否符合預期。如果符合則全量所有執行個體，如果不符合則可以直接取消染色回歸到之前的配置。配置中心的染色釋出和公司服務治理平台進行了完全打通，支援了相關多泳道能力的建設。如配置中心和 PaaS 平台的關聯，做到釋出染色服務讀取染色配置等一整套流程。
4.8 增量釋出與讀取
Paladin 提供對配置的增量讀，一個配置版本的可能含有多個未變化配置，用戶端隻需要加載變化的配置。
4.9 模版配置
Paladin 還支援模闆配置，對于中間件或者其他公共服務的 SDK 需要的配置格式是固定的，絕大部分的Value也是固定的，這個時候中間件可以建立相應的模闆，其他使用該中間件應用隻需引用該模闆進而可以降低因各個使用者的了解不同導緻的配置問題。
4.10 複制與導入
Paladin 對不同區域的之間的配置可以使用導入或者複制功能直接操作，可以有效防止因人為操作問題導緻的配置出錯。
4.11 指令行運維工具
為了更好的提供運維服務，Paladin 可以在僅有 Node 元件的情況下運維操作，即有助于運維，也可以在 Admin 和 Portal 均不能有效提供服務的情況下做緊急操作。
5、性能
作為基礎服務，Paladin 的性能也是考察服務的關鍵點。配置中心本身是一個多讀的服務，在伺服器48核2.8GHZ，單節點30萬條配置的情況下，可以同時連接配接6.5萬個用戶端，平均推送耗時在40毫秒以下。在同樣伺服器和配置的前提下，有一萬個用戶端同時監聽一個配置檔案的變更，所需的推送時間也在600毫秒以内。
6、展望
配置中心是微服務基礎架構中不可或缺的核心元件，未來我們将繼續研究配置中心的應用模式與場景。Paladin 在功能上基本覆寫了配置的大部分使用方式，後續我們将進一步優化使用者的使用體驗，抽象出 feature/vars 等場景化能力，并對大模型的資料的分發性能進行進一步的優化，以及結合公司的容器平台研究适配 K8s 替代相應的 ETCD 提高相應的性能方面做努力。現代微服務架構和雲原生環境，對應用配置管理提出了更高的要求。配置驅動資源正在成為雲計算的一個重要技術趨勢，雲計算相關的所有資源都可以通過配置去驅動[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