用規(guī)則引擎讓你一天上線十個需求
各位讀者朋友大家好,我是薯條,好久沒更文章,不知還有多少讀者記得這個號,這篇文章寫的有點精分,如果你有耐心看完本文,可以翻翻留言區(qū),我會發(fā)個新年紅包。
業(yè)務(wù)背景
如果是本號老讀者,可能知道我是做數(shù)據(jù)系統(tǒng)的,作為一個在線數(shù)據(jù)服務(wù)組,我們這邊承接的需求是小而多的。我在一家打車公司上班,運營大佬們認為不同用戶在不同場景下有不同打車需求,設(shè)計出來很多子品類。于是我們組會承接這樣一類需求:計算用戶不同品類的各種實時單量,如:快車呼單量、拼車完單量。
這樣的需求,一般處理流程是這樣的:
描述一下這個圖:用戶在訂單流轉(zhuǎn)狀態(tài)關(guān)鍵節(jié)點發(fā)生動作時,系統(tǒng)會發(fā)一個MQ消息讓供其他系統(tǒng)消費。其他系統(tǒng)通過一個明確的據(jù)口徑判斷這條msg是否符合當前業(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,要求你這個抓手把他們負責品類的各種實時單量全給抓出來。
第四天,你崩潰了,因為你收到4個PM并行的8個單量需求,正當你奮筆疾書再次準備重復(fù)上述流程時,你睿智的老板告訴你這樣做有不妥之處:來一個坑填一個蘿卜是小農(nóng)時代的做法,現(xiàn)在都21世紀了,時代變了,讓你想一種通用解決方案,讓系統(tǒng)走向工業(yè)時代!
你似懂非懂點了點頭,查了各種CSDN、博客園、知乎、github,又在技術(shù)交流群各種@群里大佬有沒有遇到這種場景。一番折騰后終于有了頭緒,于是你高興的向老板匯報:老板,我懂了,這個場景可以用JPATH + Expression Eval來解決!這樣一來,再來新的需求只需要寫在db里插入倆表達式就可以了,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會把這個表達式構(gòu)建出一顆ast,然后輸入?yún)?shù)進行求值(是不是回憶起來了編譯原理?)。接下來讓我們研究一下這個庫~
govaluate介紹與使用注意
govaluate支持對C風(fēng)格的算數(shù)/字符串的表達式進行求值。比如這些例子(例子來源于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為變量
這個庫幾乎支持你能想象到的任何表達式,有興趣可以去這個test文件。除此之外它支持拓展UDF, 你可以自己寫一些函數(shù)支持你的定制業(yè)務(wù)邏輯,它還支持執(zhí)行類方法,更多信息可以看README。
當我們需要使用它時,只需要這幾行代碼
- 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的功能主要是把表達式拓展為一顆AST,Evaluate的主要功能是把用戶參數(shù)填入ast求值。。舉個例子:比如1 + foo + 4 * boo這個表達式,在兩個階段分別做的事情是這樣:
那么生產(chǎn)項目代碼中直接把這兩步抄進去就可以了嗎?顯然不是。通過觀察就可以發(fā)現(xiàn), 第一步構(gòu)造ast依賴的表達式其實是可以預(yù)先確定的,且表達式一般不會變化,沒有必要用戶每次傳一個api就構(gòu)造一顆ast然后求值。可以把表達式存入db,在項目啟動or更新配置時加載到內(nèi)存中, 比如搞一個map[string]*EvaluableExpression, 把不同表達式的ast進行cache,這樣用戶每次請求時只需遍歷ast進行求值。
預(yù)編譯所帶來的收益很顯著,尤其是在你表達式比較復(fù)雜的情況下。我對foo > 2? 1:0這個表達式分別做了現(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很有意思, 接下來讓我們挖一下它的源碼。首先來看第一階段,把表達式拓展為AST時的邏輯,我簡單畫了一張圖:
下面以1 + foo + 4 * boo為例,parserToken后,我們可以得到一堆token:
checkBalance沒啥好說的,核心功能就看小括號是否成對出現(xiàn):
而checkExpressionSyntax階段主要是check token之間是否符合預(yù)設(shè)規(guī)則,核心是這個函數(shù):
這個函數(shù)會check當前的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é)點對于不同的詳細類型也有不同策略,比如數(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 這個表達式,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進行計算的,這么玩寫代碼爽了,但是當你用1+2+9做表達式時,可能會得到一個類型為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。
這個聽起來比較唬人, 其實就是支持更弱類型的表達式運算,比如我的庫支持:'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在我心中還是有一些不完美的地方,我們這里用它也是因為項目初期就引入了這個庫,在大量的線上用例使用后要遷移這個庫成本巨大, 對于用的不爽的地方只能改了。如果讀者朋友有需求, 可以看一下市面上其他的表達式開源庫, 比如gval。當然,如果你的場景比較復(fù)雜, 需要很多if else 或者for循環(huán),那簡單的規(guī)則引擎可能滿足不了你的需求,此時可以考慮內(nèi)嵌個更完整的腳本庫或者嵌入lua, 不過這樣就更復(fù)雜了, 慎重考慮把這樣的東西直接放在db里面, 后期不好維護。
反思
govaluate這個庫對我有很多啟發(fā),最主要就是表達式的預(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, 我想試著維護一個開源庫, 嘿嘿。