市場上比較有名的開源流程引擎有osworkflow、jbpm、Activiti、flowable、camunda。其中：Jbpm4、Activiti、Flowable、camunda四個框架同宗同源，祖先都是Jbpm4，開發(fā)者只要用過其中一個框架，基本上就會用其它三個。低代碼平臺、辦公自動化（OA）、BPM平臺、工作流系統(tǒng)均需要流程引擎功能，對于市場上如此多的開源流程引擎，哪個功能和性能好，該如何選型呢？

一、主流開源流程引擎介紹

1、osworkflow

Osworkflow是一個輕量化的流程引擎，基于狀態(tài)機機制，數(shù)據(jù)庫表很少，Osworkflow提供的工作流構(gòu)成元素有：步驟（step）、條件（conditions）、循環(huán)（loops）、分支（spilts）、合并（joins）等，但不支持會簽、跳轉(zhuǎn)、退回、加簽等這些操作，需要自己擴展開發(fā)，有一定難度，如果流程比較簡單，osworkflow是很好的選擇，但該開源組件已過時，長時間沒有版本升級了。

官方網(wǎng)站：http://www.opensymphony.com/osworkflow/

2、JBPM

JBPM由JBoss公司開發(fā)，目前最高版本JPBM7，不過從JBPM5開始已經(jīng)跟之前不是同一個產(chǎn)品了，JBPM5的代碼基礎不是JBPM4，而是從Drools Flow重新開始，基于Drools Flow技術(shù)在國內(nèi)市場上用的很少，所有不建議選擇jBPM5以后版本，jBPM4誕生的比較早，后來JBPM4創(chuàng)建者Tom Baeyens離開JBoss后，加入Alfresco后很快推出了新的基于jBPM4的開源工作流系統(tǒng)Activiti, 另外JBPM以hibernate作為數(shù)據(jù)持久化ORM也已不是主流技術(shù)，現(xiàn)在時間節(jié)點選擇流程引擎，JBPM不是最佳選擇。

官方網(wǎng)站：https://www.jbpm.org/

3、Activiti

activiti由Alfresco軟件開發(fā)，目前最高版本activiti 7。activiti的版本比較復雜，有activiti5、activiti6、activiti7幾個主流版本，選型時讓人暈頭轉(zhuǎn)向，有必要先了解一下activiti這幾個版本的發(fā)展歷史。activiti5和activiti6的核心leader是Tijs Rademakers，由于團隊內(nèi)部分歧，在2017年時Tijs Rademakers離開團隊，創(chuàng)建了后來的flowable, activiti6以及activiti5代碼已經(jīng)交接給了 Salaboy團隊, activiti6以及activiti5的代碼官方已經(jīng)暫停維護了, Salaboy團隊目前在開發(fā)activiti7框架，activiti7內(nèi)核使用的還是activiti6，并沒有為引擎注入更多的新特性，只是在activiti之外的上層封裝了一些應用。結(jié)論是activiti謹慎選擇。

官方網(wǎng)站：https://www.activiti.org/

4、flowable

flowable基于activiti6衍生出來的版本，flowable目前最新版本是v6.6.0，開發(fā)團隊是從activiti中分裂出來的，修復了一眾activiti6的bug，并在其基礎上研發(fā)了DMN支持，BPEL支持等等，相對開源版，其商業(yè)版的功能會更強大。以flowable6.4.1版本為分水嶺，大力發(fā)展其商業(yè)版產(chǎn)品，開源版本維護不及時，部分功能已經(jīng)不再開源版發(fā)布，比如表單生成器（表單引擎）、歷史數(shù)據(jù)同步至其他數(shù)據(jù)源、ES等。Flowable 是一個使用 Java 編寫的輕量級業(yè)務流程引擎，使用 Apache V2 license 協(xié)議開源。

