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