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

一、什么是工作流？

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

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

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

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

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

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

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

二、什么是工作流引擎

1、工作流引擎

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

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

比如我們上述的審批流，則是一種特殊的工作流，該業(yè)務流程的特點，就是需要較多的人工介入?yún)⑴c同意/拒絕的操作。

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

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

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

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

2、tbbpm和activiti對比

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

三、為什么需要工作流

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

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

外網(wǎng)最高的工作流的優(yōu)點回答如下：
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.

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

根據(jù)實際業(yè)務中對工作流的大量使用，我們總結出工作流有以下的優(yōu)點：

1、業(yè)務可視化

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

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

2、業(yè)務可編排

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

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

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

3、自動重試

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

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

四、工作流使用場景

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

1、領域業(yè)務高復雜度

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

2、多節(jié)點、長鏈路

比如詢價需要經(jīng)過加載用戶信息、加載商品、加載優(yōu)惠、計費等多個節(jié)點，每個節(jié)點都相對獨立。此類業(yè)務就比較適合用無狀態(tài)的內(nèi)存工作流。

3、狀態(tài)持久化和自動重試

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

五、工作流分類

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

1、內(nèi)存工作流

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

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

2、狀態(tài)機工作流

當我們需要記錄每個節(jié)點是否執(zhí)行成功，并且具備系統(tǒng)自動重試的時候，我們就需要狀態(tài)機工作流。狀態(tài)機是在內(nèi)存工作流的基礎上，增加每個節(jié)點狀態(tài)持久化，并增加重試機制。

我們以一個工作流為例，狀態(tài)機工作流的一個實例，即對應一個業(yè)務上產(chǎn)的流程實例，對應在market_bpm_statemachine_instance的一條記錄。

在一條實例里，記錄當前處理節(jié)點[current_node]、當前處理狀態(tài)[status]、當前節(jié)點重試次數(shù)[retry_times]、當前節(jié)點處理異常信息[error_message]以及業(yè)務主鍵ID[biz_id]。

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

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

3、人工工作流

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

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

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

bpm_workflow_instance ： 工作流實例表，表示一個具體執(zhí)行的業(yè)務流 bpm_task_instance ： 任務實例，將工作流的每個節(jié)點當做一個任務實例存儲下來，描述一個工作流實例里 每個節(jié)點的具體狀態(tài) bpm_param_instance ： 參數(shù)實例，工作流或者任務實例的上下文入?yún)⒖煺?bpm_timer_task：處理定時任務表，比如人工節(jié)點未審批自動超期等 bpm_sequence ：生成上述四個表的主鍵ID表

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

六、工作流設計準則

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

1、流程抽象

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

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

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

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

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

2、流程編排

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

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

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

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

以業(yè)務流程判斷為分支節(jié)點，屏蔽系統(tǒng)或非預期的業(yè)務異常分支，系統(tǒng)或非預期的業(yè)務異常在工作流框架外統(tǒng)一處理

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

3、接口設計

面向工作流的接口設計原則，首先滿足接口本身的設計原則“高內(nèi)聚低耦合”。為了滿足節(jié)點工作流的復用性，接口盡量要保持基本入?yún)?#xff0c;而不要使用復雜對象或者弱類型的MAP入?yún)ⅰ?/p> /** * 訂單置為退款中（一個不好的設計，中間的一個節(jié)點，入?yún)⒉捎昧藦碗s上下文請求ProdRefundApplyRequest，其他業(yè)務無法復用） * @return */ ServiceResult<Boolean> updateOrderRefunding(ProdRefundApplyRequest prodRefundApplyRequest);

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

/** * isv 確認（一個好的設計，中間的一個節(jié)點，入?yún)⒉捎昧嘶镜娜雲(yún)?#xff0c;其他節(jié)點和業(yè)務可以快速復用） * * @param mainOrderId 退款主訂單 * @param opUid 操作人uid * @param orgId 操作人的組織id * @return * @throws ServiceException */ Boolean confirmByProvider(Long mainOrderId, Long orgId, Long opUid) throws ServiceException;

4、異常處理

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

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

統(tǒng)一處理異常的優(yōu)點是可以統(tǒng)一工作流節(jié)點錯誤實現(xiàn)方式，還可以打印錯誤提醒日志，方便快速定位工作流運行期間產(chǎn)生的異常問題。

七、總結與思考

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

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

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

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

工作流用得好，從另外一個角度來說，業(yè)務可維護、業(yè)務可視化，對后來者學習和維護的成本都很低?；旧蟻碚f，用工作流設計的邏輯，很少出現(xiàn)翔一樣的不可維護，想打人的代碼。

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

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

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

關注我，交流更多工作流

總結

以上是生活随笔為你收集整理的java 审批流_一文读懂工作流的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。