1. 首頁 > 生活百科 > >

規則引擎深度對比，LiteFlow vs Drools！

生活百科

前言Drools是一款老牌的java規則引擎框架 ， 早在十幾年前，我剛工作的時候，曾在一家第三方支付企業工作 。在核心的支付路由層面我記得就是用Drools來做的 。
難能可貴的是，Drools這個項目在十幾年后還依舊保持著開源和更新 。

https://github.com/kiegroup/drools
而LiteFlow也是一款java規則引擎 ， 于2020年開源 。經過2年的迭代，現在功能和特性也非常棒 ， 很適合用在高復雜度的核心業務上，同時又能保持業務的靈活性 。
https://gitee.com/dromara/liteFlow
這篇文章我們就來深入比較下這兩款框架，都適合用在什么樣的場景，有什么異同點，以及在相同的場景下表現力如何 。
（其中Drools基于7.6.0版本，LiteFlow基于2.9.0版本）
雖然題主就是開源項目LiteFlow的作者，但是我這幾天也深入了解了下Drools，盡量從很客觀的角度嘗試去分析 。很多比對的結果都是基于實際使用后的感受 。不過題主難免會帶有一些主觀的心理以及了解的片面性，尤其是Drools現在已經更新到了8.X，說實話并沒有使用過 。所以說的不正確的地方也請指正 。
規則引擎的定義首先我想明確下規則引擎的定義，因為很多小伙伴容易把規則引擎和流程引擎的概念混在一起 。
規則引擎通常是嵌入在應用程序組件中的，實現了將業務決策從應用程序代碼中分離出來，并使用預定義的語義模塊編寫業務決策 。接受數據輸入，解釋業務規則 ， 并根據業務規則做出業務決策 。
簡單來說就是，規則引擎主要解決易變邏輯和業務耦合的問題，規則驅動邏輯 。以前項目內寫死在代碼里的邏輯用規則引擎可以提出來 ， 隨時熱變更 。
而流程引擎實現了將多個業務參與者之間按照某種預定義的規則進行流轉，通常需要涉及到角色信息 。
簡單來說就是，流程引擎主要解決業務在不同角色之間的流轉問題，如請假流程 ， 審批流程，往往要經過多個角色 。規則驅動角色流轉 。
兩款框架的異同點Drools和LiteFlow都是優秀的開源框架，都能把業務中的邏輯給剝離出來 。并且擁有自己表達式語法 。
但是有所區別的是，Drools強調邏輯的片段規則化 ， 你可以把核心易變部分寫成一個規則文件，等同于原先寫在java里的代碼現在搬遷到了規則文件 。規則文件里的代碼全都是可以熱變更的 。
而LiteFlow是基于組件式的思想設計的，更強調組件的規則化，覆蓋范圍是整個業務 。編排的最小單位是組件 ， 規則文件用來串聯組件間的流轉 。同時LiteFlow也支持片段式的代碼規則化，因為LiteFlow也支持業務邏輯的腳本化 。規則支持熱變更 。
所以評判一個規則引擎是否合格的主要因素有：
  1. 有沒有靈活的規則表達式來支持
  2. 規則和Java之間能否非常方便的聯動
  3. API調用是否方便，和各種場景系統的集成如何
  4. 侵入性耦合比較
  5. 規則的學習成本，是否容易上手
  6. 規則表達式是否有語言插件
  7. 規則能否和業務松耦合，存儲于其他地方
  8. 規則的變更能否實時改變邏輯
  9. 是否有界面形態來支持非技術人員的使用
  10. 框架的性能表現
下面就從這幾個方面來細細比較兩款框架的表現力
規則表達式Drools的規則表達式為Java量身定制的基于Charles Forgy的RETE算法的規則引擎的實現 。
Drools的規則表達式貼近自然編程語言，擁有自己的擴展名文件drl，語法支持全，基本上自然編程語言有的語法drl全有 。所以，完全可以把java的邏輯寫在drl文件中 。
來看下drl文件的大體樣子：
規則引擎深度對比，LiteFlow vs Drools！

文章插圖
可以看到，Drools定義規則的方式是一個規則一段，有明確的when...then，表示當滿足什么條件時，做什么 。在觸發規則時候，會自動判斷該去執行哪一段rule，如果滿足多個條件，是可以觸發多個規則的then的 。
LiteFlow編排表達式簡單易懂 ， 底層用EL表達式語言包裝而成 。用于組件的流轉，支持異步，選擇，條件，循環，嵌套等一些場景 。
組件層面不僅可以是java組件，還可以用腳本語言來編寫 ， 目前支持了Groovy和QLExpress兩種腳本語言 。所有能用java實現的 ， 用腳本語言都可以做到 。
LiteFlow的規則文件大體長這個樣子：

推薦閱讀