描述

很多業務場景固定、不那么偏向“業務”的系統如果遇到靠譜的工程師最終會走向配置化。達到配置化的先決條件是 系統內部有個”引擎“模塊，引擎讀取配置信息把業務流程生成出執行計劃，這個執行計劃根據業務形態可以是 DAG、鏈表、樹或是其他。有了這套系統，日常開發就變成寫配置+豐富系統能力了。

舉個例子：

“用戶每次下單后統計其當天完單量，并發給下游營銷系統其總完單量信息。下游營銷系統會根據用戶的完單量推送優惠策略。

這個業務需求抽象后可以用下圖表示業務流程，黃色方塊主要和存儲打交道，藍色方塊是純計算流程。

這整個流程完全可以用配置化方式解決：

MQ消息的ETL在配置中描述需要的字段的path信息解析;

黃色方塊的operator主要操作存儲，需要在配置中描述數據的存儲以及獲取相關的信息；

藍色方塊的operator是純計算流程，配置中描述schema格式即可；

最后再配個轉發mq消息的配置，不到一小時支持了一個看起來有點復雜的業務需求，此時你就可以美滋滋的寫周報去了~

整個流程看起來無比絲滑，但是配置化系統是銀彈嗎？繼續探究一下所謂的”配置“。

咋存

第一個問題是系統的配置存在哪里。

配置化系統的本質是：引擎解析配置信息，生成operator執行計劃操作DB和計算行為。程序員通過提前寫好通用operator，支持業務時不上線、不寫定制代碼，只寫配置信息就可以支持業務，一定程度上提高了開發效率。

配置信息可以選擇存到db或是file里。如果我們目的之一是不上線即可支持業務，那把配置信息寫到文件里就不是個好主意，因為在代碼中更新文件后還得經過上線流程，這樣會降低效率，所以把配置存到db里。

把配置文件存入像MySQL這樣的db里，還有其他好處：

前面例子中講到了完單量這個業務流程的配置信息，配置信息可以當成一個API供上游調用，這樣的API是可以復用的，當系統里有成千上萬的API后，若沒有一套管理系統來管理元信息，那幾乎就是災難了。配置的元信息存到MySQL后，你可以很快樂的寫一些管理接口管理配置。

基于MySQL的備份機制還可以做配置信息備份，以防不測。

咋配

第二個問題是 配置=簡單嗎？

有了配置化系統之后，開發日常的工作就變成了寫配置，然而在mysql里通過SQL寫配置并不一定比寫代碼輕松愉快。。。

文章前面的例子模型可以抽象成一個形如鏈表的pipline，這樣看起來還比較簡單，但是現實中很多業務比這個要復雜多了，很多業務抽象出來是個好幾層的樹型結構，這種東西靠人寫SQL描述執行計劃并不一定比寫代碼簡單多少。稍微拓展一下上面的例子：

“用戶每次完單后統計其總完單量，完單量達到不同閾值后給用戶下發不同的成就。

這個API的模型如下圖所示，它采用所謂的lambda架構，在離線中計算用戶T+1的總單量，同時根據離線總單量產出日期dt 補充在線單量，最終把兩部分數據加起來返回給業務方結果。

為啥要采用這樣的架構呢。由于離線數據的產出時間不固定，所以需要一個dt字段做標識。

舉個例子，現在是3月20號凌晨1點整，此時19號的離線任務沒有跑完，此時單量計算規則為：

“用戶總完單量 = 18號總單量（離線）+19號當天單量（在線） + 20號當天單量（在線）。

若現在8點鐘，離線任務跑完了，此時單量計算規則為：

“用戶總完單量 = 19號總單量（離線） + 20號當天單量（在線）。

上面這套流程已經比較復雜了，你可以想一下這塊該如何配置，再想想如何通過SQL去描述配置。如果業務方還想在API中增加判定邏輯，比如 單量超過500單就通知下游給用戶發個章，那配置起來就更復雜了。所以把配置存到管理平臺后，還需要在平臺上搞一個牛逼的前端頁面，讓開發同學可以在界面上勾勾選，拖拖拽拽，把配置描述出來，而且支持REPL讓用戶可以debug。

咋保證HA

現在有了管理系統+MySQL去管理配置就萬事大吉了嗎？

萬事總有個意外。業務迭代過程中，系統開發一般會比平臺開發先行。比如你為這套牛逼的配置系統增加了一個feature，在這個feature集成到平臺之前，還是得寫SQL做需求。這其實有很大風險的：如果你SQL寫錯了，在線下沒復現出來，業務比較著急，上線時候沒灰度就上全量集群了，系統就崩了~此時你慌得一批，趕緊寫了個delete的SQL去刪除那行配置，如果這個delete恰好沒加條件，且你的MySQL中沒配置SQL_SAFE_UPDATES變量，那恭喜你，這一趟折騰下來系統不可用時間起碼半個小時，可以準備跑路了~

前面那段是我編的，只是要說明需要保證配置的HA（high availability）。

我們寫代碼時會使用git來做版本控制，且像golang這種編譯型語言還會有編譯器來幫你檢查代碼是否有語法錯誤。如果配置也像代碼一樣，那該有多好啊：

實際上這兩部分都是可以達到的，

編譯檢查方面：配置信息一般使用json格式表示，所謂編譯檢查一方面可以檢查json格式是否正確，另一方面可以根據業務特性檢查json配置是否符合規范。

版本控制方面：前些日子逛Github時我發現了一個有趣的庫：https://github.com/dolthub/dolt。看一下它的介紹：

“Dolt is a SQL database that you can fork， clone， branch， merge， push and pull just like a git repository. Connect to Dolt just like any MySQL database to run queries or update the data using SQL commands. Use the command line interface to import CSV files， commit your changes， push them to a remote， or merge your teammate‘s changes.

這玩意可以視為一個支持SQL協議和Git協議的數據庫，支持git就有趣多了，我們所有關于配置的更改記錄都有版本信息，基于這個庫封裝出API并集成在管理平臺中，前端渲染一個酷炫版本信息頁面。我們就可以通過點點點進行git reset操作了。

對于配置本身，可以有一些方式來保證高可用，在系統內部，同樣可以做一些兜底操作，如下圖所示：

責任編輯：lq6