網上關于工作流引擎有比較多的簡介，也有很多工作流的實際應用場景。本文結合筆者多年對工作流的經驗來闡述一下對工作流的理解。

一、什么是工作流？

先貼上wiki百科對于工作流的定義

工作流（Workflow），是對工作流程及其各操作步驟之間業務規則的抽象、概括描述。 工作流建模，即將工作流程中的工作如何前后組織在一起的邏輯和規則，在計算機中以恰當的模型表達并對其實施計算。 工作流要解決的主要問題是：為實現某個業務目標，利用計算機在多個參與者之間按某種預定規則自動傳遞文檔、信息或者任務。

那么再簡單點說，我認為工作流就是對業務的流程化抽象。WFMC給出了工作流參考模型如下：

為什么稱之為“流”，則是各個節點通過內外部驅動觸發引起節點的推進，形成一個流式的狀態達到業務終點。比如一次用戶查看淘寶商品的費用、一次支付成功后的權益開通、一次用戶注冊、一次調度任務的運行等，都是可以是一個工作流。

從代碼層面上來說，工作流是對業務邏輯代碼的按照指定的流程格式化。即原來可以用代碼直接完成的任務流程，借助工作流工具來進行標準格式化、視圖化。

另外要提一點，工作流本身是一種工程化的設計思想，在特定場景下，也是一種業務的實現方式。對于狹義的通用工程來說，工作流只是一種設計模式，或者說思維方式，不涉及任何的具體編碼，即所有業務代碼還是需要人工完成，只是用工作流的方式來規劃和編排代碼運行方式。而對于某些垂直的業務，工作流本身就是業務實現的具體方式，比如審批流的配置，可以直接通過工作流引擎的方式，直接實現配置化編排業務。

現在業務都趨于融合，所以很多工作流提供了默認的實現，也提供了自定義的實現。比如阿里巴巴旗下的業務【宜搭】就宣稱“0代碼搭建應用”。宜搭本身就是一種用工作流的思維提供的應用搭建平臺。

二、什么是工作流引擎

1、工作流引擎

我們明白為什么需要工作流以及什么是工作流的定義。那么工作流引擎則是實現驅動工作流的一套實現工具。工作流本質上是業務流的抽象，因此不同分類的業務流則形成了不同的工作流，進而有不同的工作流引擎來負責對不同類別的工作流進行具體的定義和實現。

工作流設計器，我們常說的工作流引擎，一般都包括設計器的能力，即負責對業務流程的拖拽式工具， 有插件式也有WEB云端式的。

比如我們上述的審批流，則是一種特殊的工作流，該業務流程的特點，就是需要較多的人工介入參與同意/拒絕的操作。

因此實現審批流的引擎提供的圖形化配置能力，并且具備和組織用戶直接關聯的功能及調用外部服務的能力。

上面三張分別是一個工作流引擎的插件視圖、XML源碼和編譯生成的運行代碼，可以看到通引擎，可以把視圖解析成一套簡單的可執行代碼框架，幫助編排我們自己實現所需要的業務BEAN。

通用型的工作流引擎，比較知名的有jBPM5與Activiti，阿里巴巴集團則使用tbbpm多一些。下面是國外對于常用的開源的工作流引擎的一個對比。

注1：對比數據來自：https://workflowengine.io/blog/java-workflow-engines-comparison/

2、tbbpm和activiti對比

市面上比較知名的開源工作流引擎有jbpm和acitivi。

三、為什么需要工作流

相信大家都了解流水線的好處，蒸汽時代就是將手工化轉變成了流水線化，手工有明顯的一個缺點，就是生產效率極低，而流水線則可以提高生成效率。

那么工作流則是將業務流水線化，從原來的一團處理邏輯清晰的劃分成為若干個步驟，每個步驟流轉清晰明顯。每個模塊有非常高的內聚，模塊之前有非常清晰的依賴。

外網最高的工作流的優點回答如下：
Workflows can help streamline and automate repeatable business tasks, minimizing room for errors and increasing overall efficiency. This, in turn, dramatically improves your business. Managers can make quicker, smarter decisions and employees are empowered to collaborate in a more productive and agile way.

