構建企業數字化轉型之某大廠審批流引擎核心技術揭秘

1. 定義

企業數字化轉型的道路上，必不可少的一項就是審批流程的線上化，都需要搭建自己的審批系統，而審批系統的核心就是審批流引擎

什么是審批流引擎呢？

是一個工具包，用來驅動審批類業務的執行，通過使用這個引擎，可以方便快速的實作各類審批相關的功能，如：審批、同意、或簽、并簽、串簽、拒絕、駁回、回退到任意節點、前加簽、后加簽、平行加簽、平行減簽、外部呼叫節點、抄送、填寫、主子流程、分支、選擇、流程預測、流程仿真、取回、撤銷、傳閱、以及各種加減簽與或并簽的任意嵌套，

2. 現有技術

業內的現有技術一般分為三大派系，一個是直接使用開源的作業流引擎作為審批流引擎，一個是在開源的作業流引擎的基礎之上進行的二次開發，最后一個是完全的自研

2.1 開源的作業流引擎

這種技術的一個基本的邏輯就是把作業流引擎當做審批流引擎來使用，常見的就是activiti，也有flowable、camunda，但由于它們二者都是直接或間接來自于actitivi，雖然做了一些改進，但區別不是很大，

以activti為例，一個典型的技術架構如下圖所示：

實踐中，使用BPMN2.0協議作為審批流流程定義的載體，使用activiti作業流引擎決議并執行這個流程，引擎通過回呼的方式來執行自定義的審批業務，審批業務通過API的方式來呼叫引擎，如此回圈，直到結束，需要注意的是，Client可以呼叫其中的任何一層

這種技術優缺點如下

優點：

• 開源的多年成熟技術
• 檔案資料比較多

缺點：

• 對絕大部分審批業務沒有直接的API或回呼支持，需要自己開發
• 一些復雜的場景，如：或并簽與加減簽的無限嵌套，支持的力度非常的弱，有時需要繞過作業流引擎，而去直接修改資料庫本身，這樣帶來的危害是比較大的
• 開源的代碼量巨大，50W行左右，遇到一些棘手的問題，又找不到資料，必需看原始碼找問題的時候，會非常非常的痛苦，對開發不友好，學習成本高
• 與BPMN協議依賴性較強，因審批流協議與BPMN協議的交集較小，需要BPMN協議的擴展功能來表達審批流語意，導致語意含糊，表達力不強

從根本上來說，直接把作業流引擎當做審批流引擎是混淆了作業流與審批流的概念，把一些審批流的邏輯范疇強行加到作業流上，把個性當共性，最終導致了復雜性的爆炸，審批業務做的不倫不類，無法做大做強，

2.2 二次開發

這種技術是在開源的作業流引擎的基礎之上進行的二次開發，把activiti之流當做底層的技術底座，進行了一些封裝，一般的技術架構如下圖所示：

使用的時候，Client直接呼叫審批流API介面，然后進行相應的邏輯處理，最后呼叫作業流引擎，完成整個流程

這種技術優缺點如下

優點：

• 屏蔽了底層技術細節，介面對使用者友好
• 對大部分審批業務提供了直接的支持

缺點：

• 因其技術底座使用了activiti之流，故其帶來的困擾一點沒有減少，直接對引擎的維護者不友好，間接提高BUG率，進而影響上層業務，不穩定性增大
• 對一些特定的RDBMS的支持較差，如：達夢國產資料庫、自研的記憶體資料庫，需要做大量的二次開發，修改底層源代碼
• 對資料庫的異構性支持幾乎沒有，會直接影響本地事務的一致性

2.3 自研

每一家的解決方案各自不同，使用的技術底座不同，協議不同，持久化機制不同，介面引數不同，但一個相同的邏輯就是有針對性的對審批業務提供了直接的支持，不在混淆作業流與審批流的概念，對開發更加的友好，開發更加的簡單，同時對現有的審批業務的范疇之內，提供了一些擴展能力，雖然有上述優點，缺點也不容易忽視，如下：

• 如果審批業務有了進化，提出了一些新的概念，而擴展性又覆寫不到的話，那么就需要開發引擎本身來進行支持，這對于軟體的分發、升級、部署、資料一致性方面提出了挑戰
• 與某一持久化機制強系結，無論是RDBMS、KV還是檔案，顯得很笨重，集成的時候，會引起與現有基礎設施不一致的問題，很是麻煩

3. 我們的技術

我們采用的是自研的方式，走了一條很不一樣的技術路線，完全自研了作業流引擎框架，在這基礎之上，構建了自己的審批流引擎，具有如下的特點：

