用規(guī)則引擎讓你一天上線十個需求
各位讀者朋友大家好，我是薯條，好久沒更文章，不知還有多少讀者記得這個號，這篇文章寫的有點精分，如果你有耐心看完本文，可以翻翻留言區(qū)，我會發(fā)個新年紅包。
業(yè)務(wù)背景
如果是本號老讀者，可能知道我是做數(shù)據(jù)系統(tǒng)的，作為一個在線數(shù)據(jù)服務(wù)組，我們這邊承接的需求是小而多的。我在一家打車公司上班，運營大佬們認(rèn)為不同用戶在不同場景下有不同打車需求，設(shè)計出來很多子品類。于是我們組會承接這樣一類需求：計算用戶不同品類的各種實時單量，如：快車呼單量、拼車完單量。
這樣的需求，一般處理流程是這樣的：
描述一下這個圖：用戶在訂單流轉(zhuǎn)狀態(tài)關(guān)鍵節(jié)點發(fā)生動作時，系統(tǒng)會發(fā)一個MQ消息讓供其他系統(tǒng)消費。其他系統(tǒng)通過一個明確的據(jù)口徑判斷這條msg是否符合當(dāng)前業(yè)務(wù)邏輯，進而存db或是丟棄。比如一個需求要計算：拼車完單量，一個靠譜的拼車rd告訴你口徑是：
- If aa.bb.cc == 1 // 說明是多車型發(fā)單
- Unmarshal(bb.cc.ee)
- 看type是否為 4
- else // 單車型發(fā)單
- Unmarshal(bb.cc.ff)
- 看type是否為 4
- (type = 4 的是拼車)
你對著這個口徑，訂閱mq，寫數(shù)據(jù)提取和訂單判斷的邏輯，整個流程寫代碼1小時，自測一小時，由于你們機器太多，上線花了1整天，整體研發(fā)效率還行。
第二天，產(chǎn)品又給你提了個需求，想計算拼車的發(fā)單量，你又去找對應(yīng)業(yè)務(wù)線的開發(fā)同學(xué)尋求一個取數(shù)口徑，然后重復(fù)上面的過程。
第三天，產(chǎn)品上線了，效果不錯，數(shù)據(jù)漲了3個點，老板非常開心，在周會上讓PM講兩句他的心路歷程，PM同學(xué)重點感謝了老板的栽培，然后輕描淡寫的說了產(chǎn)品的底層邏輯和關(guān)鍵抓手。而他的幾個精明的同事都get到了抓手是你，于是連夜趕PRD，要求你這個抓手把他們負(fù)責(zé)品類的各種實時單量全給抓出來。
第四天，你崩潰了，因為你收到4個PM并行的8個單量需求，正當(dāng)你奮筆疾書再次準(zhǔn)備重復(fù)上述流程時，你睿智的老板告訴你這樣做有不妥之處：來一個坑填一個蘿卜是小農(nóng)時代的做法，現(xiàn)在都21世紀(jì)了，時代變了，讓你想一種通用解決方案，讓系統(tǒng)走向工業(yè)時代!
你似懂非懂點了點頭，查了各種CSDN、博客園、知乎、github，又在技術(shù)交流群各種@群里大佬有沒有遇到這種場景。一番折騰后終于有了頭緒，于是你高興的向老板匯報：老板，我懂了，這個場景可以用JPATH + Expression Eval來解決!這樣一來，再來新的需求只需要寫在db里插入倆表達(dá)式就可以了，20個需求提過來也不用怕。
你的老板微笑著點了點頭，看了一眼自己手上的勞力士，有意無意的晃了晃，說：小伙子很上道，自己也琢磨出解法了，趕緊設(shè)計方案，爭取本周上線，盡快拿到業(yè)務(wù)結(jié)果，到時候升職加薪少不了你的!
實現(xiàn)方案
這個系統(tǒng)的核心需求有兩點：
- 數(shù)據(jù)提取
- 規(guī)則判斷
數(shù)據(jù)提取即ETL，把mq的msg中關(guān)鍵信息提取出來，提取之后可能還需要簡單處理一下(比如msg中事件時間是timestamp，你想轉(zhuǎn)化為RFC3339格式) ，這里可以用JPATH 做數(shù)據(jù)提取 (如果你寫過爬蟲，一定知道用xpath去提取HTML中的node消息，jpath就是json數(shù)據(jù)的提取規(guī)則)。配置一個ETL rule，如圖所示：
然后是數(shù)據(jù)規(guī)則判斷，即題目中提到的規(guī)則引擎，我們這里使用 開源庫govaluate，比如上面拼車完單的例子，我們可以配置這樣的規(guī)則：
- cc == 1 ? ( in(4, ee)? 1:0 ) : ( ff ==4 ? 1:0)
govaluate會把這個表達(dá)式構(gòu)建出一顆ast，然后輸入?yún)?shù)進行求值(是不是回憶起來了編譯原理?)。接下來讓我們研究一下這個庫~
govaluate介紹與使用注意
govaluate支持對C風(fēng)格的算數(shù)/字符串的表達(dá)式進行求值。比如這些例子(例子來源于evaluation_test.go):
- 1. 100 ^ (23 * (2 | 5))
- 2. 5 < 10 && 1 < 5
- 3. (foo == true) || (bar == true) // foo、bar為變量
- 4. theft && period == 24 ? 60 // theft、period為變量
這個庫幾乎支持你能想象到的任何表達(dá)式，有興趣可以去這個test文件。除此之外它支持拓展UDF， 你可以自己寫一些函數(shù)支持你的定制業(yè)務(wù)邏輯，它還支持執(zhí)行類方法，更多信息可以看README。
當(dāng)我們需要使用它時，只需要這幾行代碼
- expression, err := govaluate.NewEvaluableExpression("foo > 0");
- parameters := make(map[string]interface{}, 8)
- parameters["foo"] = -1;
- result, err := expression.Evaluate(parameters);
- // result is now set to "false", the bool value.
通過這個demo我們可以看到它的api被設(shè)計成了兩步， 第一步NewEvaluableExpression的功能主要是把表達(dá)式拓展為一顆AST，Evaluate的主要功能是把用戶參數(shù)填入ast求值。。舉個例子：比如1 + foo + 4 * boo這個表達(dá)式，在兩個階段分別做的事情是這樣：
那么生產(chǎn)項目代碼中直接把這兩步抄進去就可以了嗎?顯然不是。通過觀察就可以發(fā)現(xiàn)， 第一步構(gòu)造ast依賴的表達(dá)式其實是可以預(yù)先確定的，且表達(dá)式一般不會變化，沒有必要用戶每次傳一個api就構(gòu)造一顆ast然后求值?？梢园驯磉_(dá)式存入db，在項目啟動or更新配置時加載到內(nèi)存中， 比如搞一個map[string]*EvaluableExpression, 把不同表達(dá)式的ast進行cache，這樣用戶每次請求時只需遍歷ast進行求值。
預(yù)編譯所帶來的收益很顯著，尤其是在你表達(dá)式比較復(fù)雜的情況下。我對foo > 2? 1:0這個表達(dá)式分別做了現(xiàn)編譯和預(yù)編譯的benchmark，結(jié)果如下：
現(xiàn)編譯
(現(xiàn)編譯 構(gòu)建ast占用62.3%的cpu開銷，而eval只占2%)
預(yù)編譯
(預(yù)編譯省掉了構(gòu)建ast的成本，節(jié)約了大量cpu資源) 建議大家如果使用這個庫，有條件要用預(yù)編譯版本。
govaluate 原理
看起來govaluate很有意思， 接下來讓我們挖一下它的源碼。首先來看第一階段，把表達(dá)式拓展為AST時的邏輯，我簡單畫了一張圖：
下面以1 + foo + 4 * boo為例，parserToken后，我們可以得到一堆token:
checkBalance沒啥好說的，核心功能就看小括號是否成對出現(xiàn)：
而checkExpressionSyntax階段主要是check token之間是否符合預(yù)設(shè)規(guī)則，核心是這個函數(shù)：
這個函數(shù)會check當(dāng)前的token是否是上一個token的合法值，合法值是預(yù)設(shè)的，比如NUMERIC的合法值是后面這些：
接下來的 optimizeTokens 函數(shù)沒啥好說的，主要就是編譯一下正則。
比較有意思的是planStages這個步驟。planStages這個大步驟內(nèi)部大概分成了planTokens、reorderStages、elideLiterals這三個小步驟，下面來一一介紹：
planTokens
這個函數(shù)寫的讓我大開眼界，首先它用func做不同運算符的優(yōu)先級計算，原理是func接收struct作為參數(shù)，而參數(shù)中的next為這個函數(shù)連接的下一個優(yōu)先級的func。
這個func優(yōu)先級打印出來是這樣的：
有了運算符優(yōu)先級之后，對于具體的節(jié)點，會繼續(xù)看節(jié)點類型，比如是func，accesser還是valueType，valueType的節(jié)點對于不同的詳細(xì)類型也有不同策略，比如數(shù)字節(jié)點會構(gòu)建一個Node，而小括號節(jié)點會直接parser下一個token來構(gòu)建優(yōu)先級更高的樹。
對于不同的運算符，在這個函數(shù)鏈上會下沉構(gòu)建出優(yōu)先級比較高的節(jié)點，保證符合數(shù)學(xué)計算的規(guī)律。
reorderStages
這里主要把ast重排序，讓ast由普通tree變成avl tree，樹旋轉(zhuǎn)的代碼寫的特別騷氣，比如1 + foo + 4 * boo 這個表達(dá)式，planToken執(zhí)行完后，會變成這樣一顆樹：
重排序的過程是把相同優(yōu)先級的節(jié)點進行旋轉(zhuǎn)，第一步是交換左右節(jié)點：
第二步是LL左旋：
這樣就平衡了，一個非常騷氣的算法。
elideLiterals
這個步驟是看葉子節(jié)點是否為LITERAL，比如這棵樹：
在這個階段，各個子節(jié)點會進行dfs計算直接變成：
至此第一階段的邏輯梳理完畢。而第二個階段Evaluate的主要功能是把用戶參數(shù)填入ast，進行求值。這個過程比較簡單，本文不在贅述。
govaluate 不足
govaluate 看起來很美好，真的是這樣嗎?其實不然，這個項目最后一次commit是2017年，距今已經(jīng)6年了。我們在使用期間也發(fā)現(xiàn)了很多小bug和代碼優(yōu)美度欠缺的地方。下面來簡單列舉幾個：
弱類型
govaluate所有數(shù)字類型都是被解析為float64進行計算的，這么玩寫代碼爽了，但是當(dāng)你用1+2+9做表達(dá)式時，可能會得到一個類型為fload64的interface{}結(jié)果。
函數(shù)限制
govaluate的函數(shù)有的返回值無法繼續(xù)做運算。比如這個case：
看起來沒有任何問題，但是執(zhí)行會報錯：
參數(shù)會去除轉(zhuǎn)義符
比如這段代碼：
理論上結(jié)果應(yīng)該含有轉(zhuǎn)義符，實際上結(jié)果是:
實際上是這段代碼搞的鬼，代碼比較簡單，就不解釋了。
奇奇怪怪的代碼
- this關(guān)鍵字：這個就不舉例子了，這個庫里所有方法的接收者都是this，被官方建議熏陶過的我，看的我著實蛋疼...
- 雙重否定表肯定：token解析階段有這樣的代碼，不知道作者為啥要搞個雙重否定，我的話，會用一個isQuote代替。
govaluate改進
作為一個17年后就沒更新過的項目， 也不知道作者還會不會維護。業(yè)務(wù)發(fā)展是不等人，govaluate對于我們服務(wù)來說并不能滿足需求，很多時候用起來比較別扭，所以我基于我們的場景對于govaluate做了一些定制改造。我個人還是非常喜歡這個庫的，于是把代碼fork了一份，加了個eplus后綴，改造了上面那幾個匪夷所思的問題。并加了個比較定制化的feature：type promotion。
這個聽起來比較唬人， 其實就是支持更弱類型的表達(dá)式運算，比如我的庫支持：'2' -1, '4' * 3，要支持這種功能，核心需要改兩種地方：
- 第一種地方是typeCheck。比如subStage會check兩個字節(jié)點必須是float64類型， 我們要支持string operator num， 可以把typeCheck擴大為可以是chek node是否為 floatOrStr。
- 第二種地方是OpeatorOperate。前面我們把String類型也放進來讓它支持計算了，但是在go里str和float終究是無法計算的， 所以到了計算階段需要做一個type promotion，即把string類型轉(zhuǎn)化為數(shù)字類型之后再計算。
總結(jié)與反思
總結(jié)
govaluate在我心中還是有一些不完美的地方，我們這里用它也是因為項目初期就引入了這個庫，在大量的線上用例使用后要遷移這個庫成本巨大， 對于用的不爽的地方只能改了。如果讀者朋友有需求， 可以看一下市面上其他的表達(dá)式開源庫， 比如gval。當(dāng)然，如果你的場景比較復(fù)雜， 需要很多if else 或者for循環(huán)，那簡單的規(guī)則引擎可能滿足不了你的需求，此時可以考慮內(nèi)嵌個更完整的腳本庫或者嵌入lua， 不過這樣就更復(fù)雜了， 慎重考慮把這樣的東西直接放在db里面， 后期不好維護。
反思
govaluate這個庫對我有很多啟發(fā)，最主要就是表達(dá)式的預(yù)編譯可以節(jié)省大量CPU開銷，組內(nèi)某個項目目前的運行方式是隨著請求現(xiàn)編譯，構(gòu)建執(zhí)行計劃dag圖，理論上如果能預(yù)編譯，請求到來只是對于對應(yīng)param訪問存儲，可以節(jié)省大量CPU開銷。
跳脫出govaluate本身，我們系統(tǒng)選擇JPATH + Expr做數(shù)據(jù)提取和條件描述做需求，本質(zhì)上是因為這邊的mq數(shù)據(jù)是JSON格式，JSON有一定的局限性，描述數(shù)據(jù)沒啥問題，但是描述條件就比較困難了，理論上如果用XML這種技能描述條件，又能描述數(shù)據(jù)的交互形式，那我們可能會構(gòu)建一個完全不同的系統(tǒng)。
最后稍微打個廣告吧， 如果你也想使用govaluate，又有一些定制化的需求，歡迎star我的庫然后提個issue， 我想試著維護一個開源庫， 嘿嘿。
