接手Drule2.0這套規(guī)則引擎的時候我心里其實有點嘀咕。項目從1.x升級過來舊的規(guī)則文件全得重寫接口層面也動了不少。當(dāng)時團隊里沒人系統(tǒng)整理過新版的用法文檔東一塊西一塊大多是一句“按老版本兼容”就帶過了。結(jié)果上線測試第一周我們就被規(guī)則不生效、會話狀態(tài)串掉這類問題連續(xù)錘了好幾次。后來我花了兩周時間把Drule2.0從配置、開發(fā)到上線排查的整套鏈路重新捋了一遍也把生產(chǎn)環(huán)境踩過的坑都補進了內(nèi)部使用手冊。這篇就當(dāng)是一個更詳細的外部版給正在或者準備用Drule2.0的同行一個參考。內(nèi)容按照我對這套引擎的理解來組織重點放在“怎么用對”和“怎么排查錯”上適合后端開發(fā)、規(guī)則配置人員以及對規(guī)則引擎選型感興趣的同學(xué)。1. 規(guī)則引擎到底解決了什么問題先對齊一個認知很多團隊把規(guī)則引擎當(dāng)成“if-else的替代品”這么理解不能說錯但容易用歪。以我參與的這個金融風(fēng)控項目為例最直接的痛點不是代碼寫不出判斷邏輯而是業(yè)務(wù)規(guī)則天天變下午三點業(yè)務(wù)方提需求說“貸款額度超過五萬且歷史逾期超過兩次的訂單要人工審核”第二天上午就要上線。傳統(tǒng)的做法是改代碼、發(fā)版、走回歸一套流程下來最快也得一兩天而且改一次代碼就要動一次測試用例成本嘩嘩往上漲。Drule2.0把“決策邏輯”從業(yè)務(wù)代碼里拆了出來變成了獨立的規(guī)則文件。規(guī)則文件可以由業(yè)務(wù)分析師或運營人員通過配置界面維護也可以由開發(fā)以文本形式提交到倉庫再走CI流程發(fā)布。推送一次規(guī)則相當(dāng)于業(yè)務(wù)邏輯的即時熱更新不需要重啟服務(wù)也不需要重新編譯主程序。再說深一層規(guī)則引擎的價值不只是“快”還有一個容易被忽略的點可審計。金融項目做風(fēng)控決策需要回答“這筆訂單為什么被拒”這個問題。如果判斷邏輯散落在代碼的十幾個if-else里你很難快速給出完整依據(jù)。規(guī)則引擎里每一條規(guī)則都有獨立的命名、條件描述和動作定義引擎執(zhí)行完還可以輸出詳細的決策軌跡我在第7章會專門講這個問題。Drule2.0和典型的Drools等老牌引擎相比最明顯的差異是降低了規(guī)則編寫的門檻同時把“規(guī)則集”和“會話生命周期”這兩個概念徹底分開了。這意味著同一條規(guī)則可以被不同業(yè)務(wù)場景以不同參數(shù)加載執(zhí)行也允許引擎在同一進程里跑多個相互隔離的規(guī)則會話。這個設(shè)計對于中大型項目來說很關(guān)鍵因為同一個風(fēng)控服務(wù)可能同時服務(wù)好幾個產(chǎn)品線每條產(chǎn)品線的規(guī)則模板和優(yōu)先級策略并不相同。如果只是幾十條固定判斷說實話硬編碼在代碼里并不丟人。規(guī)則引擎的優(yōu)勢要等規(guī)則量上了百、變更頻率上了周、參與維護的人超過兩三個之后才會明顯體現(xiàn)。所以我給你的第一條建議是先別急著給項目上規(guī)則引擎先盤一下規(guī)則的規(guī)模和變更頻率。2. 六個核心概念從規(guī)則文件到會話一次講透Drule2.0的官方文檔里概念很多但真正貫穿日常開發(fā)的其實就六個。把這六個概念和它們之間的關(guān)系搞明白后面所有配置和接口調(diào)用都不會跑偏。2.1 事實引擎操作的對象事實是進入規(guī)則引擎參與匹配的數(shù)據(jù)對象。它可以是一個訂單對象、一個用戶實體也可以是一個Map。引擎本身不關(guān)心事實的業(yè)務(wù)語義只把它當(dāng)作“是什么類、有哪些屬性、當(dāng)前值是多少”的數(shù)據(jù)載體。在Drule2.0的Java客戶端里事實通常是POJO規(guī)則里通過全限定類名加屬性引用來取值。比如規(guī)則文件里寫OrderInfo(amount 50000)就是在匹配一個名為OrderInfo的事實對象并且要求它的amount字段大于等于50000。有一點要注意同一個會話里可以插入多個不同類型的事實引擎在處理時會把這些事實統(tǒng)一放進工作內(nèi)存規(guī)則的條件部分可以引用其中任意一個或多個。2.2 條件與動作規(guī)則文件的一左一右規(guī)則文件里最核心的兩個部分是條件Left Hand Side簡稱LHS和動作Right Hand Side簡稱RHS。條件描述“什么時候觸發(fā)”動作描述“觸發(fā)后干什么”。條件部分通常由字段約束、邏輯組合和事實之間的關(guān)聯(lián)組成動作部分可以是修改變量值、調(diào)用日志、對外發(fā)消息或者只是簡單地把規(guī)則名記下來。我自己寫規(guī)則時的一個習(xí)慣是盡量讓動作簡單可控不要在動作里寫太復(fù)雜的處理邏輯。規(guī)則引擎適合做決策不適合做重型業(yè)務(wù)處理。如果某個動作需要調(diào)用第三方服務(wù)或者寫數(shù)據(jù)庫建議放到引擎外部去做規(guī)則里只輸出一個“建議結(jié)果”這樣可以保持規(guī)則文件的輕量。2.3 規(guī)則集獨立命名的規(guī)則容器規(guī)則集是一個邏輯容器把一組規(guī)則打包在一起。Drule2.0里一個規(guī)則文件或者一個發(fā)布包通常對應(yīng)一個規(guī)則集。規(guī)則集之間是隔離的這意味著你創(chuàng)建會話時只能加載指定的一個或幾個規(guī)則集不會互相干擾。項目里如果你的規(guī)則被分成“反欺詐規(guī)則集”“額度審批規(guī)則集”“黑名單規(guī)則集”它們在加載時就是獨立、隔離的。這帶來一個很大的好處你可以單獨測試、單獨發(fā)布某一個規(guī)則集而不影響其他正在運行的規(guī)則。2.4 無狀態(tài)會話與有狀態(tài)會話別選錯這是Drule2.0實際使用中最容易出問題的地方也是文檔里描述最抽象的地方之一。無狀態(tài)會話就像一次性的純凈水杯你把事實丟進去引擎當(dāng)場算完返回結(jié)果會話直接銷毀。適合一次請求一次決策的場景比如“判斷這個訂單要不要風(fēng)控攔截”。有狀態(tài)會話則像一個持續(xù)對話的窗口你可以在會話里分多次插入事實每次插入后觸發(fā)規(guī)則還可以在后續(xù)查詢之前規(guī)則的執(zhí)行結(jié)果。適合需要分階段決策、或者在一個流程里多次依賴上一次結(jié)果的場景。我強烈建議除非你的業(yè)務(wù)流程確實需要跨多次觸發(fā)保存中間狀態(tài)否則優(yōu)先用無狀態(tài)會話。有狀態(tài)會話用不好最典型的問題就是“上次請求的數(shù)據(jù)污染了本次結(jié)果”我在第7章會詳細講一個因為復(fù)用有狀態(tài)會話導(dǎo)致的線上事故。2.5 規(guī)則模板與動態(tài)參數(shù)前面說過Drule2.0降低編寫門檻主要體現(xiàn)在規(guī)則模板機制上。你可以在規(guī)則文件里定義模板變量比如minAmount和maxAmount然后在創(chuàng)建會話時傳入?yún)?shù)值。同一個規(guī)則集因為傳入?yún)?shù)不同可以形成“消費貸額度偏好模板”和“小微企業(yè)貸額度偏好模板”兩套執(zhí)行效果。這比舊版本里為每個商戶復(fù)制一份規(guī)則文件的做法干凈多了。以前我們給商戶A寫一份規(guī)則、給商戶B復(fù)制一份再改改參數(shù)結(jié)果規(guī)則數(shù)量指數(shù)級膨脹維護成本高到想罵人。用模板參數(shù)后一份規(guī)則同時服務(wù)幾十個不同配置的對象規(guī)則文件本身幾乎不需要重復(fù)維護。2.6 規(guī)則函數(shù)的擴展方式Drule2.0不可能覆蓋所有業(yè)務(wù)場景的自定義邏輯。文件里還預(yù)留了自定義函數(shù)的注冊接口開發(fā)人員可以寫一小段Java代碼把判斷邏輯打包注冊成函數(shù)規(guī)則里直接調(diào)用。比如根據(jù)身份證號計算年齡段、根據(jù)經(jīng)緯度判斷是否屬于同一城市這些邏輯就不是規(guī)則語言能優(yōu)雅表達的注冊成函數(shù)后在規(guī)則文件里用一行調(diào)用就行。這里有一個邊界要守好自定義函數(shù)應(yīng)該是“判斷工具”不要用自定義函數(shù)去操作其他事實對象或者修改全局變量否則會讓規(guī)則執(zhí)行的可預(yù)測性變得很差。3. 規(guī)則文件長什么樣一份風(fēng)格靈活但邊界清晰的配置Drule2.0的規(guī)則文件在社區(qū)版里支持好幾種格式不同行業(yè)使用習(xí)慣也不同。我基于實際項目經(jīng)驗把規(guī)則文件拆解成兩層來看。3.1 規(guī)則文件的基本骨架下面這段是個風(fēng)格類似DRL但做了簡化脫敏的示例用來展示核心字段的邏輯關(guān)系。Drule2.0對規(guī)則文件有一套schema校驗規(guī)則如果使用了不屬于本版本的關(guān)鍵字發(fā)布包在校驗階段就會報錯。具體的文件名后綴和packaging方式建議以你所用發(fā)行版的官方CLI或編輯器插件提示為準。package demo.risk import com.example.dto.OrderInfo import com.example.dto.UserProfile rule 高危訂單攔截 when $order : OrderInfo(amount 50000, channel ONLINE) $user : UserProfile(riskLevel HIGH) then $order.setIntercept(true); $order.setReasonCode(AMOUNT_HIGH_WITH_RISK); drule.log(hit rule: HIGH_RISK_ORDER); end幾個關(guān)鍵點拆開說package表示所屬包名類似Java的包主要用于組織和隔離規(guī)則。import引入需要操作的事實類。不引入直接用字符串類名也可以但會犧牲編譯期檢查線上跑出來容易出類型不匹配。rule 名稱規(guī)則名稱在當(dāng)前規(guī)則集里必須唯一。一旦重復(fù)發(fā)布時直接報錯。我曾經(jīng)見過兩個同事各自加了同名規(guī)則結(jié)果發(fā)布校驗階段卡了好久。when條件區(qū)。上面示例里兩個模式之間默認是“同時滿足”的關(guān)系。Drule2.0默認所有條件都是與的關(guān)系如果你想表達“或”需要顯式使用or關(guān)鍵字或者拆成兩條規(guī)則。then動作區(qū)。用類似Java的語法修改變量、打日志。注意變量上的$前綴只是慣例方便區(qū)分規(guī)則變量和事實對象的內(nèi)部字段不是強制的。3.2 JSON風(fēng)格規(guī)則描述文件業(yè)務(wù)配置團隊更習(xí)慣的是JSON格式的規(guī)則描述。Drule2.0支持把規(guī)則拆成“描述動作腳本”的結(jié)構(gòu)。下面是我們在某個信貸審批場景里用過的簡化結(jié)構(gòu){ ruleSet: loan_check, ruleList: [ { ruleName: loan_overdue_check, description: 歷史逾期超過3次且當(dāng)前未結(jié)清的單直接拒絕, priority: 10, enabled: true, condition: { type: and, items: [ { field: overdueCount, operator: , value: 3 }, { field: currentStatus, operator: , value: UNPAID } ] }, action: { type: script, script: order.setResult(REJECT); order.setReason(OVERDUE); } } ] }JSON格式對非開發(fā)人員相對友好而且天然支持模板變量替換。配置人員不需要理解Java語法只需要知道字段名、比較符和結(jié)果集就能自己維護一套規(guī)則。我們把字段清單維護成一份數(shù)據(jù)字典上面的overdueCount、currentStatus就是字典里的標準字段規(guī)則配置人員照著字典寫基本不會出界。3.3 條件操作符的種類和用法Drule2.0常用操作符大概是這些操作符示例含義說明status CLOSED等于字符串用雙引號amount 10000數(shù)值比較age 25數(shù)值比較和上面一樣支持整數(shù)與小數(shù)!status ! BLOCKED不等于inchannel in [APP, MINIAPP]屬于給定集合not inlevel not in [LOW, MEDIUM]不屬于給定集合matchesmobile matches ^1[3-9]正則匹配containstagList contains VIP集合字段包含某元素exists/not existsexists(SubOrder)工作內(nèi)存中是否存在某類事實實際項目中遇得最多的是兩種問題一是字符串比較漏了引號導(dǎo)致當(dāng)成字段名解析二是時間類型的比較沒有嚴格統(tǒng)一格式導(dǎo)致規(guī)則執(zhí)行結(jié)果前后不一致。時間字段我建議統(tǒng)一轉(zhuǎn)成時間戳long類型再比較不要直接比較日期字符串。3.4 動作區(qū)支持的不只是賦值動作區(qū)看起來像Java但它主要做三類事情給事實對象的字段賦值比如order.setResult(REJECT)。調(diào)用規(guī)則引擎內(nèi)置API比如drule.log()輸出執(zhí)行日志或者用drule.insert()往工作內(nèi)存里插入一個新事實從而觸發(fā)后續(xù)規(guī)則。調(diào)用注冊好的自定義函數(shù)比如if (riskUtil.isBlack(mobile)) { ... }。動作區(qū)不適合做的是長時間阻塞的IO操作、復(fù)雜事務(wù)、需要異步回調(diào)的流程。遇到這些需求更合理的做法是規(guī)則只負責(zé)設(shè)置一個標記值真正的處理邏輯放到引擎外部通過監(jiān)聽器或者后置鉤子去完成。4. 引擎內(nèi)部是怎么找到那條規(guī)則的優(yōu)先級、沖突與規(guī)則鏈用規(guī)則引擎的人經(jīng)常有一個疑問“我插入了事實引擎到底按什么順序執(zhí)行規(guī)則如果好幾條規(guī)則都能匹配上先執(zhí)行誰”這一章把順序問題講透。Drule2.0的處理機制并不神秘它本質(zhì)上做的是模式匹配匹配完成之后再進行規(guī)則沖突的解決與激活執(zhí)行。4.1 規(guī)則執(zhí)行的兩階段流程第一階段是“匹配”。事實插入工作內(nèi)存后引擎會把事實對象和當(dāng)前規(guī)則集里的所有規(guī)則條件進行匹配。注意不是順序遍歷那種簡單匹配引擎內(nèi)部有一個索引結(jié)構(gòu)來緩存模式與事實之間的關(guān)聯(lián)這也是為什么大量規(guī)則下引擎的執(zhí)行性能依然能穩(wěn)住的原因。這個階段的結(jié)果是產(chǎn)生一個“激活表”也就是“哪些規(guī)則在當(dāng)前事實組合下被滿足”。第二階段是“執(zhí)行-沖突解決”。如果激活表有多條激活的規(guī)則引擎按照議程Agenda的次序逐條執(zhí)行動作區(qū)的代碼。一條規(guī)則動作執(zhí)行完畢后如果它向工作內(nèi)存插入了新事實或者修改了已有事實引擎會重新進行匹配產(chǎn)生新一輪激活繼續(xù)執(zhí)行直到?jīng)]有新激活規(guī)則為止。4.2 優(yōu)先級是怎么排的數(shù)字越大越先跑Drule2.0里的規(guī)則優(yōu)先級用priority字段控制默認值是0。數(shù)值越高在當(dāng)前議程里越靠前執(zhí)行。規(guī)則文件里可以寫成rule 高優(yōu)先級規(guī)則 priority 100 when ...在JSON風(fēng)格里對應(yīng)priority: 100。我在配置優(yōu)先級時踩過一個教訓(xùn)不要指望同一事實下互不相關(guān)的規(guī)則也嚴格按照優(yōu)先級排順序。優(yōu)先級只在“匹配同一組事實的規(guī)則”之間的執(zhí)行順序上有意義如果規(guī)則觸發(fā)的條件本質(zhì)上不同那么它激活的時機都不一樣硬調(diào)優(yōu)先級反而不容易理解。把規(guī)則按業(yè)務(wù)階段分層優(yōu)先保證層內(nèi)順序正確跨層的順序交給事實流轉(zhuǎn)去控制是我目前覺得最清晰的做法。4.3 沖突解決的三條隱性規(guī)則如果優(yōu)先級相同且都匹配了同一組事實Drule2.0內(nèi)部按照一個固定的規(guī)則來排序雖然不同發(fā)行版可能略有差異但大致思路是規(guī)則的“特化程度”高者優(yōu)先。也就是條件寫得越具體、約束條件越多的規(guī)則系統(tǒng)認為它信息量更大越該先執(zhí)行。事實插入順序靠前的優(yōu)先。先插入的事實匹配出來的激活規(guī)則排在前面。如果規(guī)則文件里顯式聲明了規(guī)則順序按聲明的先后關(guān)系執(zhí)行。實際配置中不要指望這些隱性排序來解決業(yè)務(wù)問題而是要對“同時命中且互相影響”的規(guī)則設(shè)置顯式的優(yōu)先級防止隱性排序變化時出現(xiàn)行為抖動。4.4 規(guī)則鏈與重復(fù)觸發(fā)保護規(guī)則動作里可以插入新事實并觸發(fā)后續(xù)規(guī)則這形成了規(guī)則鏈。規(guī)則鏈可以簡化復(fù)雜決策流程的表達但有一個危險如果規(guī)則A的動作為事實X設(shè)置了一個值而規(guī)則B的條件又依賴這個值等規(guī)則B執(zhí)行完后又反過來修改了事實X導(dǎo)致規(guī)則A再次激活就可能無限循環(huán)。Drule2.0在循環(huán)防護上提供了開關(guān)配置同時建議規(guī)則作者在容易形成環(huán)的地方設(shè)置觸發(fā)次數(shù)上限這類業(yè)務(wù)條件。遇到線上規(guī)則無限循環(huán)問題先看日志里有沒有同一個規(guī)則名反復(fù)出現(xiàn)再檢查動作區(qū)是否改動了條件區(qū)依賴的字段。關(guān)于規(guī)則鏈還有一點非常重要如果一條規(guī)則的觸發(fā)條件里依賴了自己動作修改過的字段最好仔細測試否則很容易出現(xiàn)“你以為只跑一次實際被再次激活”的情況。除非確有需要否則條件字段和動作修改字段應(yīng)該盡量錯開。4.5 決策表Excel也能做規(guī)則Drule2.0的配置中心支持把規(guī)則以決策表形式導(dǎo)入。決策表比較適合“條件多、結(jié)果為離散值”的場景第一行放條件字段下一行放比較符第三行放具體條件值最后一行放結(jié)果。決策表在后臺會被引擎編譯成規(guī)則文件。業(yè)務(wù)團隊非常喜歡這種方式因為它和Excel篩選的操作習(xí)慣一致。但決策表不擅長的是處理復(fù)雜邏輯組合比如多表關(guān)聯(lián)判斷還是老老實實用規(guī)則文件更穩(wěn)妥。5. 從搭建到跑通第一次請求集成流程和關(guān)鍵步驟這章直接上實操。我用JavaKotlin混合的微服務(wù)項目環(huán)境來演示不過Drule2.0本身也提供了其他語言的客戶端思路是一樣的。建議先在一個干凈的Spring Boot工程里跑通最小鏈路再對接現(xiàn)有業(yè)務(wù)。5.1 工程依賴與初始化項目構(gòu)建工具如果是Maven第一個動作是引入Drule2.0的客戶端依賴以及對應(yīng)的規(guī)則包解析器。依賴配置的具體groupId和版本號跟隨你的發(fā)行版走公司內(nèi)部如果使用私有倉庫以私服坐標為準。引入依賴后建立一個配置類把規(guī)則集發(fā)布到本地緩存的路徑配好。Configuration public class DruleConfig { Bean public RuleEngineService ruleEngineService() { RuleEngineOptions options RuleEngineOptions.builder() .ruleBasePath(/opt/rules) .enableCompileCache(true) .build(); return new RuleEngineService(options); } }這里面的關(guān)鍵點是ruleBasePath指向存放規(guī)則文件或發(fā)布包的目錄。Drule2.0啟動時會掃描這個目錄下的規(guī)則包并預(yù)編譯所以規(guī)則文件的改動雖然可以不重啟服務(wù)但發(fā)布到該目錄的時機需要和你的文件同步更新機制配合好。5.2 創(chuàng)建無狀態(tài)會話并執(zhí)行一次決策首次跑通最推薦的方式是寫一個單元測試直接創(chuàng)建會話、插入事實、觸發(fā)執(zhí)行、斷言結(jié)果。Test void testHighAmountOrderShouldBeIntercepted() { RuleEngineService service ruleEngineService(); RuleSession session service.newSession(risk_control_rule_set); OrderInfo order new OrderInfo(); order.setAmount(80000); order.setChannel(ONLINE); session.insert(order); session.fireAllRules(); assertTrue(order.isIntercept()); assertEquals(AMOUNT_HIGH, order.getReasonCode()); }分步驟解釋newSession(risk_control_rule_set)根據(jù)規(guī)則集名稱創(chuàng)建一個無狀態(tài)會話。session.insert(order)把訂單對象當(dāng)作事實插入工作內(nèi)存。session.fireAllRules()執(zhí)行所有匹配規(guī)則的激活項。動作區(qū)通過order.setIntercept(true)直接修改了傳入對象。由于Java對象引用傳遞主線程的order對象在fire之后已經(jīng)發(fā)生了變化所以后面可以直接斷言。這是最簡單也最穩(wěn)妥的使用方式。事實對象會被直接修改因此要特別注意不要在同一個請求里對同一個對象開多個會話操作否則可能出現(xiàn)并發(fā)覆蓋。5.3 創(chuàng)建有狀態(tài)會話并分階段觸發(fā)有狀態(tài)會話適合依賴“上一次規(guī)則執(zhí)行結(jié)果”的場景。比如先走一次反欺詐校驗結(jié)果沒問題再走額度審批。示例RuleSession session service.newSession(credit_flow_rule_set); OrderInfo order new OrderInfo(); order.setAmount(30000); UserProfile profile new UserProfile(); profile.setRiskLevel(MEDIUM); session.insert(order); session.fireAllRules(); session.insert(profile); session.fireAllRules(); OrderDecision decision session.getGlobal(decision);有狀態(tài)會話持有了工作內(nèi)存中的事實所以能在多個階段之間保留狀態(tài)。它的問題是如果整個會話執(zhí)行過程中發(fā)生異常會話里所有中間狀態(tài)都必須主動清理否則下一次復(fù)用就會受影響。上面代碼里沒有做關(guān)閉嚴格的寫法應(yīng)該在finally塊里調(diào)用session.dispose()釋放會話或者干脆每次請求都創(chuàng)建新會話。如果你用的是有狀態(tài)會話并且容器是線程池的一定要想清楚“這個會話是否會被多個線程共用”。無狀態(tài)會話沒有這個問題因為它每次請求都新建并銷毀。5.4 監(jiān)聽器和審計日志配置Drule2.0提供事件監(jiān)聽機制可以在規(guī)則命中前后、議題激活前后掛鉤子實現(xiàn)審計日志收集、指標量統(tǒng)計等功能。實現(xiàn)接口后注冊進會話即可。正常情況下線上會記錄以下內(nèi)容請求唯一ID、進入引擎時間、命中的規(guī)則名列表、每條規(guī)則的動作結(jié)果摘要、總耗時。這些審計數(shù)據(jù)是從“結(jié)果”回溯到“原因”的鑰匙建議一定在早期就配上不然后面出問題排查成本很高。5.5 一個常見的跑通后問題很多第一次接入Drule2.0的團隊會困惑為什么我在配置中心改了規(guī)則測試數(shù)據(jù)也變了但線上執(zhí)行的還是老結(jié)果排查方向通常是緩存沒刷新或者新舊版本規(guī)則集名一樣導(dǎo)致發(fā)布包被覆蓋。Drule2.0的規(guī)則編譯緩存是按規(guī)則集名版本號做的如果你的發(fā)布包沒有顯式改變版本號規(guī)則集會繼續(xù)沿用緩存版本。修改規(guī)則并發(fā)布時建議帶一個遞增版本號同時確認配置中心的緩存刷新策略是否覆蓋了所有實例節(jié)點。6. 幾個容易忽略的配置細節(jié)會話隔離、緩存與規(guī)則數(shù)量控制規(guī)則引擎用久了你會發(fā)現(xiàn)真正讓你頭疼的往往不是規(guī)則寫得不對而是引擎在特定配置下的表現(xiàn)不符合直覺。這一章講三個值得提前做好的配置決策。6.1 會話隔離級別怎么選Drule2.0本身支持多規(guī)則集隔離但同一個規(guī)則集能不能被多個會話安全并發(fā)執(zhí)行取決于會話的隔離級別。默認來說無狀態(tài)會話每次新建相對安全。如果追求性能優(yōu)化想用會話池復(fù)用對象一定要確認會話里是否有全局變量。我見過一個案例規(guī)則動作區(qū)往全局變量里存了用戶ID會話池復(fù)用后第二個用戶跑同一條規(guī)則時讀到的全局變量還是第一個用戶的ID直接導(dǎo)致風(fēng)控規(guī)則誤判。后來我們把全局變量的使用全部禁止改為通過事實對象的字段傳遞才徹底解決。全局變量能不用就不用這是我在Drule2.0實戰(zhàn)里學(xué)到的第一課。6.2 編譯緩存的正確打開方式規(guī)則文件發(fā)布后第一次被請求時需要編譯編譯耗時可能到幾百毫秒甚至更多。如果希望冷啟動也體驗良好可以開啟異步預(yù)編譯。Drule2.0支持在規(guī)則集發(fā)布時主動觸發(fā)一次編譯把產(chǎn)物放入本地緩存目錄。配置緩存時要注意清理策略長期運行的服務(wù)如果規(guī)則包版本頻繁升級本地緩存會留下大量歷史版本的編譯產(chǎn)物占用磁盤空間。建議文件保留數(shù)量和保留時間都做一個明確限制。6.3 規(guī)則數(shù)量多少算太多社區(qū)里總有聲音問“Drule2.0能支撐多少條規(guī)則”我個人的經(jīng)驗是單規(guī)則集內(nèi)規(guī)則數(shù)量控制在幾百條級別是完全沒有問題的引擎內(nèi)部的索引機制能支持相對可觀的規(guī)則量。真正帶來性能麻煩的是“規(guī)則之間有大量交叉引用且觸發(fā)鏈較長”的情況并不是規(guī)則條數(shù)本身。打個比方一萬條彼此獨立的規(guī)則就像一萬個獨立的檢查關(guān)卡跑完也就挨個過一遍但十條互相觸發(fā)的規(guī)則可能形成指數(shù)級循環(huán)把引擎卡死。所以做規(guī)則架構(gòu)設(shè)計時與其糾結(jié)條數(shù)不如把每一條規(guī)則的邊界劃清楚盡量減少規(guī)則之間的隱式依賴。7. 生產(chǎn)環(huán)境踩坑實錄四類高頻問題的完整排查鏈路這章寫的都是我親眼見過甚至親手踩過的坑每個項目的背景細節(jié)都做了脫敏處理但排查鏈路是完整的。希望你看完能少走一半彎路。7.1 規(guī)則“命中”了但動作沒生效現(xiàn)象測試環(huán)境規(guī)則跑得好好的上線后日志里能看到命中的規(guī)則名但訂單并沒有被攔截結(jié)果值也沒有按預(yù)期改寫。排查鏈路首先檢查動作區(qū)是否加了對字段非空的約束。我們遇到過的事實是動作區(qū)執(zhí)行了order.setResult(REJECT)但后面的另一個動作分支又把result覆蓋成了空值。打開完整審計日志看動作區(qū)代碼塊的執(zhí)行順序。因為同一組事實同時命中多條規(guī)則時執(zhí)行順序由優(yōu)先級決定如果你在低優(yōu)先級規(guī)則里做了覆蓋高優(yōu)先級規(guī)則的結(jié)果就會被沖掉。檢查規(guī)則文件里是否有多個同名規(guī)則。同名沖突在發(fā)布時可能被攔截但舊版本規(guī)則集如果還殘留在緩存里新規(guī)則命中后動作可能被舊規(guī)則的后續(xù)執(zhí)行覆蓋。最后結(jié)論是這個場景本質(zhì)是優(yōu)先級設(shè)計不合理多條規(guī)則共享同一個輸出字段卻沒有約定唯一最終寫者。修復(fù)方案是調(diào)整優(yōu)先級并增加字段寫入前的前置校驗同時在測試環(huán)境增加了一個“同一字段多次寫”的靜態(tài)掃描。7.2 有狀態(tài)會話復(fù)用時發(fā)生的用戶數(shù)據(jù)串號現(xiàn)象兩個用戶并發(fā)請求A用戶跑到某一步時突然出現(xiàn)B用戶的用戶名和訂單金額被錯誤地打進了審計日志。排查鏈路第一反應(yīng)懷疑緩存鍵設(shè)置錯了。查完緩存沒問題但發(fā)現(xiàn)服務(wù)里復(fù)用了同一個規(guī)則會話對象。查看會話創(chuàng)建代碼發(fā)現(xiàn)為了性能優(yōu)化之前人把newSession()結(jié)果放進了本地線程池的ThreadLocal里期望同一線程復(fù)用。問題是ThreadLocal并不能保證同一個用戶的請求始終落在同一個線程。于是出現(xiàn)了A用戶的會話事實還沒清空B用戶的請求就插入到同一會話的情況。臨時方案是調(diào)高會話對象的使用周期把它從請求級改成業(yè)務(wù)級終態(tài)方案是把有狀態(tài)會話改成無狀態(tài)會話不保留跨請求狀態(tài)。這是有狀態(tài)會話最典型的坑一旦出現(xiàn)數(shù)據(jù)串號后果比規(guī)則不生效更嚴重。我的建議是除非業(yè)務(wù)有強需求否則不要為了解決性能問題去復(fù)用會話性能和正確性之間永遠要優(yōu)先正確性。7.3 時間比較出現(xiàn)跨天差異現(xiàn)象一條“超過當(dāng)天18點不做自動審批”的規(guī)則晚上八點應(yīng)該攔截但實際沒有攔截。排查鏈路先檢查規(guī)則條件里的時間字段類型。發(fā)現(xiàn)規(guī)則寫的是currentTime 18:00:00字符串直接比較。不同規(guī)則節(jié)點所在服務(wù)器的時區(qū)一致但字符串格式在進入規(guī)則引擎前被某個環(huán)節(jié)轉(zhuǎn)換成了帶時區(qū)的日期時間導(dǎo)致比較結(jié)果和預(yù)期不符合。修復(fù)方式是把時間字段統(tǒng)一轉(zhuǎn)成時間戳再比較同時在前置接口層把日期時間標準化規(guī)則文件里禁止直接比較日期字符串。這個問題同時提醒我們規(guī)則引擎的匹配結(jié)果嚴重依賴事實對象的值因此“進入引擎前的事實清洗”要和“規(guī)則條件設(shè)計”放在一起考慮。字段時區(qū)不統(tǒng)一、格式不統(tǒng)一的臟數(shù)據(jù)進入引擎后規(guī)則寫得再對也可能得到錯結(jié)果。7.4 規(guī)則循環(huán)導(dǎo)致引擎卡死現(xiàn)象某個訂單觸發(fā)了某條規(guī)則后進程CPU飆升請求一直不返回直到超時。排查鏈路查看引擎日志發(fā)現(xiàn)同一個規(guī)則名在短時間內(nèi)被激活了上百次。打開該規(guī)則的動作區(qū)發(fā)現(xiàn)它修改了條件區(qū)依賴的一個字段條件滿足后再次激活形成了自觸發(fā)循環(huán)。查看規(guī)則文件歷史這個規(guī)則原本是修改另一個輔助字段的后來一次重構(gòu)把賦值對象改錯了指向了條件區(qū)的判斷字段。修復(fù)方向是把動作區(qū)和條件區(qū)完全解耦明確哪些字段是“輸入字段”哪些字段是“輸出字段”并用規(guī)則文件注釋標明。循環(huán)觸發(fā)看起來很嚇人但其實規(guī)則引擎本身有防護機制如果你的版本沒有自動打開循環(huán)保護建議在配置中心里打開。同時給規(guī)則集設(shè)置合理的執(zhí)行超時時間就算真出現(xiàn)循環(huán)也能保證請求快速失敗而不是拖垮整個服務(wù)。8. 規(guī)則引擎上線前的檢查清單從測試到灰度最后這部分不是總結(jié)而是我們上線前用的內(nèi)部清單你完全可以抄走做二次確認。規(guī)則編寫階段每條規(guī)則是否有清晰、唯一的命名說明字段里是否寫了業(yè)務(wù)含義。條件區(qū)是否有可以提前合并的模式減少無意義的重復(fù)匹配。動作區(qū)是否直接或間接修改了條件區(qū)依賴的字段如有是否顯式設(shè)計過循環(huán)策略。輸入字段的數(shù)據(jù)類型是否統(tǒng)一字符串格式是否滿足規(guī)則條件的格式要求。測試階段是否準備了最小正向用例、最小反向用例和邊界值用例。是否測試了字段為空、字段類型異常、對象為null的場景。是否驗證了規(guī)則優(yōu)先級與你預(yù)期一致而不是僅靠“跑通得到正確結(jié)果”來推斷。是否在新規(guī)則集發(fā)布時對舊規(guī)則集做了回歸對比。發(fā)布與灰度階段規(guī)則集版本號是否遞增。是否先在一臺機器或少量流量上灰度。是否配置了規(guī)則執(zhí)行的監(jiān)控面板至少能看到命中率、平均耗時、異常規(guī)則名。是否部署了規(guī)則快速回滾能力?；貪L不只是把規(guī)則集降級還要確認本地編譯緩存的清理。從運維角度我還建議給規(guī)則引擎單獨設(shè)置性能監(jiān)控指標不要和應(yīng)用主流程的指標混在一起。因為規(guī)則引擎的耗時波動往往能告訴你業(yè)務(wù)規(guī)則最近是不是出了變化把它獨立出來定位問題會快很多。我個人在實際操作中的一個體會是Drule2.0本來就可以成為業(yè)務(wù)和工程之間的一層“通用語言”。讓業(yè)務(wù)方用JSON格式維護基礎(chǔ)規(guī)則讓工程師把需要復(fù)雜邏輯的規(guī)則收口成自定義函數(shù)兩者結(jié)合規(guī)則引擎在團隊里才能真正用起來而不是變成一個誰都敬而遠之的黑盒。希望這份偏實戰(zhàn)的梳理能幫你省下我當(dāng)初填坑的那些時間。