• 與審批業務強耦合，開箱即用
• 使用簡單，貧血模型，無狀態依賴
• 本身代碼量少，1W行左右，易于維護
• 只是一個jar包，可嵌入到任何業務系統中
• 不依賴具體的資料庫，無論關系型的還是非關系型的，對持久化提供了擴展
• 不依賴某一個流程協議，如：BPMN，而是使用類似流程虛擬機的形式，對審批流定義本身提供了支持
• 可擴展自己業務特定的流程節點
• 可擴展自己業務特定的執行人指定邏輯
• 可擴展自己業務特定的流程流轉事件
• 依賴少，只依賴slf4j、kryo等必要組件,不依賴任何作業流引擎，如：activiti、flowable等
• 可以方便的集成進Spring MVC，Spring Boot等
• 可以方便的控制本地事務、事務集成等
• 可運行時確定具體審批人，而不是在定義期
• 擴展性合適，既不是什么都可以擴展，也不是什么都不可以擴展，即：只擴展那些與審批相關的點

下面詳細闡述我們是怎么實作的......

3.1 理論基礎

作業流引擎的兩大模塊，一個是流程定義，一個是流程執行

現有的流程定義都是使用BPMN協議進行描述，這個協議實在是太龐大了，本著第一性原理，我們對作業流引擎的本質進行了深入的挖掘，重新對作業流進行了定義，提出了元模式的概念，

具體來講，詳細研究了43種作業流控制模式，這些作業流控制模式的組合基本上就能覆寫住絕絕絕大多數作業流場景，一般來講，對43種直接進行支持就可以了，但43種未免也有些過多，加上以后也會出現有44、45、46種模式，所以我們更進一步的對這43種進行泛化與抽象，最終得出了6種作業流控制元模式，通過這6種元模式的組合與API呼叫，就能夠直接或間接支持43種控制模式，同時，對未來出現的模式也有一定的支持，這6種為：

• 事件：事用來表示發送一個事件，也可以表示等待接收一個事件，事件是廣播的方式傳播的
• 活動：泛指各類活動任務，如：人工任務、腳本任務、服務任務、用戶任務、審批節點任務等，是與各個業務相關聯的
• 子流程：也是一個流程，用來重用或消除重復、或者減少主流程的復雜性
• 分裂：所有需要并行做的事情，都要用此元素，這里并不規定分裂邏輯，以及分裂后的分支的數目
• 匯聚：同步并行分支，在此之后，多條分支合并為一條，這里也并不規定同步邏輯，以及多次同步的方法
• 流轉：以上五種元素的流轉方向，一個源，一個目標，流程從源流轉到目標

如下圖所示：

對于流程執行來講，業內一般采用以下兩種技術：

• 基于FSM的技術：由于FSM天生的缺陷，對于狀態的擴展能力較弱，應用面較窄，只能在特定業務領域有較好的落地應用
• 基于Token的技術：市面上最主流的技術，優點是理論模型較健全，缺點是落地較復雜，實作繁瑣，理解起來較困難

我們使用的并不是二者之一，而是基于無限狀態機模型的一種技術實作，如下圖：

這種技術的本質是個回圈，其設計靈感來自于CPU的執行邏輯，不斷的讀取狀態，接下來對狀態進行處理，處理的結果也是一個狀態，然后繼續，直到沒有狀態或狀態暫時無法處理，這里面還有個類似與中斷的喚醒狀態的邏輯，鑒于保密原則，此處不在展開

有了這些理論基礎，接下來就是落地實作了

3.2 作業流引擎框架

在落地實作的程序中，我們發現各種垂直業務領域的作業流都有著一些共性，同時也有著一些個性，而且，這些共性是框架維度的，并不是庫維度的，因此，我們對此進行了抽象，提出了作業流引擎框架的概念，具體來講，它是作業流引擎的模板，通過使用這個框架，可以快速的開發實作各種業務域的“作業流”引擎，包括審批領域的審批流引擎、任務領域的任務流引擎、采購領域的采購流引擎等，它提供了基本的流程定義與流程執行能力，及其強大的擴展能力

有別于傳統的作業流引擎，它們對特定業務領域(如：審批流、任務流)的直接支持實在是太弱了，根本原因在于它們太通用了，通用到了為了支持各種作業流場景，把一塊木板變成了木削，以至于當我要制造一個柜子的時候，需要從木削開始加工，這極大的增加了作業量，在加上學習成本，可以說，這不是在提高效率，而是在降低效率，所以，一般來講，通用性越強，適用性越低，反之亦然，