舉個例子，退款本身非常復雜，運營、產品、技術、財務可能都無法從單一的角色來解釋清楚到底退款的整個鏈路和關鍵環節，但是通過工作流的方式來呈現，則所有人能快速看到退款到底是個什么樣的業務。

根據實際業務中對工作流的大量使用，我們總結出工作流有以下的優點：

1、業務可視化

首先，最大的優點，就是可以借助工作流引擎，讓業務可視化，可以通過視圖看到整個業務流程，每個節點執行什么業務邏輯一目了然，分支處理、異常處理也非常清晰。

如上述工作流，你一眼就看到，退款成功后該處理哪些事情。業務懂了，自然寫代碼也就更快了。

2、業務可編排

如果業務永遠不變化，那么我們硬編碼在一個方法里也無所謂。但是我們知道業務千變萬化的，軟件設計很重要的一個指標就是靈活可擴展。工作流流程的重編排，則可以使得業務進一步在代碼層面增加靈活性。可以通過節點的調整來快速調整業務流程，可以靈活增刪節點，而不至于對整個流程有影響。

還是以上面的為例，如果要增加一個【關閉用戶權益】的節點，或者刪除【用戶消息】，那么我們很容易利用工作流增刪原有流程。這里實現了代碼可維護里最核心的兩點：

改動代碼最簡單和改動代碼最快。

3、自動重試

對于某些工作流來說，工作流引擎提供了框架層面持久化和自動重試的能力。

上述是實際交易生產系統接收支付寶支付成功后回調后要處理的異步流程。而且在業務變化時，還需要對流程里動態增刪業務功能。由于像【優惠券處理】或者【活動處理】節點依賴條件較多，很可能會處理失敗需要重試，但是又不想把所有節點重試一遍，此時工作流引擎的持久化和節點重試能力，則是非常完美的方案。

四、工作流使用場景

那么適合用工作流的業務有什么特點？

1、領域業務高復雜度

對于偏向業務系統的邏輯，并且具備一定的領域專業性，比如進銷存、CRM、訂單管理等具備一定的領域復雜度的業務，可以用工作流模式，來實現業務的可視化。從全局的業務視角來觀察整體系統架構，而不至于在代碼大山面前無從下手。

2、多節點、長鏈路

比如詢價需要經過加載用戶信息、加載商品、加載優惠、計費等多個節點，每個節點都相對獨立。此類業務就比較適合用無狀態的內存工作流。

3、狀態持久化和自動重試

對于異步的調度流程，例如訂單支付成功后，驅動下游業務系統開通、發送用戶提醒消息、扣減庫存等異步流程節點，需要持久化每個節點的執行狀態，同時在流程失敗的情況下系統框架能進行重試恢復。

五、工作流分類

那么工作流該如何分類，如何抽象和歸類自身的業務？這是一個首要問題，從經驗上來看，我們把工作流按照業務特性分成了以下幾類：

1、內存工作流

內存工作流是最近簡單的一類工作流，該類工作流無需持久化，無需狀態，在內存調用完成即可。這種工作流也表示業務本身無狀態、無需持久化的。比如用戶的一次詢價行為，用戶到詳情頁查看價格和庫存，對于后端來說是一個非常復雜的調用流程，因此會把這一次調用抽象成工作流。

此類流程用硬編碼的方式也能很好的實現，但是用工作流的方式，則會使得業務可視化，從視圖上就能快速的看出業務是如何運轉的，有哪些分支等。同時也使的每個節點能夠最大程度的復用。

2、狀態機工作流

當我們需要記錄每個節點是否執行成功，并且具備系統自動重試的時候，我們就需要狀態機工作流。狀態機是在內存工作流的基礎上，增加每個節點狀態持久化，并增加重試機制。

我們以一個工作流為例，狀態機工作流的一個實例，即對應一個業務上產的流程實例，對應在market_bpm_statemachine_instance的一條記錄。

在一條實例里，記錄當前處理節點[current_node]、當前處理狀態[status]、當前節點重試次數[retry_times]、當前節點處理異常信息[error_message]以及業務主鍵ID[biz_id]。

當某個節點處理失敗后，節點置為異常狀態，工作流調度模塊會撈取失敗的節點繼續按照工作流預定義的流程重試， 直到重試到指定的配置次數后，將整個流程置為執行失敗，此時需要人工介入。

