微信研發(fā)體系下的分布式配置系統(tǒng)設(shè)計(jì)概要
作者：ypaapyyang，騰訊 WXG 后臺(tái)開發(fā)工程師，個(gè)人公眾號(hào)：碼農(nóng)課代表。
本文旨在分析分布式配置系統(tǒng)的必要性、可行性，及其關(guān)鍵約束，并介紹一款基于該系列分析，在微信研發(fā)體系下的實(shí)踐嘗試。
前言
對很多的業(yè)務(wù)開發(fā)同學(xué)而言，對運(yùn)營素材的處理不是一件輕松的事，通常需要定制化的進(jìn)行數(shù)據(jù)的清理、格式的轉(zhuǎn)換、工具的開發(fā)。筆者就曾過這樣一段不愉快的回憶，為了導(dǎo)入一次性的近十種類型的配置數(shù)據(jù)，就耗去了兩天的時(shí)間。如果說這段經(jīng)歷有何價(jià)值的話，那就是促使我思考分布式配置系統(tǒng)，并且在工作中實(shí)踐，使自己避免再次陷入如此槽糕的過程中。
本文正是旨在分析分布式配置系統(tǒng)的必要性、可行性，及其關(guān)鍵約束，并介紹一款基于該系列分析，在微信研發(fā)體系下的實(shí)踐嘗試。
配置的定義
我們清楚軟件建模的本質(zhì)是對現(xiàn)實(shí)世界(人、事、物及規(guī)則)的映射，映射的產(chǎn)出物即包括編程系統(tǒng)和配置。配置為我們提供了動(dòng)態(tài)修改程序運(yùn)行時(shí)行為的能力，即常說的“系統(tǒng)運(yùn)行時(shí)飛行姿態(tài)的動(dòng)態(tài)調(diào)整”，究其根源則是“我們?nèi)祟悷o法掌控和預(yù)知一切，映射到軟件領(lǐng)域上，我們總是需要對系統(tǒng)的某些功能特性預(yù)留出一些控制的線頭，以便我們在未來需要的時(shí)候，可以人為的撥弄這些線頭從而控制系統(tǒng)的行為特征。”
因此，本文所指的配置特指內(nèi)部運(yùn)營人員產(chǎn)生的數(shù)據(jù)(廣義的系統(tǒng)運(yùn)營人員，包括產(chǎn)品、運(yùn)營、研發(fā)等)，并且作為輸入?yún)?shù)而作用于編程系統(tǒng)(包括實(shí)時(shí)系統(tǒng)、批跑程序以及數(shù)據(jù)任務(wù)等)。
歸納而言，配置通常包含如下三種：
a. 環(huán)境配置，定義了應(yīng)用程序運(yùn)行的環(huán)境相關(guān)參數(shù)，如 IP、Port 等;
b. 應(yīng)用配置，定義了應(yīng)用程序自身相關(guān)的參數(shù)或者信息安全控制等，如初始內(nèi)存分配大小、數(shù)據(jù)庫連接池大小、日志級(jí)別、賬號(hào)密碼等;(密碼、證書這類東西肯定不要放在配置系統(tǒng)中，而應(yīng)當(dāng)走統(tǒng)一加解密服務(wù))
c. 業(yè)務(wù)配置，定義了應(yīng)用程序所執(zhí)行的業(yè)務(wù)行為數(shù)據(jù)，比如最常見的功能開關(guān)，參與活動(dòng)的商戶名單等。
系統(tǒng)約束
數(shù)據(jù)模型
配置最基本的數(shù)據(jù)單元是key=value(即配置項(xiàng))，比如功能開關(guān)通常就是最簡單的類型，用 boolean 型值來影響程序執(zhí)行鏈路(不考慮灰度的情況)。然而只有 key-value 類型是不足的，比如 DB 的連接配置就包含了 ip、port、username、password 等字段，在 ini 文件的實(shí)現(xiàn)中即是不同配置項(xiàng)來組成，它們在邏輯上是屬于同一個(gè)配置對象，因此基于面向?qū)ο蟮脑O(shè)計(jì)思路，key=object才是更通用的配置模型，在物理實(shí)現(xiàn)中可以為 json 或者 xml，或者 protobuf message。
object 類型的數(shù)據(jù)即可以是平坦的，也可以是多層次(嵌套)的。在實(shí)際的業(yè)務(wù)應(yīng)用中，平坦類型的數(shù)據(jù)有其特殊性，即其通常條目較多，最典型的數(shù)據(jù)是白名單，可能多達(dá)上萬條。線下，內(nèi)部運(yùn)營人員通過excel進(jìn)行這類數(shù)據(jù)的管理，如果我們只是粗暴的將其打包成一個(gè)對象，那么過大的數(shù)據(jù)可能會(huì)導(dǎo)致系統(tǒng)效率的下降(不是配置的寫入效率下降，就是配置讀出效率下降)，因此我們會(huì)使用array of plain object來表達(dá)，即key=table類型的數(shù)據(jù)。
訪問模型
相別于產(chǎn)品用戶產(chǎn)生的數(shù)據(jù)，配置系統(tǒng)的數(shù)據(jù)流是單向的，離線系統(tǒng)與實(shí)時(shí)系統(tǒng)結(jié)合而讀寫分離(異步寫、實(shí)時(shí)讀)的。最終我們要搭建的分布式配置系統(tǒng)，它的系統(tǒng)設(shè)計(jì)，也必然是建立在這類訪問模型上的。
系統(tǒng)約束
顯然，內(nèi)部運(yùn)營人員作為生產(chǎn)者，所有的配置肯定都是文本類型的(Readable)，并且數(shù)據(jù)量少(相對于用戶、系統(tǒng)等生產(chǎn)數(shù)據(jù)而言)，對存儲(chǔ)空間需求少，更新頻次低?？梢赃@么理解，在整個(gè)配置系統(tǒng)架構(gòu)中，輸入方就如同鍵盤相對于 CPU 而言是超慢速設(shè)備，他們對系統(tǒng)的易用性、易操作性、安全性要求更高。
我們思考下用戶畫像系統(tǒng)，它部分滿足配置系統(tǒng)的訪問模型，即數(shù)據(jù)流是單向的，離線系統(tǒng)負(fù)責(zé)寫入畫像數(shù)據(jù)，而實(shí)時(shí)系統(tǒng)讀數(shù)據(jù)。但是首先它的數(shù)據(jù)生產(chǎn)者通常是離線任務(wù)，而非運(yùn)營人員;再次，它涉及到的數(shù)據(jù)量是巨大的，通常需要定制的存儲(chǔ)引擎。配置系統(tǒng)與之相比，不可同日而語。
相較而言，配置系統(tǒng)的消費(fèi)者則是高頻的讀訪問，對系統(tǒng)的吞吐量、延時(shí)、網(wǎng)絡(luò)流量、可用性、一致性、請求單調(diào)性都有更高的要求。后續(xù)我們逐一展開深入的思考。
配置系統(tǒng)的設(shè)計(jì)應(yīng)當(dāng)充分考慮到上述的數(shù)據(jù)模型、訪問模型以及系統(tǒng)約束。(比較奇怪的是，筆者在查閱相關(guān)配置系統(tǒng)實(shí)現(xiàn)時(shí)，鮮少看到有針對一致性、請求單調(diào)性的討論。這也是促使筆者撰寫本文的原因)
安全約束
正因?yàn)榕渲每梢暂p易的調(diào)整系統(tǒng)運(yùn)行期行為，因此配置的安全性至關(guān)重要。實(shí)現(xiàn)安全的必要條件是：讓正確的人，以正確的方式，在正確的時(shí)機(jī)，發(fā)布正確的配置。因此，配置系統(tǒng)不但要支持灰度發(fā)布的基本能力，還要在權(quán)限管理、權(quán)限粒度管理、配置變更審核、審計(jì)、歷史版本等方面都要加強(qiáng)建設(shè)。
系統(tǒng)的演進(jìn)
單機(jī)配置文件
在單機(jī)系統(tǒng)時(shí)代，我們基本上都是使用配置文件來存儲(chǔ)配置數(shù)據(jù)(比如 ini 文件、xml 文件等)。配置文件易于理解、便于實(shí)現(xiàn)、可用性高，因此進(jìn)入分布式集群時(shí)代，仍在廣泛使用。
然而配置文件存在諸多的缺點(diǎn)，包括：
- 易用性差，主要體現(xiàn)為表達(dá)的數(shù)據(jù)類型單一，比如 ini 只能管理配置項(xiàng)，即 key=value 類型數(shù)據(jù);而如果使用 xml 文件來管理 key=table 類型數(shù)據(jù)，那么文件內(nèi)容的初始化效率低下，容易出錯(cuò)，難以維護(hù);
- 可操作性差，配置文件基本只能由開發(fā)來進(jìn)行修改并且發(fā)布，產(chǎn)品、運(yùn)營的常規(guī)業(yè)務(wù)素材變更工作就不得不卷入開發(fā)執(zhí)行，對業(yè)務(wù)的流程效率有嚴(yán)重的影響;
- 正確性、安全性難以保障，正因?yàn)榕渲梦募囊子趯?shí)現(xiàn)，導(dǎo)致很多團(tuán)隊(duì)疏忽了運(yùn)營系統(tǒng)的建設(shè)，研發(fā)人員隨意修改、惡意修改配置文件的情況無法杜絕，細(xì)粒度的權(quán)限管理、操作的審核、審計(jì)無從談起;
- 發(fā)布效率低下，配置文件是單機(jī)部署的，在集群規(guī)模較大的情況下，配置文件的任意變更都需要經(jīng)過漫長的灰度發(fā)布過程發(fā)布到全網(wǎng)，如果配置文件是靜態(tài)加載的，還需要重啟二進(jìn)制，需要消耗研發(fā)、運(yùn)維人員較多的精力;
- 文件一致性難以保障，在發(fā)布配置變更的過程中，如果集群中出現(xiàn)宕機(jī)情況，會(huì)導(dǎo)致不同機(jī)器間的配置出現(xiàn)差異，而沒有自動(dòng)校正的能力，依賴于人員或者運(yùn)維系統(tǒng)的支持，從而導(dǎo)致業(yè)務(wù)進(jìn)入未定義的行為。
如果說易用性、可操作性、正確性、安全性可以通過搭建運(yùn)營系統(tǒng)來進(jìn)行改進(jìn)，而發(fā)布效率低下、文件一致性難以保障則是單機(jī)配置文件的致命弱點(diǎn)，究其本質(zhì)，是因?yàn)閱螜C(jī)配置文件系統(tǒng)是被動(dòng)的、離散的接受外界的變更，而沒有主動(dòng)的能力。
集中式配置文件中心
由此，出現(xiàn)了集中式的配置文件系統(tǒng)，針對性的解決了上述的問題，開發(fā)人員將配置文件存儲(chǔ)到獨(dú)立的第三方服務(wù)(典型的由 ZooKeeper 進(jìn)行管理，也有部分團(tuán)隊(duì)自行實(shí)現(xiàn)微服務(wù)管理)，然后由 agent 周期性的將配置拉取到本地進(jìn)行緩存(拉)，或者通過事件的訂閱通知能力來將變更發(fā)布到相應(yīng)集群(推)。
集中式配置文件系統(tǒng)針對性的解決了發(fā)布變更效率問題以及配置文件一致性保障問題。然而在筆者所知的應(yīng)用案例中，仍然存在如下的問題亟需解決：
- 一致性粒度粗，集中式配置文件只能確保分布式集群達(dá)到最終一致(時(shí)間取決于拉、推的頻率及速率)，卻無法保證任一時(shí)刻，對任一配置，所有進(jìn)程、線程、協(xié)程看到相同的數(shù)據(jù)，而這通常會(huì)導(dǎo)致出現(xiàn)不預(yù)期的業(yè)務(wù)失敗;
- 無法保證請求單調(diào)性，在一次業(yè)務(wù)請求中，我們希望用戶看到的配置內(nèi)容是靜態(tài)的，如果中間發(fā)生變更，可能帶來業(yè)務(wù)失敗，嚴(yán)重的導(dǎo)致用戶數(shù)據(jù)狀態(tài)錯(cuò)亂;而基于集中式配置文件系統(tǒng)的配置通常是動(dòng)態(tài)加載的，配置的變更可能隨時(shí)的反應(yīng)到實(shí)時(shí)系統(tǒng)中，導(dǎo)致一次業(yè)務(wù)請求先后看到不同的數(shù)據(jù)狀態(tài);
- 安全性仍無法徹底保障，雖然集中式配置文件的修改可以控制權(quán)限，但是在消費(fèi)者機(jī)器上，開發(fā)者仍然可以手動(dòng)的修改本地配置文件 cache 來影響程序的運(yùn)行行為;
- 無法支持灰度能力，配置文件變更的下發(fā)是全量的，如果要支持灰度發(fā)布的能力，就需要卷入業(yè)務(wù)方自行實(shí)現(xiàn);
配置文件系統(tǒng)，無論是單機(jī)配置文件，還是集中式配置文件，存在的問題，歸根結(jié)底，是由于配置文件這個(gè)載體以及集中式配置文件系統(tǒng)的管道定位決定的，從而導(dǎo)致進(jìn)行精細(xì)化管理的成本高：
- 配置文件的可視可讀能力對生產(chǎn)者而言是重要的，但對消費(fèi)者卻是無關(guān)緊要的，因此全鏈路都由配置文件作為載體反而可能導(dǎo)致加載效率低下(比如應(yīng)對千萬級(jí)黑白名單，或者業(yè)務(wù)方實(shí)時(shí)請求鏈路動(dòng)態(tài)加載);
- 配置文件難以安全、便利管理元信息，為了實(shí)現(xiàn)一致性、單調(diào)性、安全性，配置需要一些元數(shù)據(jù)信息管理(下文展開詳述)，但是配置文件系統(tǒng)沒有這種能力，除非業(yè)務(wù)方使用高成本自行實(shí)現(xiàn);
- 配置文件的數(shù)目與配置的數(shù)量息息相關(guān)，隨著時(shí)間的發(fā)展，配置文件數(shù)目膨脹，帶來新的運(yùn)營問題;
- 集中式配置文件系統(tǒng)通常只把自己定位成管道(據(jù)筆者所知)，即不理解也不維護(hù)配置文件的內(nèi)容，agent 功能單一，業(yè)務(wù)消費(fèi)方不與系統(tǒng)直接交互，而是只看到配置文件，雖然松耦合可以提高可用性，但也讓業(yè)務(wù)方仍然投入不少的開發(fā)成本來處理配置文件。
配置文件只是配置的物理載體，上述缺點(diǎn)并非無法克服，只是在基于配置文件的配置系統(tǒng)下，實(shí)現(xiàn)上述能力的成本高，需要更多的使用約束，以及外圍配套。
數(shù)據(jù)庫配置存儲(chǔ)
對結(jié)構(gòu)復(fù)雜、類型較多的配置，業(yè)務(wù)研發(fā)同學(xué)通常也不會(huì)直接使用配置文件來承載，而是使用數(shù)據(jù)庫(關(guān)系型或非關(guān)系型)庫表來存儲(chǔ)配置，然后再編寫工具進(jìn)行數(shù)據(jù)的導(dǎo)入。這種存儲(chǔ)方案克服了配置文件的部分問題，對配置有更精細(xì)化的管理。但是也存在明顯的不足，即高度的定制化，不可復(fù)用，重復(fù)開發(fā)高。因此，我們需要對此進(jìn)行完善，將配置的存儲(chǔ)、讀、寫、管理等過程提煉共性，通用化、平臺(tái)化。
方案思考
物理模型
既然配置文件難以精細(xì)化管理，且具備易侵入的物理實(shí)體(本地文件)，我們需要新的數(shù)據(jù)結(jié)構(gòu)來承載配置。前文我們討論過，配置有兩種數(shù)據(jù)模型，分別是key=object以及key=table。對使用者而言，配置必須是可視、可讀、易管理的。為了達(dá)成這目的，我們只需在內(nèi)部運(yùn)營人員與配置系統(tǒng)核心之間搭一套設(shè)計(jì)良好的運(yùn)營系統(tǒng)即可。那么在后端呢?對消費(fèi)者而言，最注重傳輸、計(jì)算的效率，同時(shí)為了與微服務(wù)框架的對齊，protobuf message無疑是最佳的形式。
然而 protobuf 無法自解釋，在沒有 message 定義的情況下，我們即沒辦法將文本性的配置轉(zhuǎn)換成 pb 二進(jìn)制流，也沒辦法反序列化。因此必須將業(yè)務(wù)的 message 定義上提到運(yùn)營系統(tǒng)，然而 protobuf 卻對可視化編輯不太友好。因此一個(gè)可行的思路是基于JSON 數(shù)據(jù)進(jìn)行配置的定義、可視化操作、傳輸及存儲(chǔ)。只有到達(dá)業(yè)務(wù)側(cè)才進(jìn)行數(shù)據(jù)類型的轉(zhuǎn)換。
安全管理
搭建一套配置運(yùn)營系統(tǒng)，讓之成為運(yùn)營人員管理配置的唯一入口，輕松就可以得到很高的回報(bào)。我們可以基于運(yùn)營系統(tǒng)進(jìn)行各種配置安全加固，如配置的變更必須具備相應(yīng)的權(quán)限，而且只有通過審核才能應(yīng)用到系統(tǒng)，所有的操作都要有審計(jì)的能力，配置的歷史版本快速可查等。
同時(shí)灰度、回退等能力也需要基于運(yùn)營系統(tǒng)進(jìn)行操作。
配置系統(tǒng) SDK
上文提及，集中式配置文件系統(tǒng)的管道定位，agent 只負(fù)責(zé)定期的拉取配置然后緩存到本地的文件系統(tǒng)。業(yè)務(wù)系統(tǒng)與配置系統(tǒng)松耦合。我們認(rèn)為配置文件仍然具有較高的開發(fā)成本，對業(yè)務(wù)方而言，最佳的開發(fā)形式應(yīng)當(dāng)是：
- int GetConfig<Message>(const std::string& key, ::google::protobuf::Message& msg);
而不需要再去理解文件內(nèi)容、形式。那么我們就有必要為業(yè)務(wù)方提供一套配置系統(tǒng)的 SDK，將配置系統(tǒng)的細(xì)節(jié)、數(shù)據(jù)結(jié)構(gòu)等信息都屏蔽起來，讓業(yè)務(wù)只看到配置的 Protobuf Message 對象。
在 SDK 的基礎(chǔ)上，消費(fèi)者只需輕度介入(業(yè)務(wù)插件，見下)，我們就可以完成協(xié)議轉(zhuǎn)換、配置緩存、進(jìn)程，線程，協(xié)程快速最終一致、請求單調(diào)、灰度發(fā)布的能力。
配置系統(tǒng) SDK 是精細(xì)化管理的基礎(chǔ)，我們可以通過維護(hù)配置本身內(nèi)容之外的配置元數(shù)據(jù)信息來完成上述能力。
異步化
異步化是配置 SDK 的關(guān)鍵。很多本地緩存的更新是周期性的由實(shí)時(shí)鏈路請求負(fù)責(zé)，易于實(shí)現(xiàn)，但效率上存在問題，尤其考慮到我們還需要對配置進(jìn)行配置業(yè)務(wù)邏輯的處理。因此，最佳方案應(yīng)當(dāng)是通過異步過程來進(jìn)行配置的加載、初始化及其它邏輯處理。
異步帶來的問題是異步過程與實(shí)時(shí)請求的并發(fā)問題，即異步過程在進(jìn)行配置變更過程中，應(yīng)如何處理實(shí)時(shí)鏈路的讀請求，這是一個(gè)工程問題，我們會(huì)另文討論，一個(gè)可行的思路是多版本及引用計(jì)數(shù)技術(shù)。
業(yè)務(wù)插件
異步為我們提供的另外一個(gè)好處是，業(yè)務(wù)可以在配置生效的時(shí)候進(jìn)行一些初始化動(dòng)作，比如進(jìn)行進(jìn)行配置正確性校驗(yàn)，以及搭建業(yè)務(wù)適合的數(shù)據(jù)結(jié)構(gòu)。比如業(yè)務(wù)白名單在 pb 中只是一個(gè)數(shù)組，如果業(yè)務(wù)進(jìn)行命中查找，代價(jià)比較高。業(yè)務(wù)最期望的方式肯定還是使用 map 來存儲(chǔ)。因此配置 SDK 異步化，就為業(yè)務(wù)插件能力提供了基礎(chǔ)。
推與拉
我們更傾向于配置 SDK 主動(dòng)拉取配置的更新。推與拉的辯證在于效率和可用性。推比較高效，不存在無用的網(wǎng)絡(luò)消耗。但是推又引入了新的系統(tǒng)依賴(即事件中心)。如無必要，勿增實(shí)體，基于這樣的思想，我們傾向于由SDK 周期性主動(dòng)拉取。至于效率，完全可以通過各種工程的手段加以優(yōu)化，達(dá)到可以接受的程度。
當(dāng)然這也取決于系統(tǒng)規(guī)模，如果我們要討論的是公司機(jī)的配置系統(tǒng)，而不是部分中心級(jí)，那么我們也會(huì)認(rèn)真的思考推或者推拉結(jié)合的模式。
快速最終一致
無論是單機(jī)配置文件系統(tǒng)，還是集中配置文件系統(tǒng)，都存在嚴(yán)重的不一致問題。對一次配置變更，基本上都需要很長的時(shí)間才能達(dá)到最終一致(即所有并發(fā)看到相同的數(shù)據(jù)狀態(tài))。
一個(gè)可行的思路是多版本以及定時(shí)生效。配置只有在未來的某個(gè)時(shí)間(該時(shí)間內(nèi) SDK 已經(jīng)拉到了最新數(shù)據(jù))才對外可見。至于如何確保所有 SDK 都拉到了數(shù)據(jù)，這涉及到可用性的問題，我們另文討論。
請求單調(diào)
定時(shí)生效沒辦法解決請求單調(diào)性的問題。請求單調(diào)性是指，實(shí)時(shí)服務(wù)處理一次請求，在請求的調(diào)用棧過程中，讀到的配置內(nèi)容必須是靜態(tài)、沒有變動(dòng)的，即使中間有待生效數(shù)據(jù)變成了生效數(shù)據(jù)。一個(gè)思路是我們可以通過線程私有變量(協(xié)程私有變量)緩存配置版本即可。
灰度發(fā)布
在配置 SDK 多版本能力的基礎(chǔ)上，實(shí)現(xiàn)灰度發(fā)布的能力也是輕而易舉的?；叶劝l(fā)布的能力，不過就是選擇生效配置版本的能力，如果本機(jī)、本角色、本請求業(yè)務(wù) key(如用戶、商戶、訂單)等命中灰度范圍，則使用新版本，否則使用原版本。
效率提升
效率提升包括降低網(wǎng)絡(luò)傳輸數(shù)據(jù)量、降低配置存儲(chǔ)服務(wù)的壓力，這些都是具體的工程手段，我們不在本理論篇內(nèi)討論。
可用性提升
分布式系統(tǒng)的可用性提升是老生常談的話題，為了聚焦于配置系統(tǒng)獨(dú)特的能力，我們本篇不專門進(jìn)行討論。
(However，盡量減少系統(tǒng)中的單點(diǎn)，是一個(gè)重要的原則。在前節(jié)”推與拉“中也有涉及。同時(shí)為了業(yè)務(wù)的可用性，第三方配置系統(tǒng)的運(yùn)營能力、故障主動(dòng)發(fā)現(xiàn)能力、故障通知能力、再現(xiàn)及定位能力也非常重要。也這是重復(fù)造輪子的一個(gè)不得已的重要原因，很多團(tuán)隊(duì)軟件可能作的不錯(cuò)，但服務(wù)能力(主要指運(yùn)營能力)卻有點(diǎn)差強(qiáng)人意。)
【本文為51CTO專欄作者“騰訊技術(shù)工程”原創(chuàng)稿件，轉(zhuǎn)載請聯(lián)系原作者(微信號(hào)：Tencent_TEG)】
