規則引擎解決方案淺析

1、規則引擎使用場景:

  1. 用於頁面,流程,擴展點實現的選擇;輸出結果:實現的位置;
  2. 編排無數的條件積木和行爲積木,達到業務邏輯計算,券庫存消減的目的;輸出結果:商品重計算後的價格;
  3. 經過訂單,售後單,會員等信息編排和判斷,達到多因子決策給出最佳答案的效果;輸出結果:響應式回答/營銷推薦,也或分步驟完成某類表單(售後申請,或工單提交);
  4. 過訂單消息的觸發,和商業化協議的元數據輸入,造成結構化的計費記錄;輸出結果:計費憑證;

業務配置-條件積木,以及應用的受權邏輯,都有很是多的規則管理,因爲業務的變化大,需求迭代快,須要不斷的嵌套規則,硬編碼開發。基於業務須要,但願能創建規則引擎,將規則代碼從業務中抽離出來,下降規則迭代成本,下降if else等的規則嵌套,加強代碼的維護性和複用性。開發人員不用過多的關注邏輯判斷,能夠專一與邏輯處理。json

有不少規則,如校驗是經過if else邏輯硬編碼完成,商品目前支持電商、零售等業務部門,無非就是兩種狀況:一種是商品領域模型的變動,還有一種是規則的變動。能夠說,支撐上層業務,業務規則佔了需求的半邊天。緩存

通用的業務規則引擎,不和本身的業務藕合,提供一個通用的規則引擎是可行的。框架

file

2、什麼是規則引擎

規則引擎是一種嵌入在應用程序中的組件,實現了將業務決策從應用程序代碼中分離出來,並使用預約義的語義模塊編寫業務決策。接受數據輸入,解釋業務規則,並根據業務規則作出業務決策。ide

規則本質上是一個函數,如y=f(x1,x2,..,xn)函數

規則引擎由三部分測試

  • 事實(Fact):就是用戶輸入的已經事實,能夠理解爲推理前的已知對象。
  • LHS(Left Hand Side):能夠理解爲規則執行須要知足的條件。
  • RHS(Right Hand Sike):能夠理解爲規則執行後的返回對象。

兩個重要模塊:編碼

  • 規則管理:能夠理解爲邏輯上管理規則,主要涉及規則、事實對象和規則集三個實體。涉及到規則變動時,最好對規則加個版本,可經過規則版本控制,能夠平滑灰度地方式改變規則,也便於更有信心在測試規則正確性。版本控制

  • 規則執行:經過規則庫數據,經過規則引擎的規則解析、規則編譯將可執行代碼緩存起來,避免每次和DB交互,而後每次規則的變動也經過ZK或者DCC實時通知給規則執行器。規則執行器的實現方式,能夠多種多樣,不依賴於規則庫的存儲方式,能夠根據需求,選用Drools、Aviator等第三方引擎,甚至能夠基於ANTLR定製。對象

file

3、實踐總結

實踐出真理。調研了一些 Java 的規則引擎框架:blog

  • drools比較重,適合風控金融,反欺詐。Avator、Fel、QLExpress 等不太適合搜索路由場景
  • 用基於 Apollo 或者 grovvy腳本等實現引擎,配置路由規則到 apollo 或者 腳本便可。

若是是簡單的場景,咱們只要定義好關鍵條件 key ,命中 key ,返回 key 對應的 result 便可。

若是複雜金融場景,drools 比較合適。

好比一個搜索場景,按照優先級由上到下:

  1. 若是帶了某個店鋪ID,路由到店鋪分片的搜索索引
  2. 若是帶了某個買家ID,路由到買家分片的搜索索引
  3. 若是狀態是熱狀態,路由到熱狀態索引
  4. 若是...

這種簡單的,就用 apollo 定義好關鍵條件 json ,匹配便可。

相關文章
相關標籤/搜索