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

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

1、Osworkflow

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

官方網站：
http://www.opensymphony.com/osworkflow/

2、JBPM

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

官方網站：https://www.jbpm.org/

3、Activiti

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

官方網站：https://www.activiti.org/

4、flowable

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

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

官方網站：
https://flowable.com/open-source/

5、Camunda

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

選擇camunda的理由：

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

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

官方網站：
https://docs.camunda.org/manual/7.15/introduction/

二、flowable與Camunda對比分析

1、功能方面對比

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

（18）camunda支持優化流程，以及了解流程引擎的瓶頸所在和每個環節的耗時，flowable沒有該機制。

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

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

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

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

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

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

（25）
camunda/activiti5/6/flowable5/flowable6 均不支持國產數據庫，比如人大金倉 和 達夢。

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

2、性能方面對比

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

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

三、選型推薦

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