規則引擎與商業CRM的完美邂逅：將智能決策融入商業擴展
一、背景介紹
商業CRM系統的商機模塊業務復雜、場景繁多、規則調整頻繁，商機流轉效率一定程度決定了銷售開單的效率。如何高效配合產品側完成業務規則調整，商機流轉經歷了硬編碼到半配置化的優化升級，過程中遇到了一些問題，也總結了一些經驗，今天來和大家掰開揉碎了講一講這其中遇到的問題和解決方案。
1.1 什么是CRM
先看一下CRM的官方定義：
CRM(Customer Relationship Management)：客戶關系管理，是指企業為提高核心競爭力，利用相應的信息技術以及互聯網技術協調企業與顧客間在銷售、營銷和服務上的交互，從而提升其管理效率，向客戶提供創新式的個性化的客戶交互和服務的過程。
其最終目標是：吸引新客戶、保留老客戶以及將已有客戶轉為忠實客戶，增加市場。
可以這么簡單的理解，CRM的核心價值就是：將潛在客戶更高效的轉化為客戶，將客戶更高效的轉化為長期客戶。
圖片
介紹完什么是CRM，那CRM系統就很容易理解了，用于支撐企業進行客戶關系管理的系統，就可以稱作CRM系統。這個定義比較寬泛，每個公司對CRM中功能邊界也不完全一樣，大家初步理解這個概念就行。比如轉轉商業CRM系統，主要包含：商機管理、客戶管理、銷售/運營人員管理、業績管理、效率監控等功能模塊。
1.2 商機業務介紹
要想把潛在客戶變成客戶，就需要銷售人員進行跟進，對潛在客戶進行產品的售賣，用戶購買產品后，變成客戶。這個潛在客戶，我們稱作“商機”，也就是一次成單的機會，有的CRM系統中，也稱為“線索”。
上圖是潛在用戶到客戶簡單的流轉圖
從商機生成到最終成單，銷售跟進過程中，涉及一些概念，比如商機池（公海池、私海池）、商機狀態/來源/類型/等級、商機的流轉等。
商機池：各種商機的集合。公海池：該集合里的商機當前不歸屬于任何銷售，所有銷售均可以看到公海里的商機。私海池：綁定了特定銷售的商機集合，比如銷售A的商機私海池，只有銷售A可以看到和跟進，其他銷售不可見、不可跟進。商機流轉：商機在跟進過程中，被不同的銷售跟進，狀態發生不同的變化。流轉規則：流轉過程中會有各種各樣的業務規則限制，比如銷售最多可以認領100條商機、負責手機類目的銷售不能認領電腦類目的商機、銷售剛放棄的商機不能立馬重新認領、單位時間內不進行電話溝通的商機將流出銷售私海等等。
二、商機流轉遇到的問題
2.1 商機流轉業務特點
這里舉一個例子來說明商機的流轉，業務背景：商機對應用戶主營類目為手機，銷售A、B負責手機類目，銷售C負責電腦類目，銷售D也負責手機類目。
圖片
這是一個簡單的流程，實際流程比這個復雜。從這個簡易的流程介紹中，可以窺見部分商機流轉模塊的業務特點，總結起來有三點：
- 狀態的多樣性
圖片
- 狀態間轉換場景繁多
圖片
- 流轉規則復雜多變
圖片
2.2 商機流轉業務痛點
之前商業CRM中關于流轉的處理邏輯，好多都是硬編碼，舉個銷售認領某條商機的例子：
//狀態校驗
if(checkClueStatus(param)){
return “狀態不合法”;
}
//綁定人校驗
if(checkClueBindUser(param)){
return “上一個綁定人不可以為···”;
}
//私海容量校驗
if(checkPrivateClueCount(param)){
return “私海庫已滿，無法操作··”;
}
//類目校驗
if(checkClueCate(param)){
return “類目不匹配，無法操作··”;
}
//任務是否完成校驗
if(checkClueTaskFinished(param)){
return “任務未完成，無法操作··”;
} ······
bind(param);//綁定操作
log();//日志記錄操作從代碼中可以看出，銷售從公海進行認領一條自己覺得有價值的商機時，并不是直接就讓該商機流入到該銷售私海中，這個過程會有各種規則的業務校驗。
2.2.1 痛點
- 硬編碼實現的業務，維護成本大；
- 業務規則經常調整，難以應對變化，產研配合效率低；
- 業務規則調整需要配合修改代碼，重新上線后生效。
2.2.2 訴求
- 規則抽取成可配置項，調整方便；
- 校驗相關閾值，可隨時動態調整，無需上線；
- 代碼優雅度適當提高。
帶著我們的痛點和訴求，接下來看看可以找到什么樣的解決方案。然后我們進入了調研階段，發現對于這種策略比較密集的業務，規則引擎是一個可參考方向，然后就開始了解規則引擎相關細節，了解完后，發現和業務問題匹配度很高。接下來，先介紹一下規則引擎相關的基本知識。
三、什么是規則引擎
3.1 什么是規則
規則就是：條件 --> 推理 --> 結果。一個完整的規則是需要這三部分元素的，平時大家討論規則，某些時候只是在討論第一部分的條件，比如學校的行為規范，咱們國家的各種法律條文，可能關注的部分是需要滿足什么條件（不能做什么什么），后面的推理和結果省去了。比如學生準則里的不辱罵同學，這是一個條件，那怎么算辱罵呢，這是推理過程，辱罵后會發生什么呢，會受到老師批評，這是結果。
那什么是推理引擎和規則引擎呢？
- 推理引擎：如果由程序來處理推理過程，那么這個程序就叫做推理機/推理引擎。
- 規則引擎：基于規則的推理機易于理解、易于獲取、易于管理，被廣泛采用。這種推理引擎被稱為“規則引擎”。是一種嵌入在應用程序中的組件，實現了將業務決策從應用程序代碼中分離出來，并使用預定義的語義模塊編寫業務決策。接受數據輸入，解釋業務規則，并根據業務規則做出業務決策。
3.2 推理引擎原理
圖片
- 模式匹配器決定選擇執行哪個規則，何時執行規則；
- 議程管理模式匹配器挑選出來的規則的執行次序；
- 執行引擎負責執行規則和其他動作。
推理引擎通過決定哪些規則滿足事實或目標，并授予規則優先級，滿足事實或目標的規則被加入議程，具體過程：
- 將初始數據（fact）輸入至工作內存(Working Memory)。
- 使用Pattern Matcher將規則庫(Rules repository)的規則（rule）和數據（fact）比較。
- 如果執行規則存在沖突（conflict），即同時激活了多個規則，將沖突的規則放入沖突集合。
- 解決沖突，將激活的規則按順序放入Agenda。
- 執行Agenda中的規則。
- 重復步驟2至5，直到執行完畢Agenda中的所有規則。
推理方式分為正向推理和反向推理
- 正向推理（演繹法）：事實驅動，正向推理，直到無事實可用或者得出結論為止；
- 反向推理（歸納法）：目標驅動，提出假設，尋找支持該假設的證據，如果能找到證明，結論正確，如果不能，換假設繼續。
常見的模式匹配算法有Rete,LFA,TREAI,LEAPS。Rete算法是目前效率最高的一個演繹法推理算法，許多規則引擎都是基于Rete算法來進行推理計算的。
3.3 Rete算法
3.3.1 Rete算法簡介
- Rete在拉丁語中是“net”，有網絡的意思。Rete算法由Carnegie Mellon University的Dr Charles L. Forgy設計發明，是一個用來實現產生式規則系統（production/inference）的高效模式匹配算法。
- RETE算法可以分為兩部分：規則編譯（rule compilation）和運行時執行（runtime execution）。
- 規則編譯：是指根據規則集生成推理網絡的過程。
- 運行時執行：指將數據送入推理網絡進行篩選的過程。
- 相關概念：
- 事實（fact）：對象之間及對象屬性之間的關系
- 規則（rule）：是由條件和結論構成的推理語句，一般表示為if…Then。一個規則的if部分稱為LHS（left-hand-side），then部分稱為RHS（right hand side）。
- 模式（module）：就是指IF語句的條件。這里IF條件可能是有幾個更小的條件組成的大條件。模式就是指的不能在繼續分割下去的最小的原子條件。
3.3.2 Rete算法原理
圖片
這是Rete算法的原理圖，Rete算法涉及兩種網絡和6種不同作用的節點。
- 網絡節點：Type Node、Select Node、Join Node、Teminal Node、Alpha Memory、Beta Memory
- alpha網絡：過濾working memory，找出符合規則中每一個模式的集合，生成alpha memory（滿足該模式的集合）。
- Beta網絡：有兩種類型的節點Beta Memory和Join Node。前者主要存儲Join完成后的集合。后者包含兩個輸入口，分別輸入需要匹配的兩個集合，由Join節點做合并工作傳輸給下一個節點。
3.3.2.1 Rete推理網絡生成過程
圖片
- 創建root節點（根節點），推理網絡的入口。
- 拿到規則1，從規則1中取出模式1（模式就是最小的原子條件，所以規則模式的關系是1：n）。
a) 檢查模式1中的參數類型，如果是新類型，添加一個類型節點。
b) 檢查模式1對應的Alpha節點是否存在，如果存在記錄下節點的位置；如果沒有，將模式1作為一個Alpha節點加入到網絡中。同時根據Alpha節點建立Alpah內存表。
c) 重復b，直到處理完所有模式。
d) 組合Beta節點：Beta(2)左輸入節點為Alpha(1)，右輸入節點為Alpha(2)；Beta(i)左輸入節點是Beta(i-1),右輸入節點為Alpha(i)，并將兩個父節點的內存表內聯成為自己的內存表。
e) 重復d，直到所有Beta節點處理完畢。
f) 將動作Then部分封裝成最后節點做為Beta（n）。
- 重復2，直到所有規則處理完畢。
3.3.2.2 Rete匹配過程
圖片
- 導入需要處理的事實到facts集合中。
- 如果facts不為空，選擇一個fact進行處理。否則停止匹配過程。
- 選擇alpha網的第一個節點運行（建立網絡的時候設定的），通過該節點則進入alpha網的下一個節點，直到進入alpha memory。否則跳轉到下一條判斷路徑。
- 將alpha memory的結果加入到beta memory中，如果不為Terminal節點，則檢測另一個輸入集合中是否存在滿足條件的事實，滿足則執行join，進入到下一個beta memory重復執行3。若另一個輸入集合無滿足條件的事實，返回到2。如果該節點為Terminal節點，執行ACT并添加到facts中。
3.3.3 Rete算法實例
上面介紹的這些都偏理論化，可能有一點不太容易理解，沒關系，接下來咱們用一個具體的例子，看看Rete算法到底是如何運行的。咱們依然以這個選拔籃球苗子的例子來說明。
圖片
- 首先看下對應的網絡圖
圖片
- Rete匹配過程
- 匹配過程詳解
A節點：拿StudentFact的年級數值進行年級匹配，如果年級符合條件，則把該StudentFact的引用記錄到A節點的alpha內存區中，退出年級匹配。
B節點：拿StudentFact的性別內容進行性別匹配，如果性別符合條件，則把該StudentFact的引用記錄到B節點的alpha內存區中，然后找到B節點左引用的Beta節點，也就是C節點。
C節點：C節點找到自己的左引用也就是A節點，看看A節點的alpha內存區中是否存放了StudentFact的引用，如果存放，說明年級和性別兩個條件都符合，則在C節點的Beta內存區中存放StudentFact的引用，退出性別匹配。
D節點：拿StudentFact的年齡數值進行年齡條件匹配，如果年齡符合條件，則把該StudentFact的引用記錄到D節點的alpha的內存區中，然后找到D節點的左引用的Beta節點，也就是E節點。
E節點：E節點找到自己的左引用也就是C節點，看看C節點的Beta內存區中是否存放了StudentFact的引用，如果存放，說明年級，性別，年齡三個條件符合，則在E節點的Beta內存區中存放StudentFact的引用，退出年齡匹配。
F節點：拿StudentFact的身體數值進行身體條件匹配，如果身體條件符合，則把該StudentFact的引用記錄到D節點的alpha的內存區中，然后找到F節點的左引用的Beta節點，也就是G節點。
G節點：G節點找到自己的左引用也就是E節點，看看E節點的Beta內存區中是否存放了StudentFact的引用，如果存放，說明年級，性別，年齡，身體四個條件符合，則在G節點的Beta內存區中存放StudentFact的引用，退出身體匹配。
H節點：拿StudentFact的身高數值進行身高條件匹配，如果身高條件符合，則把該StudentFact的引用記錄到H節點的alpha的內存區中，然后找到H節點的左引用的Beta節點，也就是I節點。
I節點：I節點找到自己的左引用也就是G節點，看看G節點的Beta內存區中是否存放了StudentFact的引用，如果存放了，說明年級，性別，年齡，身體，身高五個條件都符合，則在I節點的Beta內存區中存放StudentFact引用。同時說明該StudentFact對象匹配了該規則，形成一個議程，加入到沖突區，執行該條件的結果部分：該學生是一個籃球苗子。
3.3.4 Rete算法的優點
- 可共享node和memory，提高效率；
- memory存儲中間結果，空間換時間，避免重復計算；
- Rete 匹配速度與規則數目無直接關系，因為fact只有滿足本節點才會繼續向下沿網絡傳遞。
3.3.5 Rete算法的缺點
規則的條件與facts的數目如果過大，對應memory會指數級升高，極端情況下會耗盡系統資源。
3.3.6 Rete算法使用建議
- 容易變化的規則盡量置后匹配，可以減少規則的變化帶來規則庫的變化。
- 約束性較為通用或較強的模式盡量置前匹配，可以避免不必要的匹配。
- 針對 Rete 算法內存開銷大和facts增加刪除影響效率的問題，技術上應該在 AlphaMemory 和 BetaMemory 中，只存儲指向內存的指針，并對指針建里索引（可用 hash 表或者非平衡二叉樹）。
- Rete 算法 JoinNode 可以擴展為 AndJoinNode 和 OrJoinNode，兩種節點可以再進行組合。
看完這個匹配的過程，相信大家對規則引擎中常用的Rete算法有了一定的了解?；氐揭巹t引擎，那為啥用規則引擎呢，也就是它有何優勢，以及有哪些適用的場景呢？
3.4 規則引擎優勢
- 高靈活性：規則保存在知識庫中，規則變動可以輕易做出修改。
- 容易掌控：規則比過程代碼更易于理解，因此可以有效地來彌補業務人員和開發人員之間的溝通問題。
- 降低復雜度：在程序中編寫大量的判斷條件，很可能是會造成一場噩夢。使用規則引擎卻能夠通過一致的表示形式，更好的處理日益復雜的業務邏輯。開發人員也可以更關注邏輯處理，而無需過多關注邏輯判斷。
- 可重用性：規則集中管理，可提高業務的規則的可重用性。而且，傳統的代碼程序通常會添加不必要的變數，很難進行重復利用。
- 規則外部化：即有利于規則知識的復用，也可避免改變規則時帶來的代碼變更問題。
3.5 規則引擎使用場景
一般多用于規則較多且規則調整頻繁的業務場景，比如：積分規則、計費系統、信用風險評估、監控告警、工作流系統。
3.6 規則引擎的分類
網上有兩種分類方式，這里我列舉出來，供大家了解。
- 基于實現方式
- 基于完成度和功能配置
圖片
四、商機流轉問題解決方案
了解了上面這些業務背景以及遇到的問題，也熟悉了規則引擎的理論知識，現在需要制定具體的解決方案了，我們怎么做的呢？市面有各種各樣的規則引擎，先進行技術選型，這里列舉下當前主流規則引擎優缺點。
圖片
通過各方面綜合評估，重點放到了Drools和easyRule兩者，且easyRule最終勝出。
4.1 Drools和easyRule對比
圖片
確定了要使用easyRule就得知道easyRule如何使用的，先介紹下其相關概念和使用方法。
4.2 easyRule插件介紹
4.2.1 規則說明
- name：規則命名空間中的唯一規則名稱
- description：規則的簡要描述
- priority：規則的優先級
- facts：觸發規則時的一組已知事實
- conditions：在給定一些事實的情況下，為了應用該規則，需要滿足的一組條件
- actions：滿足條件時要執行的一組操作(可能會添加/刪除/修改事實)
4.2.2 規則定義方式
- 通過在POJO上添加注解來聲明
- 通過RuleBuilder API編程
4.2.3 組合規則用法
Easy Rules提供了3種CompositeRule的實現。
- UnitRuleGroup：要么應用所有規則，要么不應用任何規則。--要么全用要么不用
- ActivationRuleGroup：激活規則組觸發第一個適用規則并忽略組中的其他規則。--首個選用
- ConditionalRuleGroup：條件規則組將具有最高優先級的規則作為條件，如果具有最高優先級的規則的計算結果為true，那么將觸發其余的規則。--優先級最高說了算
4.2.4 自定義優先級
值越低優先級越高。要覆蓋此行為，可重寫compareTo()方法以提供自定義優先級策略。
4.2.5 引擎執行模式
- skipOnFirstAppliedRule：當一個規則成功應用時，跳過余下的規則。--一個成功，不管其他
- skipOnFirstFailedRule：當一個規則失敗時，跳過余下的規則。--一個失敗，不管其他
- skipOnFirstNonTriggeredRule：當一個規則未觸發時，跳過余下的規則。--一個不符合，不管其他
- rulePriorityThreshold：當優先級超過指定的閾值時，跳過余下的規則。--優先級達標，不管其他
4.2.6 多種監聽器可供選擇
支持自定義規則監聽器、規則引擎監聽器。
4.2.7 表達式語言支持
支持MVEL、SPEL表達式語言，可通過編程方式定義規則。
4.2.8 規則中的錯誤處理
- 對于條件求值過程中可能發生的任何運行時異常(丟失事實、表達式中輸入錯誤等)，引擎將記錄一個警告，并認為條件求值為false。
- 對于任何在執行操作時可能發生的運行時異常(丟失事實、表達式中輸入錯誤等)，該操作將不會執行，引擎將記錄一個錯誤。
4.3 easyRule使用樣例
還是用篩選籃球苗子的例子
圖片
- 定義一個學生實體類
public class Student {
/**
* 年級
*/
private Integer grade;
/**
* 性別
*/
private String gender;
/**
* 年齡
*/
private Integer age;
/**
* 是否強壯
*/
private Boolean isStrong;
/**
* 身高
*/
private Integer height;
/**
* 是否一個好苗子
*/
private Boolean isGoodSeed = true;
}- 定義規則（有多種方式，我列舉幾種）
//創建規則1-年級
Rule rule1 = new MVELRule()
.name("grade rule")
.description("判斷一個學生是否是一個籃球好苗子-年級")
.priority(1)
.when("student.getGrade() <= 3")
.then("System.out.println(\"年級-不是好苗子\");")
.then("student.setIsGoodSeed(false);");//創建規則2-性別
Rule rule2 = new MVELRuleFactory(new YamlRuleDefinitionReader()).
createRule(new FileReader(
ResourceUtils.getFile("classpath:gender-rule.yml")));規則2需要的yml文件內容如下：
name: "gender rule"
description: "判斷一個學生是否是一個籃球好苗子-性別"
priority: 2
condition: "student.getGender().equals(\"girl\")"
actions:
- "System.out.println(\"性別-不是好苗子\");student.setIsGoodSeed(false);"//創建規則3-年齡
Rule rule3 = new MVELRuleFactory(new JsonRuleDefinitionReader()).
createRule(new FileReader(
ResourceUtils.getFile("classpath:age-rule.json")));//創建規則4-是否強壯
Condition condition = new MVELCondition("!student.getIsStrong()");
Action action = new Action() {
@Override
public void execute(Facts facts) throws Exception {
Student student1 = (Student) facts.get("student");
student1.setIsGoodSeed(false);
System.out.println("強壯-不是好苗子");
}
};
Rule rule4 = new RuleBuilder()
.name("strong rule")
.description("判斷一個學生是否是一個籃球好苗子-是否強壯")
.priority(4)
.when(condition)
.then(action).build();@Rule(name = "height rule" ,description = "判斷一個學生是否是一個籃球好苗子-身高")
public class HeightRule {
@Condition
public boolean checkHeight(){ return student.getHeight() <= 170;}
@Action
public void action(){
System.out.println("身高-不是好苗子");
student.setIsGoodSeed(false);
}
private Student student;
public HeightRule(Student student){
this.student = student;
}
}
//創建規則5-身高
HeightRule rule5 = new HeightRule(student);- 創建實例(fact)
//創建一個Student實例(Fact)
Student student = new Student(3,"girl",9,true, 160,true);
Facts facts = new Facts();
facts.put("student", student);- 創建引擎，并執行規則
//注冊規則
Rules rules = new Rules();
rules.register(rule1);
rules.register(rule2);
//rules.register(rule3);
rules.register(rule4);
rules.register(rule5);
//創建規則執行引擎，并執行規則
RulesEngine rulesEngine = new DefaultRulesEngine();
System.out.println("開始判斷是否是一個籃球苗子：" + JSON.toJSONString(student));
rulesEngine.fire(rules, facts);
System.out.println("是否為好苗子：" + student.getIsGoodSeed());- 執行結果
圖片
4.4 商機流轉如何接入easyRule
熟悉了easyRule如何使用的，接下來看看我們如何在項目中落地的，我們分了幾步：
- 將easyRule工具包進行二次改裝，使其執行規則后能有返回值，封裝成jar包，將規則引擎抽取成通用能力。
初始化規則相關配置（首次初始化+定時更新）；
提供對外public T fire(String ruleId, V v)通用的規則引擎api接口。
圖片
這里我們將規則引擎的處理結果進行了返回，因為業務上很多場景需要，比如不符合規則時的提醒文案。
- 將現有的流轉規則進行整理提取，將各種判斷條件拆解成單一的指標判斷。
- 項目中引入easyRule工具。
項目中配置規則引擎相關配置；
實例化RuleEngineTemplate類；
根據場景，組裝上下文context；
調用ruleEngineTemplate.fire(ruleId,context)方法。
圖片
引入后，我們的商機流轉流程發生了如下變化：
圖片
4.5 商機解綁流程舉例
- 商機解綁流程
圖片
- 解綁對應的規則配置application.yml
spring:
easy-rule:
priority-threshold: 100
skip-on-first-failed-rule: false
skip-on-first-applied-rule: true
skip-on-first-non-triggered-rule: false
rules:
- rule-id: "opportunity_unbind"
rule-file-location: "opportunity_unbind" #規則配置文件
rule-config-type: JSON
rule-factory-type: SPEL具體的規則配置json
[
{
"name": "bind_check_cate",
"description": "判斷是否凍結-72小時",
"condition": "@opportunityUnbindRuleBll.checkOpportunityNeedFreeze(#context.getOpportunityId(), n,m)",
"priority": 4,
"actions": [
"@clueOpporBll.unbindOpportunity(#context,T(OpportunityStatusEnum).UNBIND, T(com.clue.enums.OpportunityMinorStatusEnum).UNBIND_FROZEN)"
]
},
{
"name": "task_bind_out",
"description": "任務商機流回公海",
"condition": "#context.getOpportunityStatus() == T(com.enums.OpportunityStatusEnum).TASK && #context.getOperationTypeEnum() == T(com.OpportunityOperationTypeEnum).TASK_BACK_PUBLIC",
"priority": 5,
"actions": [
"@clueBll.unbindOpportunity(#context,T(com.zhuanzhuan.biz.clue.enums.OpportunityStatusEnum).UNBIND, T(com.OpportunityMinorStatusEnum).UNBIND_NORMAL)"
]
},
{
"name": "unbind_operate",
"description": "判斷解綁后去向，現階段全部回到公海",
"condition": "true",
"priority": 10,
"actions": [
"@clueOpportunityBll.unbindOpportunity(#context,T(com.OpportunityStatusEnum).UNBIND, T(com.enums.OpportunityMinorStatusEnum).UNBIND_NORMAL)"
]
}
]
}
]- 業務代碼
public Result<ParallelExecuteDTO> unbindOpportunity(UnbindOpportunityRequest request) {
return parallelExecutor.parallelExecute(request.getOpportunityIds(), (Long opportunityId) -> {
final Result<String> unbindResult = opportunityUnbindRuleBll.unbindOpportunity(opportunityId, request.getOperator(),
request.getReasonType(), request.getReasonDesc(), request.getOperationType());
logger.info("method=unbindOpportunity, act=unbind, opportunityId={},unbindResult={}", opportunityId, unbindResult);
return unbindResult;
}
);
}4.6 引入規則引擎前后效果對比
圖片
五、總結
在easyRule引入商機流轉業務過程中，從調研到選型再到最終落地，遇到了各種大大小小的問題，但最終的效果還是比較明顯的，對團隊的整體效率提升非常明顯，這里有幾點總結與建議與大家分享。
- 系統引入規則引擎，一定要場景符合，不能為了引入而引入；
- 業務規則轉換為抽象的規則配置，可以多和業務人員交流，他們對于規則的理解可能更深刻；
- 選擇規則引擎方案后，需要定好規則維護規范，后續執行按照規范維護；
- 對于集群中沒有直接引用的代碼，不要直接清理，有可能是在規則文件里有引用。
作者介紹
楊迎，轉轉商業后端開發工程師，目前負責商業B端相關業務系統開發（商機線索、客戶運營、銷售運營管理、廣告發布等）。
