官網：https://liteflow.cc/

Gitee：https://gitee.com/dromara/liteFlow

Github：https://github.com/dromara/liteflow

LiteFlow一個現代化的開源規則引擎框架，以下文中簡稱LF。

前言

時常在社區里看到有的小伙伴在那提問：

LF在一個流程中如何暫停，等待操作員完成后，進行下一步該怎么做？

LF流程失敗后，下一次能否繼續上次的執行？

LF流程適不適合某個我的業務？

LF流程如何定時執行我的某個流程？

還有的同學表示即便全部看完文檔，也不知道LF該用在何種業務場景。能夠帶來什么好處。

究其原因是錯誤理解了流程的概念和不知道規則引擎的概念。

流程

我們先說流程。

LiteFlow定位是一個規則引擎，而不是流程引擎。它并不完成流程所要做的事，其實壓根LF和流程一點關系也沒有。

那什么是流程呢，標準的定義是，流程由流程定義，節點要做的事和角色組成。每一個角色做一件事，根據定義的流程定義串起來就叫流程。最典型的例子就是審批流：采購員提交了一張采購申請，部門領導審核，審核通過則到了財務這里，財務專員根據預算進行審核，審核通過到了總監這里，總監審核通過，再到CEO這里簽字批準。整個采購單狀態變成待采購。然后進行采購流程。

以上就是標準的一個流程。3大要素，流程定義，事和角色一個都不能少。通常在實際落地過程中，流程引擎負責流程的流轉和角色的分派。開發人員只需要定義流程，和開發每個角色需要做的邏輯即可。

流程引擎重點強調2點：

流程的定義，下一步是什么，整體的流向，有多少分支。

角色的分派，即下一步該由誰完成。

大部分流程引擎為了靈活性，也提供了流程定義的熱更新以及添加角色，修改流程節點更改綁定角色的功能。

雖然LF從EL規則上來看，似乎也是一個個小模塊的流轉，但是LF并不涉及角色分派這件事。

規則

我們再來看規則引擎的概念。

規則引擎主要強調一件事，把業務中最主要的決策邏輯從程序中抽離出來，用預定義的DSL來實現。并且可以實時改變這些最主要的決策邏輯。