另外，一般的工作流引擎提供了默認集成的調度框架，我們也可以自己采用第三方的調度工具，只要使用IStateMachineQueryService框架內置的接口查詢出待執行的數據即可。

3、人工工作流

人工工作流，又可以認為是外部觸發驅動工作流，至少是存在一個或者多個節點是待外部確認才能推進整體業務流程。

和狀態機相比，人工工作流多了外部觸發的功能。為某一些需要外部觸發的業務提供了很好的支持，比如業務流程依賴審批的，比如退款流程，需要負責人審批通過后才能進行打款；比如報銷打款，需要財務審批成功后，才能對報銷單進行打款核銷；還有一些物流流程，用戶確認到貨后，驅動流程繼續往下走，比如提供售后服務、關閉物流單等。

以工作流為例，人工工作流的設計會稍微復雜一些，分了多個表，每個表我簡介一下其意義

bpm_workflow_instance ： 工作流實例表，表示一個具體執行的業務流 bpm_task_instance ： 任務實例，將工作流的每個節點當做一個任務實例存儲下來，描述一個工作流實例里 每個節點的具體狀態 bpm_param_instance ： 參數實例，工作流或者任務實例的上下文入參快照 bpm_timer_task：處理定時任務表，比如人工節點未審批自動超期等 bpm_sequence ：生成上述四個表的主鍵ID表

可以看到和狀態機相比，人工工作流多了對每個任務的流式快照以及定時功能，主要是解決人工等外部觸發的自動、超期等問題。

六、工作流設計準則

我們可以認為，對于復雜流式業務，面向工作流編程是一個思路，也是一個基本設計理念和方向。如何面向工作流設計？如何讓工作流更好的輔助業務編排和業務推進，則是一個需要認真思考的話題。

1、流程抽象

首要的工作，就是要把業務抽象流程化。即將業務用精簡的流程圖的方式展現出來。對業務的深刻理解，才能抽象出業務流程，包括業務鏈路、關鍵節點和分支、異常和重試邏輯、是否需要持久化、是否需要外部輸入信息。

這個環節實際上就是領域驅動設計里的，成為領域專家或者和領域業務專家對焦業務的重要部分，即深入業務，讀出業務真正的核心流程、異常流程、分支流程以及容錯流程。

這里需要對業務流程多問幾個問題，比如詢價流程里，商品加載不到怎么處理？退款流程里等待ISV確認同意退款，如果ISV一直沒有同意怎么辦？報銷流程里，審批單提交了財務人員離職了怎么辦？這些問題都思考清楚了，對整體業務流程也就有了一個全面的認識，才能清楚的定義真正的業務流程和業務流程閉環。

另外，根據業務類型，選擇是否需要持久化節點，比如用戶詢價、查看商品詳情等只讀業務，則直接采用內存式工作流；如果有持久化重試需求，比如處理支付回調消息，驅動開通用戶權益，當流程處理失敗，必須保存當前的流程快照并且需要進行重試補償，則可以選用狀態機工作流。當需要有外部用戶觸發，例如用戶審批等人工節點參與，則可以使用人工工作流。

畫出最優的業務流程圖，是工作流設計中的首要，也是最重要的一個步驟。

2、流程編排

完成業務流程產出后，就要利用工作流引擎工具提供的功能，對業務流進行具體的實現，即“流程編排”。流程編排包括幾部分：畫出工作流圖、工作流配置等。

如上述的退款業務，首先需要將業務流程化編排，抽象出核心的關鍵節點，比如【退訂判斷】，判斷是否符合退款條件，其次【更新訂單】將訂單更新為退款申請中，給用戶一個良好的體驗，然后將【訂購置為退款中】，防止退款期間系統產生新的訂單，然后【匯金申請退訂】向底層交易發起退款申請，根據底層返回成功和失敗分別做【訂單訂購恢復】的回滾操作以及【保存退款申請】的結束動作。

編排需要判斷哪些是自動節點，哪些需要用判斷節點，調用失敗如何處理等。就理論上而言，每個節點都可能執行失敗，即每個節點都可以做成判斷節點，但是這樣的缺點很明顯，主要鏈路不清晰，分支非常多，即大家會額外的去關注節點失敗的分支，盡管實際上可能無需單獨關注異常分支。

