1. 為什么需要工作流

松哥將之前的文章轉發到朋友圈后，有小伙伴評論說一直不理解為什么需要工作流，今天我們就先來說說這個話題。

假設我有一個請假需求，流程如下：

請假可以提交給我的上司，上司可以選擇批準或者拒絕，無論批準還是拒絕，都會給我一個通知。

這個流程比較簡單，我們很容易想到解決方案，不用工作流也能解決，有一個專門的請假表，當 A 要請假的時候，就往請假表中添加一條記錄，這條記錄的內容包含了請假的天數、原因、請假的審批人 B 以及一個名為 status 的字段，這個 status 字段表示這個請假申請目前的狀態（待審批、已批準還是已拒絕），然后 B 登錄系統之后，在請假表中查詢到了 A 的請假信息，然后選擇批準，此時將 status  字段的值改一下就行了。

這個流程很簡單，相信小伙伴們都能想到。

然而，這是一個非常簡單的流程，對于這樣的流程，一般來說也確實沒有必要使用工作流，但是現實中，我們涉及到的工作流往往都是非常復雜的，我舉個例子，就說報銷審批吧，這個可能很多小伙伴都經歷過。

小伙伴們看到，這個流程相對來說還是比較復雜的，此時你再用一個 status 字段去描述，就很難說的請到底是怎么回事了。每一步審批，都有可能批準也有可能拒絕，拒絕并不意味著流程結束，員工修改報銷資料之后，還可以繼續提交。此時如果還用 status 去描述，那么 status 將有 N 多個值去表示不同的情況，這個維護起來非常不便。

這就復雜了嗎？非也非也，我們再來看一個生產筆記本電腦的例子，假設公司研發了一款新型筆記本電腦，整個研發到生產的流程可能是這樣：

相比上面兩個，這個就更復雜一些了，不僅有串行任務還有并行任務，如何去設計這樣一個系統？單純的通過狀態字段去描述顯然已經不夠用了，此時我們就得考慮一種通用的、更易維護的方案來實現這樣的系統了，這種通用的、易維護的方案，也就是工作流。

2. 三大工作流

一個比較早的工作流是 jBPM，這是一個由 Java 實現的企業級流程引擎，是 JBoss 公司開發的產品之一。

jBPM 的創建者是 Tom Baeyens，這個大佬后來離開了 JBoss，并加入到 Alfresco，并推出了基于 jBPM4 的開源工作流系統 Activiti，而 jBPM 則在后續的代碼中完全放棄了 jBPM4 的代碼。從這個過程中也能看出來，jBPM 在發展過程中，由于意見相左，后來變成了兩個 jBPM 和 Activiti。

然而戲劇的是，Activiti5 沒搞多久，從 Activiti 中又分出來一個 Camunda，Activiti 繼續發展，又從中分出來一個 Flowable。。。

由于開發 jBPM、Activiti、Camunda 以及 Flowable 的人多多少少有一些關聯性，讓人不得不猜測意見相左拉一票人出來單干是他們的企業文化。

所以現在市面上主流的流程引擎就一共有三個：

• Activiti
• Flowable
• Camunda

這三個各有特點：

• Activiti 目前是側重云，他目前的設計會向 Spring Cloud、Docker 這些去靠攏。
• Flowable 核心思想還是在做一個功能豐富的流程引擎工具，除了最最基礎的工作流，他還提供了很多其他的擴展點，我們可以基于 Flowable 實現出許多我們想要的功能（當然這也是小伙伴們覺得 Flowable 使用復雜的原因之一）。
• Camunda 相對于前兩個而言比較輕量級，Camunda 有一個比較有特色的功能就是他提供了一個小巧的編輯器，基于 bpmn.io 來實現的（松哥之前已經發文講過了）。如果你的項目需求是做一個輕巧的、靈活的、定制性強的編輯器，工作流是嵌入式的，那么可以選擇 Camunda。

如果仔細比較起這三個的差異，能列一個長長的表格，這個網上也有不少人都總結過了，松哥這里也就不啰嗦了。

3. 流程圖

既然有三個不同的工作流，那么三個不同的工作流畫出來的流程圖是否都各不相同呢？

