描述

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

舉個例子：

“用戶每次下單后統(tǒng)計其當天完單量，并發(fā)給下游營銷系統(tǒng)其總完單量信息。下游營銷系統(tǒng)會根據(jù)用戶的完單量推送優(yōu)惠策略。

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

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

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

黃色方塊的operator主要操作存儲，需要在配置中描述數(shù)據(jù)的存儲以及獲取相關(guān)的信息；

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

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

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

咋存

第一個問題是系統(tǒng)的配置存在哪里。

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

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

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

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

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

咋配

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

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

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

“用戶每次完單后統(tǒng)計其總完單量，完單量達到不同閾值后給用戶下發(fā)不同的成就。

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

為啥要采用這樣的架構(gòu)呢。由于離線數(shù)據(jù)的產(chǎn)出時間不固定，所以需要一個dt字段做標識。

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

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

若現(xiàn)在8點鐘，離線任務跑完了，此時單量計算規(guī)則為：

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

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

咋保證HA

現(xiàn)在有了管理系統(tǒng)+MySQL去管理配置就萬事大吉了嗎？

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

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

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

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

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

版本控制方面：前些日子逛Github時我發(fā)現(xiàn)了一個有趣的庫：https://github.com/dolthub/dolt?？匆幌滤慕榻B：

“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協(xié)議和Git協(xié)議的數(shù)據(jù)庫，支持git就有趣多了，我們所有關(guān)于配置的更改記錄都有版本信息，基于這個庫封裝出API并集成在管理平臺中，前端渲染一個酷炫版本信息頁面。我們就可以通過點點點進行g(shù)it reset操作了。

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

責任編輯：lq6