具體到實作層面，框架一共分為兩層

第一層為ISM，也就是無限狀態機，是個微內核，其概念模型如下圖所示

Func是一個狀態轉換器，其有兩個方法，一個是transfer()，用來消費一個State，然后，生產一個State，另一個是eventHandle，用來消費一個訊息，然后生產一個State；Funs維護著Func；Case是一個實體，其內部維護著所有的狀態(State)，記錄著狀態變化的歷史，每一個狀態包含：

• id：唯一標識本狀態
• tobeStarted：需要對本狀態進行處理的Func集合
• ing：進行中的Func集合
• toIngMsg：給進行中的Func發的訊息
• alreadySend：已經處理完訊息的Func集合

第二層為PVM，也就是流程虛擬機，通過這個虛擬機可以進行流程定義、流程執行、與中斷喚醒等操作，如下圖所示

流程定義(Definition)繼承了Funcs，從而有了管理Func的能力，流程中的節點(Node)繼承了Func，從而有了消費與產出State的基本能力；由Transition來表示兩個節點之間的流轉，指定了來源節點與目標節點；流程實體(Instance)，使用了流程定義，從而可以據此來發起一個流程，同時，也使用了Case，進行流程實體的流轉；對于節點來說，具象化了作業流領域內的常用的一些節點及其對狀態的處理邏輯，包括：

• 活動節點Activity，以及以此為基礎的子流程節點SubProcess
• 并發分裂網關Fork，以及與其配套使用的同步匯聚網關Join
• 事件節點Event，以及其兩個重用分類，發送事件節點TxEvent，及其派生類EndEvent，接收事件節點RxEvent，及其派生類StartEvent

有了這個框架之后，就具備了基本的作業流流程定義與執行能力，能夠通過此來開發上層的審批領域的審批流引擎了

3.3 審批流引擎

審批流引擎設計到的點非常多，由于篇幅所限，這里只分享最重要幾點

第一個是在審批流流程定義層面，我們繼承了Activity節點，派生出了審批節點、抄送節點、填寫節點等

第二個是在API層面，我們直接提供了審批、同意、或簽、并簽、串簽、拒絕、駁回、回退到任意節點、前加簽、后加簽、平行加簽、平行減簽、外部呼叫節點、抄送、填寫、主子流程、分支、選擇、流程預測、流程仿真、取回、撤銷、傳閱等方法，可以直接呼叫

第三個是在流程執行層面，整個流程是個PVM，每個審批節點內部也有個PVM，這么做的目的是因為審批業務的復雜性，同時也是一種現有能力的復用，由于PVM的足夠輕量，使得這種模式成為了可能，如下圖所示：

第四個是在流轉層面，每一次流轉的前后變化都存盤在一個背景關系中，通過對比前后變化，就能夠得到一些資訊，包括：

• 哪些節點已經開始執行了
• 哪些節點已經完成了，包括取消
• 哪些任務生成了
• 哪些任務完成了，包括取消

從而，可以據此資訊來進行下一步的處理，如：持久化、回退等

第五個是通過訪問者模式，提供了對流程定義合法性的發起前的檢查能力，同時提供了一些默認實作，也可自行擴展

第六個是直接提供了流程預測的方法，該方法實作的內在邏輯為：在記憶體中模擬整個流程的流轉，把其中涉及到的一些預測資訊存盤在一個Map中，這種方法有別于傳統的使用資料庫的方式，即快又不污染資料庫中的資料，同時也可并行執行，在預測程序中，不會阻塞正常流程的流轉

第七個是在節點擴展性方面，可以通過派生自審批節點的方式自行擴展自己特定審批邏輯的審批節點，也可通過派生自Activity、甚至是Func的方式，來擴展特定功能的節點

第八個是在分支條件運算式方面，對具體的運算式語法、語言進行了解耦，由其具體的運算式決議類進行運算式的決議，只要把Bool結果告知引擎即可

第九個是對流程實體變數的榷訓，榷訓為一個Map，這樣可以表達更多的資訊

4. 未來展望

• 在完善審批流引擎本身能力的同時，提供豐富的檔案與示例，方便大家使用
• 基于審批流引擎，研發下一代審批流系統+，提供完善的集成能力，同時提供一些通用作業流能力
• 建設審批流前端頁面組件能力，方便流程定義等前端復雜功能的實作

標籤：其他

上一篇：面向物件編程，不美了么？

下一篇：href標簽破壞了Vue模板組件