前言

一位讀者朋友跟我反饋，能不能寫一篇比較全的配置中心的文章。自己最近在面試過程中有被面試官問：如何設(shè)計一個配置中心？ 這個話題，由于自己在工作中也沒實(shí)際使用過配置中心，所以對于如何去設(shè)計是完全沒有概念的。

今天就給大家寫一篇去配置中心需要考慮的點(diǎn)，我也不是什么配置中心開源項(xiàng)目的參與者，所以寫出來的僅供大家參考。

有必要重復(fù)造輪子嗎？

當(dāng)面試官問你：如果讓你寫一個配置中心，說說你的設(shè)計思路？ 首先我們要有自己的想法，雖然是在面試過程中的問題。我們也可以反問，市面上目前有幾款很優(yōu)秀的開源的配置中心，我們可以直接拿來用，有必要去重新造輪子嗎？

如果面試官說只是考察一下你對這塊的設(shè)計和理解程度，然后你就可以接著講解你的思路了。如果面試官說我們很多框架都是自研的，任性，就是有這個需求，那你還是得接著說，躲不掉，哈哈。

如果要重新造，我們也可以基于開源的進(jìn)行改造，下面我說下如果要設(shè)計一個配置中心，它的整體思路是怎樣的，需要用到哪些技術(shù)點(diǎn)，然后開始你的表演。

配置存儲選型

首先我們來看存儲的選型，配置中心需要存儲所有的配置內(nèi)容，肯定需要進(jìn)行存儲。目前主流開源的配置中心都采用 Mysql 進(jìn)行配置的存儲，當(dāng)然你也可以用其他的，比如 MongoDB 也非常適合。

用不同的數(shù)據(jù)庫在設(shè)計表結(jié)構(gòu)的時候會有所不同，比如 Mysql 可能要 10 個表，MongoDB 簡化后可能 5 個表就夠了（Mysql 多表關(guān)聯(lián)，MongoDB 內(nèi)嵌文檔）。

Mysql 多表關(guān)聯(lián)

MongoDB 內(nèi)嵌文檔

這些表除了基本的配置內(nèi)容存儲，還有就是一些輔助的表，比如用戶信息，權(quán)限信息等。

除了底層結(jié)構(gòu)的設(shè)計，我們還需要考慮存儲的可用性。Mysql 可以做主從，分庫分表等，MongoDB 天生就是分布式的數(shù)據(jù)庫，也不存在單點(diǎn)問題，在可用性這塊都是 OK 的。

另外在設(shè)計層面，對于配置信息可以加上本地緩存，當(dāng)數(shù)據(jù)庫或者服務(wù)不可用時也能短暫提供服務(wù)能力，一般都是在 client 層面做。Apollo 和 Nacos 都會在本地緩存配置信息。

配置隔離

配置隔離在配置中心也是非常重要的一個點(diǎn)，不同的環(huán)境不同的配置信息，這個是最基礎(chǔ)的。在沒使用配置中心之前通常都是在項(xiàng)目中為每個環(huán)境維護(hù)一個配置文件，然后通過命令進(jìn)行切換需要使用的文件。

除了環(huán)境的隔離，還有一種就是訪問層面的隔離，比如命名空間，不同的空間相互是隔離的，不能相互訪問。

底層隔離的方式也有很多種，第一種是在存儲的時候增加一個字段進(jìn)行環(huán)境的區(qū)分，數(shù)據(jù)統(tǒng)一存儲在一起，但是可以區(qū)分，這種方式好處在于一套配置中心可以提供給所有環(huán)境進(jìn)行使用。

第二種是在部署層面直接就隔離了，也就是測試環(huán)境部署一套獨(dú)立的配置中心，線上也部署一套獨(dú)立的配置中心，也就不需要在存儲的時候通過字段隔離了。

第三種也是部署的時候進(jìn)行隔離，不同的點(diǎn)在于 Web 后臺管理只部署一套，配置信息對應(yīng)的服務(wù)可以按環(huán)境部署多套，每套都有自己獨(dú)立的數(shù)據(jù)庫，Apollo 就是采用這種方式。

配置推送刷新

配置在修改后能夠?qū)崟r的推送到應(yīng)用程序中進(jìn)行更新，這個是最重要的一個功能，用戶體驗(yàn)也是非常好的。在沒用配置中心之前，有用 Mysql 進(jìn)行配置存儲的，為了提高性能，減小數(shù)據(jù)庫的壓力，配置信息讀取后會放入緩存中，后臺會啟動一個定時線程去更新，比如 1 分鐘一次。

