1. 為什么需要工作流

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

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

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

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

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

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

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

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

2. 三大工作流

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

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

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

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

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

Activiti
Flowable
Camunda

這三個(gè)各有特點(diǎn)：

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

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

3. 流程圖

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

不是的。

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

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

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

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

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

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

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

我們一個(gè)一個(gè)來說。

事件

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

連線

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

任務(wù)

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

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

接收任務(wù)

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

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

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

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

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

腳本任務(wù)

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

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

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

用戶任務(wù)

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

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

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