賦能轉轉回收：LiteFlow可視化編排方案設計
1、引言
LiteFlow解決哪些場景的問題呢？通過下面的例子感受一下。
假設有三個組件（或方法）stepOne、stepTwo、stepThree，并且你想要按照順序打印"one"、"two"、"three"，通常我們編寫代碼的方式可能是這樣的：
@Component
public class PrintService {
/**
* 執行業務代碼
*/
private void doExecute() {
stepOne();
stepTwo();
stepThree();
}
private void stepOne() {
// 業務代碼
System.out.println("one");
}
private void stepTwo() {
// 業務代碼
System.out.println("two");
}
private void stepThree() {
// 業務代碼
System.out.println("three");
}
}這樣寫最簡單粗暴，但是如果之后有調整打印順序的話，例如你想打印two、one、three，或者直接跳過two直接打印one、three，你一定需要修改代碼并且重新上線。
// 打印two、one、three
public void doExecute() {
stepTwo();
stepOne();
stepThree();
}
// 打印one、three
public void doExecute() {
stepOne();
stepThree();
}對于需要動態調整執行流程的業務場景，顯然不適合將流程硬編碼在代碼中。
2、 LiteFlow簡介
LiteFlow是一款編排式的規則引擎框架，可以通過表達式的方式來編排組件或方法的執行流程，并且支持一些高級的流程編排。
上述案例如何通過更高級的方式來實現零代碼修改、無需重新上線即可編排流程了呢？我們基于LiteFlow做一些改造。
2.1 引入jar包
可以去官網根據需要選擇合適的版本，這里用的是最新版本
<dependency>
<groupId>com.yomahub</groupId>
<artifactId>liteflow-spring-boot-starter</artifactId>
<version>2.12.0</version>
</dependency>2.2 定義組件
將打印功能分別定義成一個個組件，繼承NodeComponent 這個抽象父類并實現其中的方法：
@Component
public class PrintOne extends NodeComponent {
@Override
public void process() throws Exception {
// 業務代碼
System.out.println("one");
}
}@Component
public class PrintTwo extends NodeComponent {
@Override
public void process() throws Exception {
// 業務代碼
System.out.println("two");
}
}@Component
public class PrintThree extends NodeComponent {
@Override
public void process() throws Exception {
// 業務代碼
System.out.println("three");
}
}2.3 執行流程
定義好組件之后，我們就開始編寫組件執行的流程表達式了，官方名稱叫EL表達式；上述案例可以這樣編寫表達式：
THEN(node("printOne"),node("printTwo"),node("pirntThree"));
并給這個流程起個名字（流程唯一標識）：print_flow
根據流程名稱執行流程：
@Component
public class PrintService {
@Autowired
private FlowExecutor flowExecutor;
/**
* 執行業務代碼
*/
public void doExecute() {
// 開始執行流程
LiteflowResponse response = flowExecutor.execute2Resp("print_flow");
// 根據執行結果進行后續操作
// ......
}
}一般我們會將流程放到數據庫中，如果想改變打印順序，只需要修改表達式即可，例如：打印two、one、three。
THEN(node("printTwo"),node("printOne"),node("pirntThree"));
打印two、three。
THEN(node("printTwo"),node("printThree"));
然后LiteFlow真正強大的地方遠不止如此，它不僅僅支持簡單的串行編排，還支持更加復雜的邏輯例如（并行編排）WHEN、（條件編排）IF、（選擇編排）SWITCH、（循環編排）FOR等。
2.4 官網
上述的簡單示例旨在為不熟悉LiteFlow框架的伙伴們提供一個初步的認知。要想真正基于LiteFlow將業務流程落地并運用到實際業務場景中，還需要通過官方文檔深入了解該框架的運作原理和核心機制。
https://liteflow.cc/
3、可視化編排（形態進階）
3.1 為什么要可視化
官網提供修改表達式的方式只有一個，那就是手寫！官網并沒有提供配套的可視化工具，手寫可能存在諸多問題和不便，例如：
- 容易出錯：表達式少一個字母甚至一個逗號都不行！
- 流程不可視：我們只能完全依賴大腦去構想這些流程，運營或產品團隊想要了解或討論流程，也只能依賴于其他畫圖工具來手動繪制和表達。
- 節點不可配置：我們的運營會根據不同的場景對節點進行動態配置，沒有可視化界面，運營改動配置的需求則無從下手。
所以可視化對于編排流程來說意義重大，對于研發能更準確地理解和設計流程，還能讓運營能更便捷地監控和管理流程。
3.2 方案設計
網上有一些網友開源的項目，但基本都是個人維護，對于復雜流程的處理不是很好，質量也參差不齊，所以自己進行了調研和設計；支持普通節點、判斷節點、選擇節點、并行節點；循環節點目前業務不需要，有需要的可以自己拓展，掌握方案之后拓展節點類型非常簡單。完成可視化編排需要解決兩個問題：
- 一款與用戶交互的前端畫布（推薦logicFlow，有自己熟悉的也行）
- 將畫布數據轉化成EL表達式（手寫算法，基于DFS的遞歸）
這里重點講畫布數據轉化為EL的過程。
3.2.1 整體流程
創建流程
流程的核心在第5步，下面會重點講解。
回顯流程
解析EL成本很高，所以我選擇不解析表達式，直接將前端傳入的畫布json數據返回給前端進行回顯。
3.2.2 后端抽象語法樹設計
節點類型枚舉
public enum NodeEnum {
// 普通節點，對應普通組件
COMMON,
// 并行節點，對應并行組件
WHEN,
// 判斷節點，對應判斷組件
IF,
// 選擇節點，對應選擇組件
SWITCH,
// 匯總節點（自定義）
SUMMARY,
// 開始節點（自定義）
START,
// 結束節點（自定義）
END;
}COMMON
普通節點，入度和出度都為1。
IF
判斷節點，包含一個true分支，一個false分支，入度為1，出度為2。
SWITCH
根據SWITCH返回的tag，來決定執行后續哪個流程。入度為1，出度大于1。
WHEN
官網沒有WHEN節點的概念，我這里自定義WHEN節點會避免很多問題。
為什么要定義WHEN節點？
WHEN作為一個出度大于1的節點，和IF、SWITCH不同的是WHEN并沒有一個前置節點去驅動一個流程。
假設這樣一個流程，如果沒有WHEN節點的支持，展示到畫布上的效果很差。
THEN(
IF(node("c"),
WHEN(
node("a"),
node("b"),
node("d"),
node("e")
).ignoreError(true)
),
node("f")
)
SUMMARY
官網沒有這種節點，自定義節點，用于匯總所有分支節點，也就是WHEN、IF、SWITCH節點。入度大于1，出度為1。
為什么要定義SUMMARY節點？
構建EL算法是基于遞歸實現的，參考的是深度優先遍歷算法（DFS），這種嵌套方式如果沒有一個結束標志會一直執行下去。
舉個例子：
基于圖1生成EL表達式
THEN(
node("c"),
WHEN(
THEN(node("b"),node("e")),
THEN(node("d"),node("e"))
)
)基于圖2生成EL表達式
THEN(
node("c"),
WHEN(node("b"),node("d")),
node("e")
)可以看出來圖2的EL表達式才是我們想要的。
市面上有名的工作流引擎在畫布上處理匯總問題也是這樣設計的，比如在activiti中使用并行網關開啟會簽，也必須用并行網關在會簽結束時進行匯總，否則就會出現重復審批的問題。
START
開始節點，一個流程必須有一個開始節點，入度為0，出度為1。
END
結束節點，一個流程必須有一個結束節點，入度為1，出度為0。
上述節點類型的類定義
// 抽象父類
@Getter
public abstract class Node {
// node的唯一id
private final String id;
// node名稱，對應LiteFlow的Bean名稱
private final String name;
// 入度
private final List<Node> pre = Lists.newArrayList();
// 節點類型
private final NodeEnum nodeEnum;
// 出度
private final List<Node> next = Lists.newArrayList();
protected Node(String id, String name, NodeEnum nodeEnum) {
this.id = id;
this.name = name;
this.nodeEnum = nodeEnum;
}
public void addNextNode(Node node) {
next.add(node);
}
public void addPreNode(Node preNode) {
pre.add(preNode);
}
}
// 普通節點
public class CommonNode extends Node {
public CommonNode(@NonNull String id, @NonNull String name) {
super(id, name, NodeEnum.COMMON);
}
}
// 并行節點
public class WhenNode extends Node {
public WhenNode(@NonNull String id, @NonNull String name) {
super(id, name, NodeEnum.WHEN);
}
}
// 判斷節點
@Getter
public class IfNode extends Node {
private Node trueNode;
private Node falseNode;
public IfNode(@NonNull String id, @NonNull String name) {
super(id, name, NodeEnum.IF);
}
public void setTrueNode(Node trueNode) {
this.trueNode = trueNode;
super.addNextNode(trueNode);
}
public void setFalseNode(Node falseNode) {
this.falseNode = falseNode;
super.addNextNode(falseNode);
}
}
// 選擇節點
@Getter
public class SwitchNode extends Node {
private final Map<Node, String> nodeTagMap = Maps.newHashMap();
public SwitchNode(@NonNull String id, @NonNull String name) {
super(id, name, NodeEnum.SWITCH);
}
public void putNodeTag(Node node, String tag) {
nodeTagMap.put(node, tag);
super.addNextNode(node);
}
}
// 開始節點
public class StartNode extends Node {
public StartNode(@NonNull String id, @NonNull String name) {
super(id, name, NodeEnum.START);
}
}
// 結束節點
public class EndNode extends Node {
public EndNode(@NonNull String id, @NonNull String name) {
super(id, name, NodeEnum.END);
}
}
// 匯總節點
public class SummaryNode extends Node {
public SummaryNode(@NonNull String id, @NonNull String name) {
super(id, name, NodeEnum.SUMMARY);
}
}3.2.3 畫布JSON數據設計
畫布數據最終體現在JSON語法樹，數據結構如下：
{
"nodeEntities": [
{
"id": "節點的唯一id，由前端生成。必填",
"name": "節點名稱，對應LiteFlow的節點名稱，spring的beanName。必填",
"label": "前端節點展示名稱，到時候給前端。必填",
"nodeType": "節點的類型，有COMMON、IF、SWITCH、WHEN、START、END和SUMMARY。必填",
"x": "x坐標。必填",
"y": "y坐標。必填"
}
],
"nodeEdges": [
{
"source": "源節點。必填",
"target": "目標節點。必填",
"ifNodeFlag": "if類型節點的true和false，只有ifNode時必填，其他node隨意",
"tag": "switch類型的下層節點的tag，主機有switchNode時必填，其他node隨意"
}
]
}用戶拖動畫布節點和節點之間連線的過程，其實就是維護節點數組和邊數組的過程。
3.2.4 畫布JSON數據合法校驗
下面是針對畫布json數據的一些簡單合法性校驗，可以自己根據需要拓展，實現很簡單，最后有具體實現代碼，需要的可以下載。
- 流程必須有一個開始節點和一個結束節點
- 校驗節點類型，只能是IF、WHEN、COMMON、SWITCH、START、END和SUMMARY
- IF、WHEN、SWITCH節點的數量總和與SUMMARY類型節點數量總和校驗
- 校驗節點和邊的source和target是否能對應上
- 校驗SWITCH的出度邊是否有tag，且tag不能為空
- 校驗IF節點有沒有ifNodeFlag的標識，并且總有一條true分支，總有一條false分支
3.2.5 畫布JSON數據轉化為抽象語法樹
舉個簡單的例子：
對應的JSON語法樹如下；避免篇幅過長，這里只列舉了部分屬性。
{
"nodeEntities": [
{
"id": "a",
"label": "a",
"nodeType": "COMMON"
},
{
"id": "e",
"label": "e",
"nodeType": "WHEN"
},
{
"id": "b",
"label": "b",
"nodeType": "COMMON"
},
......
],
"nodeEdges": [
{
"source": "a",
"target": "e",
},
{
"source": "e",
"target": "b",
},
{
"source": "e",
"target": "c",
},
......
]
}JSON轉化為抽象語法樹，實際就是創建節點對象，并維護節點的屬性，下面是偽代碼。
// 創建節點對象
List<Node> nodes = Lists.newArrayList();
for (NodeEntity nodeEntity : nodeEntities) {
Node node = null;
switch (nodeEntity.getNodeType()) {
case NodeEnum.COMMON;
node = new CommonNode("節點的id", "節點的label");
break;
case NodeEnum.WHEN;
node = new WhenNode("節點的id", "節點的label");
break;
case NodeEnum.SUMMARY;
node = new SummaryNode("節點的id", "節點的label");
break;
default:
throw new RuntimeException("未知的節點類型！");
}
nodes.add(node);
}
// 構建nodeId和node的map
Map<String, Node> nodeIdAndNodeMap = nodes.stream()
.collect(Collectors.toMap(Node::getId, Function.identity()));
// 維護節點間關系
for (NodeEdge nodeEdge : nodeEdges) {
Node sourceNode = nodeIdAndNodeMap.get(nodeEdge.getSource());
Node targetNode = nodeIdAndNodeMap.get(nodeEdge.getTarget());
sourceNode.addNextNode(targetNode);
targetNode.addPreNode(sourceNode);
......
}疑問：為什么要設計JSON和AST（抽象語法樹）兩種數據結構？
根據上述JSON數據可以發現，用戶編輯畫布時，前端只需要維護節點和邊兩個數組即可；而生成EL表達式的操作在后端，生成方法是利用遞歸實現的深度優先遍歷算法（DFS），顯然JSON是不滿足遞歸需求的，所以JSON轉換為AST。
總之設計JSON和AST就是為了方便前后端去各自維護數據。
3.2.6 抽象語法樹生成EL表達式
整個流程的核心就在這里，AST生成EL表達式
同樣用上面的例子來模擬生成EL表達式過程，該流程只涉及THEN和WHEN，我們約定把THEN和WHEN當成數組來處理，例如THEN(node("a"),node("b"))對應數組[node("a"),node("b")]，同理WHEN。
- 流程必須以一個數組開始。
[
node("a")
]- 遇見WHEN分支節點e，創建一個新數組，并加入上一層數組。
[
node("a"),
[
]
]- 分支節點之后的每一個分支都要創建一個數組，并且加入到分支節點的數組中。
[
node("a"),
[
[
node("b")
]
]
]- 正常的串行，節點直接加入最內層數組。
[
node("a"),
[
[
node("b"),
node("d")
]
]
]- 遇見匯總節點，什么也不處理。
[
node("a"),
[
[
node("b"),
node("d")
]
]
]- 繼續向下，將f節點加入WHEN節點所在的數組，到達遞歸的出口。
[
node("a"),
[
[
node("b"),
node("d")
]
],
node("f")
]這可能有疑問，程序是如何定位到WHEN所在的數組在哪呢？
利用棧，遇到WHEN節點的時候會將WHEN節點所在的數組壓棧，等遇到匯總節點時將數組出棧，那么可以確定f節點應該加入出棧時的數組了。
- 因為是從e節點開始有分支流程的，以b節點開頭的分支已經執行完，回溯到另一條分支；同樣c節點屬于e的一條分支，分支節點之后的每一個分支都要創建一個數組，并且加入到分支節點的數組中。
[
node("a"),
[
[
node("b"),
node("d")
],
[
node("c")
]
],
node("f")
]- 到了匯總節點，因為遍歷以b節點開頭的分支時已經訪問了該匯總節點，這次不處理，到達遞歸的出口。
[
node("a"),
[
[
node("b"),
node("d")
],
[
node("c")
]
],
node("f")
]如何判斷匯總節點是否訪問過？
用Set，訪問過的匯總節點加入Set中，下次再訪問先判斷Set中有沒有該匯總節點，有就不往下執行，到達遞歸出口。
結束！
根據上面簡單示例，下面是用遞歸實現DFS的偽代碼；文末有全量源碼，感興趣的可以下載參考一下。
public static String ast2El(Node head) {
if (head == null) {
return null;
}
// 用于存放when節點List
Deque<List> stack = new ArrayDeque<>();
// 用于標記是否處理過summary節點了
Set<String> doneSummary = Sets.newHashSet();
List list = tree2El(head, new ArrayList(), stack, doneSummary);
// 將list生成EL，你可以認為框架有對應的方法
return toEL(list);
}
private static List tree2El(Node currentNode,
List currentThenList,
Deque<List> stack,
Set<String> doneSummary) {
switch (currentNode.getNodeEnum()) {
case COMMON:
currentThenList.add(currentNode.getId());
for (Node nextNode : currentNode.getNext()) {
tree2El(nextNode, currentThenList, stack, doneSummary);
}
case WHEN:
stack.push(currentThenList);
List whenELList = new ArrayList<>();
currentThenList.add(whenELList);
for (Node nextNode : currentNode.getNext()) {
List thenELList = new ArrayList<>();
whenELList.add(thenELList);
tree2El(nextNode, thenELList, stack, doneSummary);
}
case SUMMARY:
if (!doneSummary.contains(currentNode.getId())) {
doneSummary.add(currentNode.getId());
// 這種節點只有0個或者1個nextNode
for (Node nextNode : currentNode.getNext()) {
tree2El(nextNode, stack.pop(), stack, doneSummary);
}
}
default:
throw new RuntimeException("未知的節點類型！");
}
return currentThenList;
}3.2.7 校驗EL表達式的合法性
這是生成EL表達式的最后一步；框架有本身有支持校驗EL合法性的方法，在生成EL之后進行校驗。
// 校驗是否符合EL語法
Boolean isValid = LiteFlowChainELBuilder.validate(el);進行完最后一步，EL表達式就可以入庫了。
3.3 推拉結合刷新流程
流程入庫之后并不是立即生效，進行以下操作后生效。
3.3.1 拉
框架會定期從數據庫（或通過配置指定的任何數據源）中同步最新流程，并將這些流程緩存在內存中；新流程同步和緩存的過程是平滑進行的，不會干擾或打斷現有流程的執行；該框架還允許用戶根據實際需求配置數據刷新的時間間隔（默認1分鐘），具體配置方法可參照官方文檔進行詳細了解。
3.3.2 推
如果我們希望改動的EL表達式立即生效而不是等待框架被動刷新，我們可以通過官方提供的api進行主動刷新：
flowExecutor.reloadRule();需要注意的的是，官方提供的方法只是刷新單個實例節點的流程；如果是集群環境，我們需要借助消息隊列以達到通知整個集群的效果。
3.4 源碼
目前這套設計方案已在實際業務場景落地并使用；自己進行過很多復雜流程的驗證，基于這種規則能百分百保證生成EL表達式的正確性。
自己的寫的demo，可以借鑒一下思路；里面有一個構造好的復雜流程案例，通過調接口的方式自己感受。
https://dl.zhuanstatic.com/fecommon/liteFlow-el.zip
4 效果收益&未來規劃
通過引入流程的可視化編排，結合LiteFlow框架的支持，顯著提升了流程設計的直觀性和開發效率，為項目帶來了更為順暢和高效的開發體驗。
4.1 效果收益：
- 開發人員只需要專注于核心的業務流程設計，而無需在語法規則上耗費過多精力。
- 通過直觀的可視化流程界面，產品和研發團隊之間的溝通變得更為高效，復雜的業務邏輯能夠清晰展現，避免了不必要的溝通。
- 運營能夠實時編輯流程節點，并快速了解節點的屬性配置；例如“黑名單校驗”節點中配置了哪些用戶，從而更加靈活地管理業務流程。
4.2 未來規劃
痛點：
- 流程編排只是針對現有節點，對于新的業務節點，依然需要開發。
- 對外提供服務可能需要調用方提供較為詳盡的參數信息。
規劃：
- 希望未來借助動態腳本，實現全新業務流程的快速搭建，無需進行任何開發工作。
- 引入數據字典的概念，將常用的參數整合為數據字典，例如只需要一個訂單號，便能根據數據字典獲取該流程想要的參數，從而降低調用方的開發成本。
