From: https://mp.weixin.qq.com/s?__biz=MzI4Njc5NjM1NQ==&mid=2247551521
市場上比較有名的開源流程引擎有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好多功能都是類似的，因此在這裏重點羅列差異化的功能
-
camunda支持流程實例的遷移，比如同一個流程有多個實例，多個流程版本，不同流程實例運行在不同的版本中，camunda支持任意版本的實例遷移到指定的流程版本中，並可以在遷移的過程中支持從哪個節點開始。
-
camunda基於PVM技術，所以用戶從Activii5遷移到camunda基本上毫無差異。flowable沒有pvm了，所以遷移工作量更大（實例的遷移，流程定義的遷移、定時器的遷移都非常麻煩）。
-
camunda對於每一個CMD命令類都提供了權限校驗機制，flowable沒有。
-
camunda繼續每一個API都有批處理的影子，flowable幾乎沒有。比如批量掛起流程、激活流程等，使用camunda可以直接使用API操作，使用Flowable則只能自己去查詢集合，然後循環遍歷集合並操作。
-
camunda很多API均支持批處理，在批量處理的時候可以指定是異步方式操作或者是同步方式操作。異步的話定時器會去執行。Flowable沒有異步批處理的機制。比如批量異步刪除所有的歷史數據。
-
camunda啓動實例的時候支持從哪個節點開始，而不是僅僅只能從開始節點運轉實例。Flowable僅僅只能從開始節點運轉實例。
-
camunda支持任意節點的跳轉，可以跳轉到連線也可以跳轉到節點，並且在跳轉的過程中支持是否觸發目標節點的監聽器。flowable沒有改原生API需用戶去擴展。
-
camunda支持雙異步機制，第一個異步即節點可以異步執行，第二個異步方式是：完成異步任務後，還可以繼續異步去執行任務後面的連線。所以稱之爲雙異步機制，flowable只有第一種異步方式。
-
camunda支持多種腳本語言，這些腳本語言可以在連線上進行條件表達式的配置，開箱即用。比如python、ruby、groovy、JUEL。flowable僅僅支持JUEL、groovy。開箱即用的意思就是如果想用python直接引入jython包就可以用了，不需要額外配置。
-
camunda支持外部任務，比如我們有時候想在一個節點中執行調用第三方的API或者完成一些特定的邏輯操作，就可以使用外部任務，外部任務有兩種表，並支持第三方系統定期來抓取並鎖定外部任務，然後執行業務完畢之後，完成外部任務，流程實例繼續往下執行。外部任務的好處就是解決了分佈式事物的問題。在flowable中我們可以使用httpTask任務，我個人更傾向於camunda外部任務，因爲這個外部任務有外部系統決定什麼時候完成，httpTask是不等待任務，實例走到這個節點之後，調用一個api就直接往下跑了，外部任務不會繼續往下跑，有外部系統去決定啥時候往下跑。
-
camunda支持爲用戶定製一些個性化的偏好查找API，比如張三每次查詢任務的時候，一般固定點擊某某三個查詢條件過濾數據，使用camunda就可以將這三個查詢條件進行持久化，下次張三來了，就可以直接根據他的偏好進行數據的過濾，類似機器學習。
-
camunda支持歷史數據的批量刪除或者批量遷移到其他介質，比如批量遷移到es，flowable沒有該機制。
-
camunda支持在高併發部署流程的時候，是否使用鎖機制，flowable沒有該機制。
-
camunda支持單引擎多組合、多引擎多庫。flowable僅僅支持單引擎多組合。
-
camunda支持流程實例跨流程定義跳轉，flowable沒有該機制。
-
camunda支持分佈式定時器，flowable沒有該機制。
-
flowable支持nosql，camunda只有nosql的解決方案。
-
camunda支持優化流程，以及瞭解流程引擎的瓶頸所在和每個環節的耗時，flowable沒有該機制。
-
camunda修改了流程模板xml解析方式，相比flowable性能更好。
-
camunda在解析流程模板xml的時候，去除了activiti5的雙解析機制，相對而言耗時時間更短。flowable沒有了pvm所以規避了雙解析機制。
-
camunda可以在任意節點添加任意的屬性，flowable原生API沒有，需要自己擴展。
-
camunda框架沒有爲流程生成圖片的API(所有流程圖展示以及高亮均在前端動態計算)，activiti5/6/flowable5/flowable6有圖片生成以及高亮的API.
-
camunda可以在節點中定義定時作業的優先級，也可以在流程中進行全局優先級的定義。當節點沒有定義優先級的時候可以使用全局的優先級字段。activiti5/6/flowable5/flowable6沒有改功能。
-
camunda可以再流程中定義流程的tag標記，activiti5/6/flowable5/flowable6沒有改功能。
-
camunda/activiti5/6/flowable5/flowable6 均不支持國產數據庫，比如人大金倉 和 達夢。
-
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流程引擎強大，性能和穩定性更突出。