如上圖所示，同樣的一個流程，可以有兩種編排的方法，進而也導致了接口有著不同的設計。那么到底如何編排節點是最優的？有個約定的標準：

以業務流程判斷為分支節點，屏蔽系統或非預期的業務異常分支，系統或非預期的業務異常在工作流框架外統一處理

即以上述退款為例，調用訂單更新在正常情況下理論上應該一定是成功的，因此無需設計成判斷節點，可以直接設置成自動節點，當該接口發生不在預期的異常時，可以直接throw系統異常，直接在節點外進行捕獲處理。具體參考“異常處理”步驟的推薦做法。

3、接口設計

面向工作流的接口設計原則，首先滿足接口本身的設計原則“高內聚低耦合”。為了滿足節點工作流的復用性，接口盡量要保持基本入參，而不要使用復雜對象或者弱類型的MAP入參。

    /**      * 訂單置為退款中（一個不好的設計，中間的一個節點，入參采用了復雜上下文請求ProdRefundApplyRequest，其他業務無法復用）      * @return     */     
ServiceResult<Boolean> updateOrderRefunding(ProdRefundApplyRequest     prodRefundApplyRequest);

上述接口則抽象度不夠，導致調用困難（組裝ProdRefundApplyRequest上下文復雜），復用困難（其他業務可能不包含ProdRefundApplyRequest內的字段或者屬性）。

/**      * isv 確認（一個好的設計，中間的一個節點，入參采用了基本的入參，其他節點和業務可以快速復用）      *      
* @param mainOrderId 退款主訂單      
* @param opUid       
操作人uid      
* @param orgId       操作人的組織id      
* @return      * @throws ServiceException      
*/     
Boolean confirmByProvider(Long mainOrderId, Long orgId,      Long opUid) throws ServiceException;

4、異常處理

如何統一處理工作流中的異常？一般的工作流引擎工具中就設計了對異常的統一處理方式。但是還是需要接口設計本身對異常加以處理，避免對于異常的處理不合理，導致流程難以理解和捕捉。

上圖就是一個較為通用的處理辦法，工作流本身不處理業務異常，業務異常統一上拋至應用層處理。另外捕獲Exception，防止工作流本身產生的任何異常（如果工作流已經處理，則可以忽略）。

統一處理異常的優點是可以統一工作流節點錯誤實現方式，還可以打印錯誤提醒日志，方便快速定位工作流運行期間產生的異常問題。

七、總結與思考

工作流提供了一種很好的工程化的方式來解決業務問題，使得業務抽象、流程格式化、易維護和易拓展，一定程度的業務可視化。

從工程上來說，通用工作流即是一塊可同步執行或異步執行的代碼塊上，增加了格式化和視圖化。

當然，工作流設計模式也不是放之四海皆準。引入工作流本身會增加工程難度，特別是目前沒有一個非常極致體驗的工作流引擎的情況下。就筆者來說，常用的tbbpm就存在較多的問題，比如圖形拖拽不美觀、上下文變量設置麻煩、容易出異常未知問題。另外對于一些簡單的業務邏輯，幾段代碼搞定的，也無需考慮使用工作流。

工作流用的好的話，也是對整體業務思維邏輯的體現。工作流能劃清楚，至少業務已經懂了，剩下的只是擼碼問題，而擼碼是最簡單的。就好比一個算法題，設計算法是最難的，具體代碼實現則降低了一個數量級，當然，編程功底不過關的另說。

工作流用得好，從另外一個角度來說，業務可維護、業務可視化，對后來者學習和維護的成本都很低。基本上來說，用工作流設計的邏輯，很少出現翔一樣的不可維護，想打人的代碼。

工作流用的好，整個流程具備閉環，具有很強的容錯性。異常分支的考慮、錯誤節點的重試、異常節點告警、節點持久化、超時節點配置，系統就具備很強的魯棒性了。

工作流用的好，當然，下班就會更早。

總而言之，只要符合復雜領域多節點長鏈路的業務，都可以采用工作流的方式，至少，可以使用工作流的思考方式。

關注我，交流更多工作流