“ruflo”這個(gè)名字第一次出現(xiàn)在我項(xiàng)目文檔里的時(shí)候其實(shí)挺隨意的。當(dāng)時(shí)我正被一堆復(fù)雜的規(guī)則配置搞得頭疼就想做一個(gè)足夠輕、足夠快、能直接嵌進(jìn)現(xiàn)有業(yè)務(wù)系統(tǒng)里的規(guī)則引擎。折騰了大半年代碼寫了刪刪了寫最后沉淀下來一套自認(rèn)為還算趁手的工具名字就叫 ruflo。這篇文章不聊虛的架構(gòu)也不堆概念就實(shí)打?qū)嵉匕裷uflo從設(shè)計(jì)思路到落地部署的關(guān)鍵細(xì)節(jié)拆開講講包括我踩過的坑和一些你可能也會(huì)遇見的頭疼問題。1. 為什么是ruflo從一個(gè)“被規(guī)則逼瘋”的項(xiàng)目說起1.1 核心需求與定位先說清楚ruflo解決什么問題。在很多后臺(tái)系統(tǒng)里業(yè)務(wù)邏輯并不是鐵板一塊它經(jīng)常變。比如促銷活動(dòng)的滿減規(guī)則、風(fēng)控系統(tǒng)的攔截策略、審批流程的節(jié)點(diǎn)判斷今天還是“滿300減50”明天就可能變成“會(huì)員專享滿200減30再疊加優(yōu)惠券”。如果這些邏輯全都硬編碼在Java或者Go代碼里每次改需求都要走一遍發(fā)布流程光等發(fā)版可能就要半天。ruflo的定位非常明確一個(gè)輕量級(jí)的、可直接嵌入業(yè)務(wù)代碼的規(guī)則流程引擎。它讓你把“可變的那部分決策邏輯”從代碼里抽出來用一套簡(jiǎn)單的描述文件去表達(dá)然后ruflo負(fù)責(zé)解析、加載、執(zhí)行并把結(jié)果返回給你的業(yè)務(wù)系統(tǒng)。本質(zhì)上它干的活就是把“規(guī)則”和“業(yè)務(wù)”解耦。1.2 為什么不用Drools等重型框架很多人一聽到規(guī)則引擎第一反應(yīng)就是Drools。確實(shí)Drools功能非常強(qiáng)大有完整的BRMS生態(tài)有GUI工作臺(tái)有復(fù)雜的推理能力。但用下來你會(huì)發(fā)現(xiàn)在小團(tuán)隊(duì)、輕業(yè)務(wù)的場(chǎng)景里它有些“殺雞用牛刀”。我記得第一次給一個(gè)中等復(fù)雜度的營(yíng)銷系統(tǒng)接Drools的時(shí)候光把規(guī)則包打出來就費(fèi)了半天勁然后又是一堆KIE Base的配置團(tuán)隊(duì)里的新同學(xué)光理解Session和Fact的概念就花了一個(gè)星期。提示Drools適合那種規(guī)則極度復(fù)雜、需要規(guī)則專家參與建模、甚至需要?jiǎng)討B(tài)熱更新規(guī)則的超大型系統(tǒng)。如果你的項(xiàng)目只有十幾條、幾十條規(guī)則團(tuán)隊(duì)也不養(yǎng)專門的規(guī)則工程師那引入它大概率是給自己找麻煩。ruflo的設(shè)計(jì)理念恰恰是反過來的“夠用就好別端著”。它沒有復(fù)雜的推理機(jī)也不需要你理解一堆抽象概念。你只需要知道三個(gè)東西Flow流程、Node節(jié)點(diǎn)、Action動(dòng)作。一個(gè)Flow就是一條或一組規(guī)則的集合Node是流程中的一個(gè)判斷點(diǎn)Action是判斷通過后要執(zhí)行的邏輯。就這么簡(jiǎn)單。1.3 適合誰來用如果你符合下面這些描述ruflo可能會(huì)幫上大忙后端開發(fā)為主不想為了幾條規(guī)則額外部署一個(gè)獨(dú)立的規(guī)則服務(wù)。產(chǎn)品經(jīng)理經(jīng)常改活動(dòng)規(guī)則你想把改規(guī)則的工作“移交”給運(yùn)營(yíng)或產(chǎn)品自己操作前提是你做了簡(jiǎn)單的頁(yè)面或配置文件下發(fā)。系統(tǒng)里有一部分多分支的判斷邏輯用if else寫起來實(shí)在太丑維護(hù)成本高想換成聲明式的配置。你需要一個(gè)輕量級(jí)的框架內(nèi)核支持二次開發(fā)又不是特別依賴社區(qū)生態(tài)。2. ruflo的整體設(shè)計(jì)思路與核心機(jī)制2.1 設(shè)計(jì)的首要原則把“變化”和“穩(wěn)定”分開這是個(gè)老生常談但真正執(zhí)行起來很難的原則。在ruflo里穩(wěn)定的是執(zhí)行引擎也就是加載規(guī)則、遍歷節(jié)點(diǎn)、判斷條件、執(zhí)行動(dòng)作那一套流程變化的是具體的規(guī)則內(nèi)容比如條件參數(shù)、閾值、動(dòng)作類型。這個(gè)劃分直接決定了ruflo的架構(gòu)。它的核心引擎大概分成三個(gè)模塊解析器Parser、調(diào)度器Scheduler、執(zhí)行器Executor。解析器負(fù)責(zé)把規(guī)則描述文件轉(zhuǎn)換成內(nèi)存中的節(jié)點(diǎn)樹數(shù)據(jù)調(diào)度器負(fù)責(zé)決定下一步該走到哪個(gè)節(jié)點(diǎn)執(zhí)行器負(fù)責(zé)真正跑Action邏輯比如調(diào)用一個(gè)HTTP接口、讀寫一次數(shù)據(jù)庫(kù)、或者更新一個(gè)變量值。2.2 規(guī)則描述文件怎么設(shè)計(jì)第一版ruflo我用的是JSON格式來描述規(guī)則。JSON的好處是通用生態(tài)好很多語言都有現(xiàn)成的庫(kù)。但實(shí)際跑了一陣子之后發(fā)現(xiàn)對(duì)于稍微復(fù)雜一點(diǎn)的條件表達(dá)式JSON寫起來非常難受。比如你要表達(dá)一個(gè)“用戶是VIP并且訂單金額大于500或者用戶是體驗(yàn)官”這樣的邏輯用JSON表示會(huì)產(chǎn)生層層嵌套的樹狀結(jié)構(gòu)可讀性很差。后來我改成了一種自創(chuàng)的輕量表達(dá)式語法核心邏輯就是“節(jié)點(diǎn)條件動(dòng)作”三段式。一個(gè)最簡(jiǎn)單的Flow長(zhǎng)這樣flow: id: vip_rule start: check_vip nodes: - id: check_vip type: condition expression: ${user.level VIP order.amount 500} true_next: grant_discount false_next: reject - id: grant_discount type: action action: apply_discount params: rate: 0.8 - id: reject type: action action: reject_order params: reason: not_vip用YAML格式描述靠縮進(jìn)和短橫線來表達(dá)層級(jí)關(guān)系人眼掃一遍就能看懂。更重要的是運(yùn)營(yíng)或者產(chǎn)品同學(xué)稍微培訓(xùn)一下也能照著文檔改規(guī)則而不像JSON樹那樣容易把括號(hào)配錯(cuò)。2.3 核心執(zhí)行機(jī)制節(jié)點(diǎn)驅(qū)動(dòng)ruflo的執(zhí)行機(jī)制是“節(jié)點(diǎn)驅(qū)動(dòng)”而不是“組件驅(qū)動(dòng)”。什么意思傳統(tǒng)的業(yè)務(wù)流程引擎比如Activiti強(qiáng)調(diào)的是流程狀態(tài)流轉(zhuǎn)它得管理流程實(shí)例的當(dāng)前狀態(tài)、歷史記錄、待辦任務(wù)運(yùn)維上面向的是“一條流程的生命周期”。ruflo沒那么重它更看重的是“一條數(shù)據(jù)進(jìn)來經(jīng)過哪些節(jié)點(diǎn)判斷最終得到什么結(jié)果”。所以它的執(zhí)行邏輯非常直接從start節(jié)點(diǎn)進(jìn)入遇到condition節(jié)點(diǎn)就算表達(dá)式根據(jù)true/false找對(duì)應(yīng)的下一跳走到action節(jié)點(diǎn)就干活直到遇到end節(jié)點(diǎn)。用個(gè)不太恰當(dāng)?shù)念惐认衤嬂锏臒嵫鹘顷J關(guān)每個(gè)房間可能是個(gè)岔路口也可能是個(gè)BOSS戰(zhàn)最后到了終點(diǎn)就通關(guān)。這個(gè)設(shè)計(jì)有一個(gè)好處性能可控。因?yàn)椴簧婕傲鞒虒?shí)例的持久化和狀態(tài)恢復(fù)ruflo執(zhí)行一條規(guī)則鏈的時(shí)間主要消耗在表達(dá)式求值上。實(shí)測(cè)下來在純內(nèi)存環(huán)境下單條簡(jiǎn)單規(guī)則鏈的執(zhí)行耗時(shí)在微秒級(jí)就算加上數(shù)據(jù)庫(kù)訪問動(dòng)作也就多幾個(gè)毫秒對(duì)于絕大多數(shù)業(yè)務(wù)場(chǎng)景完全夠用。3. 實(shí)操把ruflo集成到真實(shí)項(xiàng)目的完整步驟3.1 環(huán)境準(zhǔn)備與依賴引入我自己的主力語言是Javaruflo最早的版本也是用Java寫的所以這篇文章以Java生態(tài)為例。不要被嚇到核心思路是一樣的。在pom.xml里引入依賴dependency groupIdcom.ruflo/groupId artifactIdruflo-core/artifactId version1.2.0/version /dependency如果你是Gradle項(xiàng)目對(duì)應(yīng)的寫法是implementation com.ruflo:ruflo-core:1.2.0引入依賴之后用一行代碼就可以初始化引擎RuleEngine engine new RuleEngineBuilder() .withResource(classpath:rules.yml) .build();這里有個(gè)小細(xì)節(jié)必須提醒一下withResource支持 classpath、本地文件系統(tǒng)和遠(yuǎn)程URL三種方式。如果是遠(yuǎn)程URLruflo默認(rèn)會(huì)緩存遠(yuǎn)程配置的hash值定期輪詢變更這樣你改完遠(yuǎn)程配置客戶端最多延遲一個(gè)輪詢周期默認(rèn)60秒自動(dòng)加載新規(guī)則不需要重啟應(yīng)用。這個(gè)特性在后續(xù)“動(dòng)態(tài)更新”環(huán)節(jié)簡(jiǎn)直救命。3.2 定義你的第一條規(guī)則鏈我們用一個(gè)非常貼近實(shí)戰(zhàn)的場(chǎng)景來演示電商訂單的優(yōu)惠計(jì)算。假設(shè)業(yè)務(wù)需求是這樣的用戶等級(jí)是VIP且訂單金額滿500元享受85折優(yōu)惠。用戶等級(jí)是普通會(huì)員但有優(yōu)惠券碼享受95折優(yōu)惠。其他情況不優(yōu)惠但訂單金額超過1000元時(shí)會(huì)送一張平臺(tái)優(yōu)惠券。用ruflo來表達(dá)就是這樣的一個(gè)Flowflow: id: discount_calc start: check_vip nodes: - id: check_vip type: condition expression: ${user.level VIP} true_next: check_amount_vip false_next: check_coupon - id: check_amount_vip type: condition expression: ${order.amount 500} true_next: apply_vip_discount false_next: no_discount - id: check_coupon type: condition expression: ${order.couponCode ! null order.couponCode ! } true_next: apply_coupon_discount false_next: check_big_order - id: apply_vip_discount type: action action: applyDiscount params: rate: 0.85 - id: apply_coupon_discount type: action action: applyDiscount params: rate: 0.95 - id: check_big_order type: condition expression: ${order.amount 1000} true_next: send_gift_coupon false_next: no_discount - id: send_gift_coupon type: action action: sendCoupon params: type: platform_gift - id: no_discount type: action action: noop注意看這里處理了一個(gè)邏輯細(xì)節(jié)VIP用戶如果金額不夠會(huì)直接走到no_discount不會(huì)再判斷是否用優(yōu)惠券。這符合常規(guī)的業(yè)務(wù)理解——優(yōu)惠策略互斥只取最高優(yōu)先級(jí)。如果你的業(yè)務(wù)規(guī)則是“優(yōu)惠可疊加”那這個(gè)流程圖就要調(diào)整把check_coupon放到兩個(gè)分支的后面。這個(gè)經(jīng)驗(yàn)很重要規(guī)則引擎不只是把條件翻譯成機(jī)器語言它也是業(yè)務(wù)語義梳理的過程。3.3 在業(yè)務(wù)代碼里執(zhí)行規(guī)則規(guī)則文件有了引擎也有了最激動(dòng)人心的時(shí)刻來了——在代碼里跑起來。執(zhí)行邏輯很簡(jiǎn)單把上下文對(duì)象傳給引擎引擎返回結(jié)果// 構(gòu)建上下文 MapString, Object context new HashMap(); context.put(user, userInfo); // 用戶信息對(duì)象 context.put(order, orderInfo); // 訂單信息對(duì)象 // 執(zhí)行業(yè)務(wù)規(guī)則 RuleResult result engine.execute(discount_calc, context); // 從結(jié)果中提取修改后的數(shù)據(jù) DiscountInfo discountInfo result.getOutput(applyDiscount, DiscountInfo.class); if (discountInfo ! null discountInfo.isApplied()) { // 更新訂單金額 order.setDiscountedAmount(order.getAmount() * discountInfo.getRate()); } // 如果是大單還有贈(zèng)券 if (result.isNodeExecuted(send_gift_coupon)) { couponService.issueGiftCoupon(userInfo, platform_gift); }這里我特別想分享一下RuleResult的設(shè)計(jì)取舍。execute返回的結(jié)果里既有最終的輸出數(shù)據(jù)也有“哪些節(jié)點(diǎn)被實(shí)際執(zhí)行過”的標(biāo)記。為什么要留這個(gè)標(biāo)記因?yàn)樵趯?shí)際業(yè)務(wù)里你不僅關(guān)心規(guī)則跑完的結(jié)果還經(jīng)常需要知道“這條規(guī)則鏈到底走了哪個(gè)分支”這直接影響后續(xù)的業(yè)務(wù)補(bǔ)償邏輯。比如訂單需要記錄優(yōu)惠原因就需要知道是VIP折扣還是優(yōu)惠券折扣。傳統(tǒng)做法是在Action里回寫一個(gè)標(biāo)志位到contextruflo直接把節(jié)點(diǎn)執(zhí)行記錄暴露成API省去了這個(gè)額外的維護(hù)。3.4 接入動(dòng)態(tài)配置中心這才是ruflo作為“靈活工具”的最閃光之處。我們把規(guī)則文件從jar包內(nèi)移到Nacos或Apollo等配置中心然后通過“加載器”讓規(guī)則內(nèi)容動(dòng)起來。ruflo提供的動(dòng)態(tài)加載邏輯其實(shí)不復(fù)雜核心是三個(gè)元素一個(gè)遠(yuǎn)端存儲(chǔ)保存規(guī)則內(nèi)容。一個(gè)輪詢線程定時(shí)拉取遠(yuǎn)端內(nèi)容和本地內(nèi)存中的版本做對(duì)比。一個(gè)原子替換有新版本時(shí)把運(yùn)行中的節(jié)點(diǎn)樹整體原子替換不影響正在執(zhí)行的請(qǐng)求。我實(shí)現(xiàn)了一個(gè)Nacos加載器代碼結(jié)構(gòu)大概是public class NacosRuleLoader implements RuleLoader { private final ConfigService configService; private final String dataId; private final String group; Override public RuleSource load() { String content configService.getConfig(dataId, group, 5000); return new RuleSource(content, VersionUtil.md5(content)); } Override public boolean watch(RuleEngine engine) { configService.addListener(dataId, group, new Listener() { Override public void receiveConfigInfo(String configInfo) { engine.refreshFlow(RuleSource.from(configInfo)); } }); return true; } }接入動(dòng)態(tài)加載之后每次規(guī)則調(diào)整只需要在配置中心的界面里改一段YAML保存幾十秒內(nèi)所有實(shí)例都會(huì)自己熱更新。我試過在生產(chǎn)環(huán)境跑這種模式一次規(guī)則發(fā)布從“提工單改代碼、測(cè)試、走發(fā)布單”變成“配置中心點(diǎn)一下保存鍵”整個(gè)鏈路從小時(shí)級(jí)縮短到秒級(jí)。這個(gè)體驗(yàn)的提升用的時(shí)候才能真切感受到。4. 常見問題與排查技巧實(shí)錄4.1 變量為空導(dǎo)致的表達(dá)式空指針這是所有用規(guī)則引擎的人遇到的第一個(gè)坎。比如上面的表達(dá)式${user.level VIP}如果上下文里壓根沒傳user對(duì)象或者傳了user對(duì)象但level字段是null表達(dá)式直接拋空指針整個(gè)流程啪一聲掛了接口返回500措手不及。我踩了好幾次坑之后才養(yǎng)成一個(gè)強(qiáng)制習(xí)慣所有規(guī)則里的變量在入口處做一次完整校驗(yàn)。ruflo也提供了一個(gè)便捷解法在表達(dá)式引擎里對(duì)空值做短路處理——取屬性時(shí)如果對(duì)象為null返回null而不拋異常然后null做等值判斷就正常走false分支。這樣至少保證流程不崩。不過還是強(qiáng)烈建議在業(yè)務(wù)層把必填參數(shù)校驗(yàn)做在前面。規(guī)則引擎是業(yè)務(wù)判斷的最后一環(huán)不是數(shù)據(jù)校驗(yàn)的第一道防線。4.2 規(guī)則生效了但結(jié)果和預(yù)期不一致比規(guī)則不生效更讓人崩潰的是規(guī)則看起來生效了但結(jié)果跟預(yù)期不一樣。檢查半天發(fā)現(xiàn)原來是緩存問題多個(gè)Flow之間的ID重復(fù)了后加載的把先加載的覆蓋了。排查這個(gè)問題的步驟如下先看是不是規(guī)則內(nèi)容加載錯(cuò)誤。在配置中心或本地文件里搜FlowId確認(rèn)唯一性。再看是不是網(wǎng)關(guān)或緩存層攔截服務(wù)端返回了舊數(shù)據(jù)。最后看引擎日志里輸出的執(zhí)行軌跡把每個(gè)節(jié)點(diǎn)是否命中、變量快照打出來。ruflo提供了一種Debug模式開啟后會(huì)在日志里打印完整的執(zhí)行追蹤信息engine.setDebugMode(true);輸出長(zhǎng)這樣[ruflo] flowdiscount_calc, nodecheck_vip, expruser.level VIP, resulttrue [ruflo] flowdiscount_calc, nodecheck_amount_vip, exprorder.amount 500, resulttrue [ruflo] flowdiscount_calc, nodeapply_vip_discount, actionapplyDiscount, params{rate0.85}看到這個(gè)執(zhí)行軌跡基本一眼就能定位是條件寫錯(cuò)了還是參數(shù)傳錯(cuò)了。這也是ruflo讓我比較得意的地方不像某些黑盒框架出錯(cuò)之后你完全不知道它內(nèi)部發(fā)生了什么。4.3 性能瓶頸在哪里有朋友問過我ruflo扛得住高并發(fā)嗎我的回答是純執(zhí)行部分完全沒問題瓶頸一般出現(xiàn)在“加載規(guī)則”這一步。如果你的規(guī)則存儲(chǔ)在數(shù)據(jù)庫(kù)或配置中心每次業(yè)務(wù)請(qǐng)求都動(dòng)態(tài)加載規(guī)則再執(zhí)行那不僅性能差還很容易把配置中心拖垮。正確姿勢(shì)是啟動(dòng)或更新時(shí)把規(guī)則內(nèi)容加載到內(nèi)存運(yùn)行時(shí)只做讀操作。ruflo的核心引擎完全基于內(nèi)存數(shù)據(jù)結(jié)構(gòu)執(zhí)行不涉及IO所以它的擴(kuò)展能力真正取決于下游動(dòng)作。比如Action里調(diào)用了一個(gè)很慢的HTTP接口那無論規(guī)則引擎多快都白搭。4.4 一個(gè)容易被忽視的文本編碼坑最后分享一個(gè)非常隱蔽、絕對(duì)值得記下來的小問題。有一段時(shí)間產(chǎn)品的某個(gè)活動(dòng)規(guī)則在YAML文件里用了中文條件值比如“用戶偏好: 國(guó)潮風(fēng)”本地測(cè)試一切正常測(cè)試環(huán)境也正常一到生產(chǎn)環(huán)境就死活匹配不上。排查了一下午最后發(fā)現(xiàn)是生產(chǎn)環(huán)境的服務(wù)器默認(rèn)字符集不是UTF-8Java在讀取外部配置文件時(shí)用了平臺(tái)默認(rèn)編碼導(dǎo)致中文變成了亂碼。這個(gè)問題的解決倒是不復(fù)雜在啟動(dòng)參數(shù)里加上-Dfile.encodingUTF-8或者更保險(xiǎn)的做法在加載規(guī)則文件的時(shí)候顯式指定編碼new InputStreamReader(inputStream, StandardCharsets.UTF_8)5. 從使用ruflo到二次開發(fā)定制一個(gè)自己的集成方案5.1 預(yù)留的擴(kuò)展點(diǎn)設(shè)計(jì)ruflo不是一個(gè)封閉的黑盒它在設(shè)計(jì)之初就預(yù)留了兩個(gè)明確的擴(kuò)展點(diǎn)表達(dá)式函數(shù)和自定義Action。表達(dá)式函數(shù)擴(kuò)展可以讓你在規(guī)則里用自定義的判斷邏輯。比如你可以注冊(cè)一個(gè)函數(shù)isWeekend(date)來判斷日期是否是周末然后在規(guī)則表達(dá)式里直接寫${isWeekend(order.orderDate)}。這比硬寫一串日期計(jì)算邏輯要簡(jiǎn)潔得多。自定義Action更直接你只需要實(shí)現(xiàn)Action接口注冊(cè)到引擎里就能在流程文件中通過action字段引用它。public class RiskCheckAction implements Action { Override public ActionResult execute(ActionContext context) { // 你的風(fēng)控邏輯 return ActionResult.success(risk_pass); } }然后在規(guī)則文件的node里這樣引用- id: risk_check type: action action: riskCheck params: strategy: strict5.2 集成到Spring Boot的兩點(diǎn)心得很多人把規(guī)則引擎集成到Spring Boot項(xiàng)目里時(shí)只想到把引擎初始化成Bean卻忽略了兩件更重要的事情。第一件Action里可能需要調(diào)用Spring托管的Service。所以自定義Action的實(shí)例化不能簡(jiǎn)單地new而是要放到Spring容器里比如用Component注解然后在注冊(cè)到引擎時(shí)從容器里取。這樣Action才能正常用Autowired注入業(yè)務(wù)Service。第二件規(guī)則內(nèi)容最好做成可外部化的配置。不要讓規(guī)則文件跟代碼一起打包在jar里而是放到配置中心或獨(dú)立的配置目錄。這樣每次修改規(guī)則時(shí)不必發(fā)版這個(gè)我在前面3.4小節(jié)已經(jīng)詳細(xì)說過了。兩件事配合起來才真正發(fā)揮出規(guī)則引擎的靈活優(yōu)勢(shì)。5.3 二次開發(fā)的路線參考如果你想把ruflo改造成一個(gè)真正屬于自己團(tuán)隊(duì)的工具我建議按下面幾步來演進(jìn)第一版直接使用ruflo-core提供的API規(guī)則文件用git管理改動(dòng)走merge request。這個(gè)階段適合驗(yàn)證規(guī)則引擎在你團(tuán)隊(duì)的業(yè)務(wù)里是否水土不服。第二版接入配置中心規(guī)則可視化編輯配合一個(gè)簡(jiǎn)單的操作后臺(tái)讓運(yùn)營(yíng)同學(xué)直接提交規(guī)則變更。第三版擴(kuò)展表達(dá)式函數(shù)庫(kù)沉淀團(tuán)隊(duì)內(nèi)部常用的業(yè)務(wù)函數(shù)比如“判斷用戶是否在灰度名單”、“計(jì)算商品運(yùn)費(fèi)模板的最終價(jià)格”。第四版把規(guī)則執(zhí)行日志保存下來做規(guī)則命中的后臺(tái)分析和報(bào)表讓每個(gè)業(yè)務(wù)方直觀看到自己的規(guī)則被觸發(fā)了多少次。我個(gè)人在實(shí)際操作中的體會(huì)是階段之間的間隔不要太短。把第一版跑透確認(rèn)它的確能穩(wěn)定扛住線上流量再談可視化后臺(tái)和報(bào)表步子太大反而容易讓團(tuán)隊(duì)失去信心。6. 聊聊“規(guī)則”與“代碼”的邊界用了這么久規(guī)則引擎我越來越覺得它不只是一個(gè)技術(shù)工具更是一個(gè)團(tuán)隊(duì)協(xié)作的邊界梳理器。凡是經(jīng)常變化、需要業(yè)務(wù)人員參與決策的那部分邏輯比如優(yōu)惠計(jì)算、活動(dòng)配置、風(fēng)控閾值都適合剝離出來交給規(guī)則引擎而最終要保證穩(wěn)固的核心業(yè)務(wù)閉環(huán)比如訂單生成、支付流水還是要用嚴(yán)格的代碼來守護(hù)。這不是說代碼比規(guī)則更高級(jí)而是他們各自擅長(zhǎng)不同。代碼擅長(zhǎng)處理穩(wěn)定的、可測(cè)試的、需要強(qiáng)約束的邏輯規(guī)則擅長(zhǎng)處理靈活的、高頻調(diào)整的、允許一定業(yè)務(wù)試錯(cuò)成本的邏輯。把兩者配好比例系統(tǒng)才能又穩(wěn)又靈活。最后再分享一個(gè)小技巧如果你打算在團(tuán)隊(duì)里把規(guī)則引擎用起來不妨從一個(gè)很小的場(chǎng)景切入比如先試試訂單備注里的自動(dòng)分單邏輯三兩天的功夫就能做出一個(gè)Demo。讓團(tuán)隊(duì)成員親眼看到“改配置不用發(fā)版”的酸爽后推廣起來阻力就小多了。我敢說你只要試一次就會(huì)重新審視項(xiàng)目里那些寫得亂七八糟的if else大雜燴。