規則引擎解決方案淺析
阿新 • • 發佈：2019-12-31
一、規則引擎使用場景：
- 用於頁面，流程，擴充套件點實現的選擇；輸出結果：實現的位置；
- 編排無數的條件積木和行為積木，達到業務邏輯計算，券庫存消減的目的；輸出結果：商品重計算後的價格；
- 通過訂單，售後單，會員等資訊編排和判斷，達到多因子決策給出最佳答案的效果；輸出結果：響應式回答/營銷推薦，也或分步驟完成某類表單（售後申請，或工單提交）；
- 過訂單訊息的觸發，和商業化協議的元資料輸入，形成結構化的計費記錄；輸出結果：計費憑證；
業務配置-條件積木，以及應用的授權邏輯，都有非常多的規則管理，由於業務的變化大，需求迭代快，需要不斷的巢狀規則，硬編碼開發。基於業務需要，希望能建立規則引擎，將規則程式碼從業務中抽離出來，降低規則迭代成本，降低if else等的規則巢狀，增強程式碼的維護性和複用性。開發人員不用過多的關注邏輯判斷，可以專注與邏輯處理。
有很多規則，如校驗是通過if else邏輯硬編碼完成，商品目前支援電商、零售等業務部門，無非就是兩種情況：一種是商品領域模型的變更，還有一種是規則的變更。可以說，支撐上層業務，業務規則佔了需求的半邊天。
通用的業務規則引擎，不和自己的業務藕合，提供一個通用的規則引擎是可行的。
二、什麼是規則引擎
規則引擎是一種嵌入在應用程式中的元件，實現了將業務決策從應用程式程式碼中分離出來，並使用預定義的語義模組編寫業務決策。接受資料輸入，解釋業務規則，並根據業務規則做出業務決策。
規則本質上是一個函式，如y=f(x1,x2,..,xn)
規則引擎由三部分
- 事實（Fact）：就是使用者輸入的已經事實，可以理解為推理前的已知物件。
- LHS(Left Hand Side)：可以理解為規則執行需要滿足的條件。
- RHS(Right Hand Sike)：可以理解為規則執行後的返回物件。
兩個重要模組：
- 規則管理：可以理解為邏輯上管理規則，主要涉及規則、事實物件和規則集三個實體。涉及到規則變更時，最好對規則加個版本，可通過規則版本控制，可以平滑灰度地方式改變規則，也便於更有信心在測試規則正確性。
- 規則執行：通過規則庫資料，通過規則引擎的規則解析、規則編譯將可執行程式碼快取起來，避免每次和DB互動，然後每次規則的變更也通過ZK或者DCC實時通知給規則執行器。規則執行器的實現方式，可以多種多樣，不依賴於規則庫的儲存方式，可以根據需求，選用Drools、Aviator等第三方引擎，甚至可以基於ANTLR定製。
三、實踐總結
實踐出真理。調研了一些 Java 的規則引擎框架：
- drools比較重，適合風控金融，反欺詐。Avator、Fel、QLExpress 等不太適合搜尋路由場景
- 用基於 Apollo 或者 grovvy指令碼等實現引擎，配置路由規則到 apollo 或者 指令碼即可。
如果是簡單的場景，我們只要定義好關鍵條件 key ，命中 key ，返回 key 對應的 result 即可。
如果複雜金融場景，drools 比較合適。
比如一個搜尋場景，按照優先順序由上到下：
- 如果帶了某個店鋪ID，路由到店鋪分片的搜尋索引
- 如果帶了某個買家ID，路由到買家分片的搜尋索引
- 如果狀態是熱狀態，路由到熱狀態索引
- 如果...
這種簡單的，就用 apollo 定義好關鍵條件 json ，匹配即可。