1. 為什么需要工作流

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

假設(shè)我有一個請假需求，流程如下：

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

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

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

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

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

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

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

2. 三大工作流

一個比較早的工作流是 jBPM，這是一個由 Java 實現(xiàn)的企業(yè)級流程引擎，是 JBoss 公司開發(fā)的產(chǎn)品之一。

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

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

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

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

• Activiti
• Flowable
• Camunda

這三個各有特點：

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

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

3. 流程圖

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

不是的。

工作流程圖這塊其實有一個統(tǒng)一的標(biāo)準(zhǔn)，那就是 BPMN。BPMN 全稱是 Business Process Model and Notation，中文譯作業(yè)務(wù)流程模型和標(biāo)記法，這個中文太繞口了，還是簡稱 BPMN 吧。

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

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

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

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

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

• 事件
• 連線
• 任務(wù)
• 網(wǎng)關(guān)

我們一個一個來說。

事件

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

連線

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

任務(wù)

任務(wù)這塊其實有很多分類。

如果細(xì)分大致上可以分為如下幾種：

• 接收任務(wù)?

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

• 發(fā)送任務(wù)

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

• 服務(wù)任務(wù)

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

• 腳本任務(wù)

一個自動化活動。當(dāng)流程執(zhí)行到腳本任務(wù)時，自動執(zhí)行相應(yīng)的腳本。

• 業(yè)務(wù)規(guī)則任務(wù)

BPMN2.0 新引入用來對接業(yè)務(wù)規(guī)則引擎，業(yè)務(wù)規(guī)則任務(wù)用于同步執(zhí)行一個或多個規(guī)則。

• 用戶任務(wù)

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

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

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

活動

活動可以算是一種特殊的任務(wù)。活動可以調(diào)用另外一個流程使之作為當(dāng)前流程的子流程去運行?；顒右部梢苑譃橛脩艋顒印⒛_本活動等等。從顯示上來說，活動比任務(wù)邊框深一些。僅此而已。

網(wǎng)關(guān)

網(wǎng)關(guān)要是細(xì)分起來，也有很多不同類型的網(wǎng)關(guān)。

• 互斥網(wǎng)關(guān)

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

• 相容網(wǎng)關(guān)

這種網(wǎng)關(guān)會有多個出口，只要條件滿足，都會執(zhí)行。

• 事件網(wǎng)關(guān)

事件網(wǎng)關(guān)是通過中間事件驅(qū)動，它在等待的事件發(fā)生后才會觸發(fā)決策。基于事件的網(wǎng)關(guān)允許基于事件作出決策。

• 并行網(wǎng)關(guān)

并行網(wǎng)關(guān)一般是成對出現(xiàn)的，上面生產(chǎn)筆記本的那個流程中，生產(chǎn)屏幕、鍵盤等并行操作，就是通過并行網(wǎng)關(guān)來實現(xiàn)的。