描述

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

舉個(gè)例子：

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

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

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

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

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

藍(lán)色方塊的operator是純計(jì)算流程，配置中描述schema格式即可；

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

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

咋存

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

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

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

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

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

基于MySQL的備份機(jī)制還可以做配置信息備份，以防不測(cè)。

咋配

第二個(gè)問題是 配置=簡(jiǎn)單嗎？

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

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

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

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

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

舉個(gè)例子，現(xiàn)在是3月20號(hào)凌晨1點(diǎn)整，此時(shí)19號(hào)的離線任務(wù)沒有跑完，此時(shí)單量計(jì)算規(guī)則為：

“用戶總完單量 = 18號(hào)總單量（離線）+19號(hào)當(dāng)天單量（在線） + 20號(hào)當(dāng)天單量（在線）。

若現(xiàn)在8點(diǎn)鐘，離線任務(wù)跑完了，此時(shí)單量計(jì)算規(guī)則為：

“用戶總完單量 = 19號(hào)總單量（離線） + 20號(hào)當(dāng)天單量（在線）。

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

咋保證HA

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

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

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

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

實(shí)際上這兩部分都是可以達(dá)到的，

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

版本控制方面：前些日子逛Github時(shí)我發(fā)現(xiàn)了一個(gè)有趣的庫：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.

這玩意可以視為一個(gè)支持SQL協(xié)議和Git協(xié)議的數(shù)據(jù)庫，支持git就有趣多了，我們所有關(guān)于配置的更改記錄都有版本信息，基于這個(gè)庫封裝出API并集成在管理平臺(tái)中，前端渲染一個(gè)酷炫版本信息頁面。我們就可以通過點(diǎn)點(diǎn)點(diǎn)進(jìn)行g(shù)it reset操作了。

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

責(zé)任編輯：lq6