來源｜blog.csdn.net/wanyu_123/ article/details/128833719
市場上比較有名的開源流程引擎有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流程引擎強大，效能和穩定性更突出。
熱門推薦
