業務配置-條件積木,以及應用的受權邏輯,都有很是多的規則管理,因爲業務的變化大,需求迭代快,須要不斷的嵌套規則,硬編碼開發。基於業務須要,但願能創建規則引擎,將規則代碼從業務中抽離出來,下降規則迭代成本,下降if else等的規則嵌套,加強代碼的維護性和複用性。開發人員不用過多的關注邏輯判斷,能夠專一與邏輯處理。json
有不少規則,如校驗是經過if else邏輯硬編碼完成,商品目前支持電商、零售等業務部門,無非就是兩種狀況:一種是商品領域模型的變動,還有一種是規則的變動。能夠說,支撐上層業務,業務規則佔了需求的半邊天。緩存
通用的業務規則引擎,不和本身的業務藕合,提供一個通用的規則引擎是可行的。框架
規則引擎是一種嵌入在應用程序中的組件,實現了將業務決策從應用程序代碼中分離出來,並使用預約義的語義模塊編寫業務決策。接受數據輸入,解釋業務規則,並根據業務規則作出業務決策。ide
規則本質上是一個函數,如y=f(x1,x2,..,xn)函數
規則引擎由三部分測試
兩個重要模塊:編碼
規則管理:能夠理解爲邏輯上管理規則,主要涉及規則、事實對象和規則集三個實體。涉及到規則變動時,最好對規則加個版本,可經過規則版本控制,能夠平滑灰度地方式改變規則,也便於更有信心在測試規則正確性。版本控制
規則執行:經過規則庫數據,經過規則引擎的規則解析、規則編譯將可執行代碼緩存起來,避免每次和DB交互,而後每次規則的變動也經過ZK或者DCC實時通知給規則執行器。規則執行器的實現方式,能夠多種多樣,不依賴於規則庫的存儲方式,能夠根據需求,選用Drools、Aviator等第三方引擎,甚至能夠基於ANTLR定製。對象
實踐出真理。調研了一些 Java 的規則引擎框架:blog
若是是簡單的場景,咱們只要定義好關鍵條件 key ,命中 key ,返回 key 對應的 result 便可。
若是複雜金融場景,drools 比較合適。
好比一個搜索場景,按照優先級由上到下:
這種簡單的,就用 apollo 定義好關鍵條件 json ,匹配便可。