這樣帶來的問題就是配置改完后需要等待一定的時間客戶端才能更新好，一般場景都沒啥問題，對于一些特殊的場景還是需要改完立馬生效，才能盡可能避免某些業(yè)務(wù)問題帶來的損失。

對于配置修改及時更新的實(shí)現(xiàn)方式目前主要分為兩種：推和拉。

拉模式前面講過了，有時間間隔問題，就算設(shè)置的很快，比如 1 秒一次，頻率太高會導(dǎo)致服務(wù)端壓力過大。

推模式是比較好的方式，當(dāng)服務(wù)端有變動的時候?qū)⒆兏男畔⑼扑徒o客戶端，即及時又能減輕定時拉取的頻率。

推送可以采用 Spring DeferredResult 將請求掛起的模式實(shí)現(xiàn)，詳情可以參考我的這篇文章：Apollo服務(wù)端設(shè)計原理剖析

更好的方式是推拉結(jié)合，目前主流的配置中心都是采用這種方式。推保證及時性，拉用于兜底，保證最終配置一致性，推拉結(jié)合的模式可以將拉取的時間放長，降低服務(wù)端壓力。

集成 Spring

Spring 是 Java 語言開發(fā)必不可少的好朋友，使用 Spring 可以極高的提高我們的開發(fā)效率，各種框架都能非常方便的集成。

在 Spring 中最常見的兩種獲取配置值的方式是@Value 和@ConfigurationProperties，要想使用上面的方式能夠獲取到配置中心里的內(nèi)容，需要在項(xiàng)目啟動的時候從配置中心加載對應(yīng)的配置內(nèi)容，然后集成到 Spring 中。

Spring 中提供了 ConfigurableEnvironment，ConfigurableEnvironment 中又包含多個 PropertySource。PropertySource 就是 Key，Value 的配置。所以需要在應(yīng)用啟動的時候，獲取配置信息組裝成 PropertySource 交給 Spring 管理。

權(quán)限審計

無論是所有環(huán)境用一套配置中心還是每個環(huán)境都有單獨(dú)的部署，權(quán)限控制還是要的，因?yàn)椴煌男〗M負(fù)責(zé)不同的業(yè)務(wù)，肯定不能隨便去改動其他組的配置。

另一個場景就是配置能被誰改，這個一般都是負(fù)責(zé)人進(jìn)行修改，團(tuán)隊(duì)人員可以查看配置信息，這個也是很常見需要進(jìn)行控制的場景。

單純從配置的功能來講，很多人都會說為什么我要用配置中心，自己搞張表存儲一下不也行么，我認(rèn)為配置的存儲是最基本的功能，更多讓我們使用配置中的原因在于可以節(jié)省我們自己去做的成本。同時配置中心具有很全的治理方面的能力，比如權(quán)限，灰度實(shí)用的功能等。

指標(biāo)監(jiān)控

作為一款中間件，而且是被很多系統(tǒng)使用，它的一些性能指標(biāo)也是需要監(jiān)控起來的。常見的做法有下面幾種方式。

一種是配置中心自己暴露出一些指標(biāo)數(shù)據(jù)，可以讓外部監(jiān)控系統(tǒng)進(jìn)行拉取，pull 方式。像 Nacos 中就暴露了 metrics 數(shù)據(jù)，可以用 prometheus 進(jìn)行拉取并監(jiān)控，非常方便。

一種是配置中心自己埋點(diǎn)，對接一些監(jiān)控系統(tǒng)，采用 push 的方式。比如 Apollo 中就集成了 Cat 的監(jiān)控，可以將相關(guān)監(jiān)控數(shù)據(jù)投遞到 Cat 中進(jìn)行展示并告警。

還有一種方式就是提供 Tracer 相關(guān)的 SPI，可以讓使用方自行去接入不同的監(jiān)控，靈活度更高。

無論用哪種方式，我們的最終目的是一致的，都是為了能夠讓 Bug 不發(fā)生，就算有問題也能監(jiān)控到，不然就慘了，哈哈。

開放 API/多語言 SDK

目前幾款比較活躍的配置中心都是 Java 開發(fā)的，也提供了對應(yīng)的 Java SDK。如果你自己用其他語言開發(fā)一套配置中心，也是一樣的需要有對應(yīng)語言的 SDK。如果公司是多語言技術(shù)棧，那么可以為每種語言都開發(fā)一個 SDK 進(jìn)行接入。

如果作為開源的項(xiàng)目，也不能規(guī)定別人使用什么語言，如果不想開發(fā)多語言 SDK 的話，可以提供一套開放 API 讓使用者自己去封裝 SDK 或者直接在項(xiàng)目中進(jìn)行接入。