不是的。

工作流程圖這塊其實有一個統一的標準，那就是 BPMN。BPMN 全稱是 Business Process Model and Notation，中文譯作業務流程模型和標記法，這個中文太繞口了，還是簡稱 BPMN 吧。

這是一套圖形化表示法，用圖形來表示業務流程模型。BPMN 最初由業務流程管理倡議組織（BPMI, Business Process Management Initiative）開發，BPMI 于 2005 年與對象管理組織（OMG, Object Management Group）合并，并于 2011 年 1 月 OMG 發布 2.0 版本，同時改為現在的名稱。

一句話，就是流程圖這塊有一個特別古老的規范，那就是 BPMN，而我們前面所說的無論是 Activiti、Flowable 還是 Camunda，都是支持這個規范的，所以呢，無論你使用哪一個流程引擎，都可以使用同一套流程圖。

那么這個規范究竟都說了些什么事情呢？

我們以上面生產筆記本的流程圖為例，來和小伙伴們做一個簡單介紹：

從上圖中可以看到，一個流程圖中主要包含四方面的內容：

• 事件
• 連線
• 任務
• 網關

我們一個一個來說。

事件

首先在一個流程圖中應該有開始事件和結束事件，也就是上圖大家看到的兩個圓圈。另外還有一些中間事件、邊界事件等。舉個中間定時事件的例子，比如用戶下單之后，可以有一個中間定時事件，延遲 5 分鐘發貨。

連線

連線就是將事件、任務、網關等連在一起的線條，一般情況下就是普通連線，有的時候連線會有一些條件，例如松哥之前文章和大家分享的請假，如果經理同意請假申請，就走哪一個線條，如果經理不同意請假申請，就走哪一個線條。對應上圖的筆記本生產，如果經理審批通過，就載入圖紙準備生產，如果經理審批不通過，就重新設計。

任務

任務這塊其實有很多分類。

如果細分大致上可以分為如下幾種：

• 接收任務?

在上面的流程圖中，等待準備工作完成這一項就是一個接收任務。這個任務里并不需要額外做什么事情，流程到這一步就自動停下來了，需要人工去點一下，推動流程繼續向下執行。

• 發送任務

這個一般用來把消息發送給外部參與者。

• 服務任務

這個一般由系統自動完成，其實說白了就是我們的一個自定義類，可以在一個自定義類里邊完成想要做的事情。

• 腳本任務

一個自動化活動。當流程執行到腳本任務時，自動執行相應的腳本。

• 業務規則任務

BPMN2.0 新引入用來對接業務規則引擎，業務規則任務用于同步執行一個或多個規則。

• 用戶任務

用于為那些需要由人工參與者完成的工作建模。

雖然細分類別很多，但是仔細看，其實這幾種又可以歸為兩大類：

• 用戶任務：表示人工要介入做的事情。比如同意與否，或者輸入一些參數，要讓人工完成任務，就需要一個表單系統，讓人工輸入數據，或者顯示數據給人看，這也是為什么用戶任務和表單系統結合在一起的原因，用戶任務需要用戶向引擎提交一個完成任務的動作，否則流程會暫停在這里等待。
• 服務任務：表示機器自動做的事情。調用服務的任務，這個服務可以是一個 Spring JavaBean，也可以是一個遠程 REST 服務，流程會自動執行服務任務。

活動

活動可以算是一種特殊的任務。活動可以調用另外一個流程使之作為當前流程的子流程去運行。活動也可以分為用戶活動、腳本活動等等。從顯示上來說，活動比任務邊框深一些。僅此而已。

網關

網關要是細分起來，也有很多不同類型的網關。

• 互斥網關

這種網關也叫排他性網關，我們之前請假流程中的那個網關，就是互斥網關。這種網關有且僅有一個有效出口。

• 相容網關

這種網關會有多個出口，只要條件滿足，都會執行。

• 事件網關

事件網關是通過中間事件驅動，它在等待的事件發生后才會觸發決策。基于事件的網關允許基于事件作出決策。

• 并行網關

并行網關一般是成對出現的，上面生產筆記本的那個流程中，生產屏幕、鍵盤等并行操作，就是通過并行網關來實現的。