2016 年 10 月，Activiti 工作流引擎的主要開發(fā)者離開 Alfresco 公司并在 Activiti 分支基礎上開啟了 Flowable 開源項目。基于 Activiti v6 beta4 發(fā)布的第一個 Flowable release 版本為6.0。Flowable 項目中包括 BPMN（Business Process Model and Notation）引擎、CMMN（Case Management Model and Notation）引擎、DMN（Decision Model and Notation）引擎、表單引擎（Form Engine）等模塊。

官方網(wǎng)站：https://flowable.com/open-source/

5、Camunda

Camunda基于activiti5，所以其保留了PVM，最新版本Camunda7.15，保持每年發(fā)布2個小版本的節(jié)奏，開發(fā)團隊也是從activiti中分裂出來的，發(fā)展軌跡與flowable相似，同時也提供了商業(yè)版，不過對于一般企業(yè)應用，開源版本也足夠了，強烈推薦camunda流程引擎，功能和性能表現(xiàn)穩(wěn)定。

選擇camunda的理由：

（1）通過壓力測試驗證Camunda BPMN引擎性能和穩(wěn)定性更好。

（2）功能比較完善，除了BPMN，Camunda還支持企業(yè)和社區(qū)版本中的CMMN（案例管理）和DMN（決策自動化）。Camunda不僅帶有引擎，還帶有非常強大的工具，用于建模，任務管理，操作監(jiān)控和用戶管理，所有這些都是開源的。

官方網(wǎng)站：https://docs.camunda.org/manual/7.15/introduction/

二、flowable與Camunda對比分析

1、功能方面對比

由于Flowable與Camunda好多功能都是類似的，因此在這里重點羅列差異化的功能

（1）camunda支持流程實例的遷移，比如同一個流程有多個實例，多個流程版本，不同流程實例運行在不同的版本中，camunda支持任意版本的實例遷移到指定的流程版本中，并可以在遷移的過程中支持從哪個節(jié)點開始。

（2）camunda基于pvm技術(shù)，所以用戶從Activii5遷移到camunda基本上毫無差異。flowable沒有pvm了，所以遷移工作量更大（實例的遷移，流程定義的遷移、定時器的遷移都非常麻煩）。

（3） camunda對于每一個CMD命令類都提供了權(quán)限校驗機制，flowable沒有。

（4）camunda繼續(xù)每一個API都有批處理的影子，flowable幾乎沒有。比如批量掛起流程、激活流程等，使用camunda可以直接使用API操作，使用Flowable則只能自己去查詢集合，然后循環(huán)遍歷集合并操作。

（5）camunda很多API均支持批處理，在批量處理的時候可以指定是異步方式操作或者是同步方式操作。異步的話定時器會去執(zhí)行。Flowable沒有異步批處理的機制。比如批量異步刪除所有的歷史數(shù)據(jù)。

（6）camunda啟動實例的時候支持從哪個節(jié)點開始，而不是僅僅只能從開始節(jié)點運轉(zhuǎn)實例。Flowable僅僅只能從開始節(jié)點運轉(zhuǎn)實例。

（7）camunda支持任意節(jié)點的跳轉(zhuǎn)，可以跳轉(zhuǎn)到連線也可以跳轉(zhuǎn)到節(jié)點，并且在跳轉(zhuǎn)的過程中支持是否觸發(fā)目標節(jié)點的監(jiān)聽器。flowable沒有改原生API需用戶去擴展。

（8）camunda支持雙異步機制，第一個異步即節(jié)點可以異步執(zhí)行，第二個異步方式是：完成異步任務后，還可以繼續(xù)異步去執(zhí)行任務后面的連線。所以稱之為雙異步機制，flowable只有第一種異步方式。

（9）camunda支持多種腳本語言，這些腳本語言可以在連線上進行條件表達式的配置，開箱即用。比如python、ruby、groovy、JUEL。flowable僅僅支持JUEL、groovy。開箱即用的意思就是如果想用python直接引入jython包就可以用了，不需要額外配置。