說的再白話點，就是決定邏輯走向的最關鍵的決策邏輯，不是在代碼中的，可以放在外面的任意地方(文件里，數據庫里，其他存儲，遠程獲取）。并且這些決策邏輯并不是用你應用的代碼語義來實現的。規則引擎提供一套語言，來書寫這些決策邏輯。規則引擎也應該提供熱更新這些決策代碼的功能。

可以看出，規則引擎根本不涉及角色的概念，它更多的適用于一個相對比較復雜的邏輯塊。把最核心的部分抽出來用規則引擎定義。

但是整個邏輯塊基本要做的還是一件事情。只是部分抽出來而已。

標準的規則引擎處理的例子：

如果有人v我50塊，我就去家門口的KFC吃一頓

如果有人v我200塊，我就坐地鐵去港式餐廳吃一頓

如果有人v我500塊，我就打個車，去吃頓日式烤肉

如果有人v我2000塊，我就去買身衣服，去吃頓惠林頓牛排，再整瓶酒。

如果有人v我100w，趕緊抽自己一巴掌，看自己醒了沒。

有同學看到這，可能會說，那我搞個文件，存groovy代碼，我應用每次執行到關鍵決策的時候，去讀取這個文件里的groovy代碼，然后解析執行。這不就是規則引擎嗎，我要改變決策的時候，每次改那個文件里的groovy代碼就行了。

還真是這樣！這就是規則引擎！

簡單來說，規則引擎就強調3個點：

決策代碼不在你的應用程序里

擁有獨特的DSL語義書寫

實時更新，不用改變應用程序

所以，一些DSL項目也被稱作為規則引擎，如Aviator，QLExpress。這些框架提供了熱更的接口，稍作包裝，就可以開發出一套最基本的規則引擎。

但是我更愿意把這些項目歸類為表達式引擎，業界還有著名的SpEL(spring的EL)，springframwork expression language，其實從全程就可以看出，官方定義了就是表達式語言。

LF滿足決策代碼可以不寫在應用程序里，也擁有獨特的DSL，也支持實時更新。但是LF怎么還擁有流轉的功能？LF看起來怎么有點四不像啊？

那LF是什么呢

LF也是作用于一個大的邏輯塊的，和角色沒關系，滿足規則引擎的需要的3個關鍵點。從這點來說，LF是規則引擎。

LiteFlow中的腳本節點已經滿足了規則引擎的全部的定義了。那么LF只做腳本節點就可以了。可以熱更，擁有獨特的DSL，可以保存在任意地方。

但是LF也可以流轉，從一個節點流轉到另外一個節點，但是這里的節點是一個個小的拆分的邏輯塊。其實這是LF獨特的地方，這部分并不是標準規則引擎定義所必須的。我稱之為：編排。

編排如何理解呢，說的專業點，這就是邏輯關系反轉，看到這里，有些同學可能又開始看不懂了。你丫的怎么還自己造詞呢 。

且聽我慢慢道來。

spring的出現解決了依賴反轉，我們不用spring的時候，對象的裝載是自己new的，spring出現后，只需要在xml里聲明后，各個代碼塊都可以注入了。就不用自己new了。這就是依賴反轉。相信這個大家學習八股時已經背了無數遍了。

那么邏輯關系的進行，我們大部分代碼還是A類調用B類的方法，B類調用C類的方法。這就是邏輯關系的綁死。如果A，B，C三個類在代碼層面互不相干。但是我在xml里去規定，這三個的進行順序。這就是邏輯關系反轉。

邏輯關系反轉有什么好處呢？

邏輯關系反轉后，好處很多，首先每個類不再強依賴，所有的代碼都講究松耦合理論。那么邏輯關系反轉后，就完美實現了松耦合。并且LF規定了每個類的聲明方式，就顯得所有的邏輯類都長的差不多。更加統一。

其次，邏輯關系反轉后，你只需要看xml定義就可以大致理解這個大的邏輯塊都干了什么事。非常直觀。

再次，邏輯關系都可以熱更，那么這是一件多么優雅的事情啊。

那么做邏輯關系反轉的引擎我稱之為：編排引擎。

所以，LiteFlow是規則引擎+編排引擎的結合體。

它既可以熱更新最關鍵的決策邏輯，又可以熱更新邏輯關系的組成。

所以LiteFlow做的是更現代化的規則引擎，它在做好規則引擎的基礎上，超越了原本規則引擎所規定的范疇。

如何用好LF

其實如果對LF理解夠深刻，它幾乎是一個應用最核心的驅動器。妥妥神器，無論重構，要靈活，要解耦，它都不在話下。

如果對LF理解不夠，那你可能感覺LF沒什么用。也不知道該怎么用。

所以這就是我一開頭提到的。理解流程和規則邏輯流的概念很重要。

LiteFlow提供的腳本多達7種，這些腳本可以充分書寫你的關鍵決策邏輯。并且LF打通了所有腳本和Java的互通，用腳本寫不了的。也可以調用java方法來完成。

LiteFlow提供的獨特EL適用于做邏輯反轉，讓你的巨大復雜的邏輯變成一個個小的積木塊，通過DSL來進行組搭，形成你業務的邏輯流。積木塊可以是你的java組件，也可以是腳本寫的決策邏輯。

所以一般項目推薦的做法，就是首先解耦你的復雜邏輯，按照業務邊界拆成一個個小的組件，然后把最經常變動的決策邏輯用腳本組件來實現。加上DSL編寫的邏輯關系反轉表達式。這樣形成的系統，其優雅度是非常高的。

你想想，你的關鍵決策代碼，和邏輯關系均可以進行熱改變，你的系統中耦合性幾乎降低到了最低。改一個小組件不會牽扯到其他的組件的改變。

再回答開頭的問題

如果你看到這，全都能理解的話，那么最開始的幾個問題也就能輕而易舉的能回答了。

LF因為沒有角色的概念，全部流轉的只是小邏輯塊。所以沒法暫停的。因為就相當于你普通寫的瀑布式代碼調用。只是換了一種方式來寫而已。

LF不保存狀態，是一個無狀態的東西。一般來說，規則引擎都是無狀態的。狀態這回事其實還是要業務自己做的。況且有狀態這回事情非常危險，一般框架不會去保證這個。

LF一般來說，所有用普通瀑布流代碼一層層去調用都可以用LF去改造，LF并不針對于某個特殊的領域，都可以用的。除非你的定義是屬于標準的流程引擎干的事。那么的確不應該選型LF。

關于定時，也不是LF該干的事。LF提供接口層面的執行器，外面套層定時框架即可。很簡單。

LF對標的框架是什么？

LF的目標始一直沒變過，那就是：超越Drools。

LF獨特的理念是國產自研，全部的代碼也是國產自研。非常適合拿來做信創改革。

Drools是國外老牌且一向作為行業標桿的規則引擎。相信了解過這行的都有聽說過。

其實Drools只提供了標準的規則引擎，并沒有提供邏輯關系反轉的特性，而且它的DSL學習成本還是比較大的。而LF則用現成的語言來提供作為腳本，比如js，groovy，aviator，python，lua，甚至java本身也可以拿來做寫腳本，這些根本不用再次學習。

LF除了規則引擎之外，更加拓展了規則引擎的范疇，使得LF能做的事情更多。

并且LF支持的存儲中間件之豐富的，也絕非Drools能比擬的。

加上LF全中文文檔，社區答疑體系在開源中首屈一指。Drools一堆英文文檔，去哪答疑？

一定要說LF比不上的Drools的地方。那就是決策表體系。

Drools是不需要指定規則的，由決策表來多項匹配。LF由于提供了邏輯反轉，是需要指定特定的規則的。

但是這個LF也準備在2.11.5中提供，彌補最后核心上的短板。

屆時LF可以平替Drools。

我會為此一直堅守。

謹此此篇獻給關注過LF的同學。

總結

以上是生活随笔為你收集整理的白话文解析LiteFlow的理念是什么？什么时候用该怎么用？干货满满的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。