（10）camunda支持外部任務，比如我們有時候想在一個節(jié)點中執(zhí)行調(diào)用第三方的API或者完成一些特定的邏輯操作，就可以使用外部任務，外部任務有兩種表，并支持第三方系統(tǒng)定期來抓取并鎖定外部任務，然后執(zhí)行業(yè)務完畢之后，完成外部任務，流程實例繼續(xù)往下執(zhí)行。外部任務的好處就是解決了分布式事物的問題。在flowable中我們可以使用httpTask任務，我個人更傾向于camunda外部任務，因為這個外部任務有外部系統(tǒng)決定什么時候完成，httpTask是不等待任務，實例走到這個節(jié)點之后，調(diào)用一個api就直接往下跑了，外部任務不會繼續(xù)往下跑，有外部系統(tǒng)去決定啥時候往下跑。

（11）camunda支持為用戶定制一些個性化的偏好查找API，比如張三每次查詢?nèi)蝿盏臅r候，一般固定點擊某某三個查詢條件過濾數(shù)據(jù)，使用camunda就可以將這三個查詢條件進行持久化，下次張三來了，就可以直接根據(jù)他的偏好進行數(shù)據(jù)的過濾，類似機器學習。

（12）camunda支持歷史數(shù)據(jù)的批量刪除或者批量遷移到其他介質(zhì)，比如批量遷移到es，flowable沒有該機制。

（13）camunda支持在高并發(fā)部署流程的時候，是否使用鎖機制，flowable沒有該機制。

（14） camunda支持單引擎多組合、多引擎多庫。flowable僅僅支持單引擎多組合。

（15） camunda支持流程實例跨流程定義跳轉(zhuǎn)，flowable沒有該機制。

（16） camunda支持分布式定時器，flowable沒有該機制。

（17） flowable支持nosql,camunda只有nosql的解決方案。

（18）camunda支持優(yōu)化流程，以及了解流程引擎的瓶頸所在和每個環(huán)節(jié)的耗時，flowable沒有該機制。

（19） camunda修改了流程模板xml解析方式，相比flowable性能更好。

（20）camunda在解析流程模板xml的時候，去除了activiti5的雙解析機制，相對而言耗時時間更短。flowable沒有了pvm所以規(guī)避了雙解析機制。

（21）camunda可以在任意節(jié)點添加任意的屬性，flowable原生API沒有，需要自己擴展。

（22）camunda框架沒有為流程生成圖片的API(所有流程圖展示以及高亮均在前端動態(tài)計算)，activiti5/6/flowable5/flowable6有圖片生成以及高亮的API.

（23）camunda可以在節(jié)點中定義定時作業(yè)的優(yōu)先級，也可以在流程中進行全局優(yōu)先級的定義。當節(jié)點沒有定義優(yōu)先級的時候可以使用全局的優(yōu)先級字段。activiti5/6/flowable5/flowable6沒有該功能。

（24）camunda可以在流程中定義流程的tag標記，activiti5/6/flowable5/flowable6沒有改功能。

（25）camunda/activiti5/6/flowable5/flowable6 均不支持國產(chǎn)數(shù)據(jù)庫，比如人大金倉 和 達夢。

（26）flowable6支持LDAP，openLDAP,camunda不支持。activiti5不支持。

2、性能方面對比

筆者通過flowable和camunda多組對比測試，camunda性能比flowablet提升最小10%，最大39%，而且camunda無報錯，flowable有報錯，camunda在高并發(fā)場景下穩(wěn)定性更好。

性能測試詳細文章見：https://lowcode.blog.csdn.net/article/details/109030329

三、選型推薦

推薦大家使用camunda（流程引擎） bpmn-js（流程設計器）組合，筆者在多個項目中經(jīng)過實戰(zhàn)驗證，camunda在功能方面比flowable、activiti流程引擎強大，性能和穩(wěn)定性更突出。基于camunda流程引擎的體驗環(huán)境：http://www.yunchengxc.com