欧美性猛交XXXX免费看蜜桃,成人网18免费韩国,亚洲国产成人精品区综合,欧美日韩一区二区三区高清不卡,亚洲综合一区二区精品久久

1. 名詞解釋#1.1. BPMBusiness Process Management，業(yè)務(wù)流程管理，“通過(guò)建模、自動(dòng)化、管理和優(yōu)化流程，打破跨部門(mén)跨系統業(yè)務(wù)過(guò)程依賴(lài)，提高業(yè)務(wù)效率和效果”。1.2. BPMNBusiness Process Modeling Notation，業(yè)務(wù)流程建模與標注，包括這些圖元如何組合成一個(gè)業(yè)務(wù)流程圖（Business Process Diagram）；討論BPMN的各種的用途，包括以何種精度來(lái)影響一個(gè)流程圖中的模型；BPMN作為一個(gè)標準的價(jià)值，以及BPMN未來(lái)發(fā)展的遠景。1.3. BPELBusiness Process Execution Language，意為業(yè)務(wù)過(guò)程執行語(yǔ)言，是一種基于XML的，用來(lái)描寫(xiě)業(yè)務(wù)過(guò)程的編程語(yǔ)言，被描寫(xiě)的業(yè)務(wù)過(guò)程的每個(gè)單一步驟則由Web服務(wù)來(lái)實(shí)現。1.4. XPDLXML Process Definition Language,是由Workflow Management Coalition（簡(jiǎn)寫(xiě)為：WfMC）所提出的一個(gè)標準化規格，使用XML文件讓不同的工作流程軟件能夠交換商業(yè)流程定義。XPDL被設計為圖形上和語(yǔ)義上都滿(mǎn)足交換用的商業(yè)流程定義，是描述BPMN圖的最佳文件格式。BPEL也可以描述商業(yè)流程。但是XPDL不僅包含流程執行的描述，還包括了元素的圖形信息，更適于商業(yè)流程建模。1.5. JPDLJBoss jBPM Process Definition Language，是構建于jBPM框架上的流程語(yǔ)言之一。在jPDL中提供了任務(wù)（tasks）、待處理狀態(tài) （wait states）、計時(shí)器（timers）、自動(dòng)處理（automated actions）等術(shù)語(yǔ)，并通過(guò)圖型化的流程定義，很直觀(guān)地描述業(yè)務(wù)流程。1.6. PVMProcess Virtual Machine，流程虛擬機，他的設計初衷是通過(guò)實(shí)現接口和定制插件等方式兼容多種流程定義語(yǔ)言和流程活動(dòng)場(chǎng)景，為所有的業(yè)務(wù)流程定義提供一套通用API平臺。那么，無(wú)論是需要對jBPM 原有流程定義語(yǔ)言進(jìn)行擴展，或者重新實(shí)現一套專(zhuān)用的流程定義語(yǔ)言，都可以通過(guò)實(shí)現 PVM 指定的接口規范完成。1.7. DMNDecision Model and Notation，DMN的目的是提供一個(gè)模型決策結構，從而使組織的策略可以用圖形清晰的地描繪出來(lái)，通過(guò)業(yè)務(wù)分析準確的定義，使其自動(dòng)化（可選地）。1.8. CMMNCase Management Model and Notation，CMMN是一種圖形化的符號，用于捕獲工作方法，這些工作方法基于處理需要各種活動(dòng)的情況，這些活動(dòng)可能以不可預測的順序執行，以響應不斷變化的情況。通過(guò)使用以事件為中心的方法和案例文件的概念，CMMN擴展了可以用BPMN建模的邊界，包括結構化程度較低的工作和由知識工人驅動(dòng)的工作。結合使用BPMN和CMMN，用戶(hù)可以涵蓋更廣泛的工作方法。2. 眾多工作流#2.1. JBPM（Java Business Process Management）由JBoss公司開(kāi)發(fā)，目前最高版本JPBM7，不過(guò)從JBPM5開(kāi)始已經(jīng)跟之前不是同一個(gè)產(chǎn)品了，JBPM5的代碼基礎不是JBPM4，而是從Drools Flow重新開(kāi)始。下面要涉及的很多產(chǎn)品都是以JBPM4的代碼為起點(diǎn)進(jìn)行開(kāi)發(fā)的。2.2. ActivitiAlfresco軟件開(kāi)發(fā)，基于JBPM4，后并入OMG，目前最高版本activiti 7。Activiti5版本的時(shí)候，核心團隊發(fā)生了比較大的變動(dòng)（離職），activiti6的開(kāi)發(fā)團隊在新版本中去除了PVM，納入了DMN，重構XML解析，BUG較多，目前主要團隊致力于activiti7,5&6已經(jīng)官宣不維護。2.3. Osworkflow完全用java語(yǔ)言編寫(xiě)的開(kāi)放源代碼的工作流引擎，具有顯著(zhù)的靈活性及完全面向有技術(shù)背景的用戶(hù)的特點(diǎn)。由opensymphony組織維護，其不遵守XPDL等業(yè)務(wù)規范，完全使用XML編排業(yè)務(wù)。面向開(kāi)發(fā)人員。2.4. Shark靠山是Enhydra。是一個(gè)可擴展的工作流引擎框架，它包括一個(gè)完全基于 WFMC 規范的標準實(shí)現，它使用XPDL（沒(méi)有任何自己新的擴展）作為自身的工作流流程定義格式。其持久層和設計器都是自己公司研發(fā)的，持久層實(shí)現采用的標準是輕量級的Enhydra DODS O/R mapping 工具，設計器可以用Enhydra JaWE 圖形XPDL編輯器。2.5. Apache ODE輕型的、可嵌入的組件，利用組件組裝成一個(gè)完整的BPM系統。關(guān)鍵模塊包括ODE BPEL編譯器、ODE BPEL運行時(shí)、ODE數據訪(fǎng)問(wèn)對象（DAOs）、ODE集成層（ILs）和用戶(hù)工具。雖然掛在A(yíng)pache下面，但已經(jīng)年久失修。2.6. Flowable基于activiti6，最新的開(kāi)源版本是flowable6，開(kāi)發(fā)團隊是從activiti中分裂出來(lái)的，修復了一眾activiti6的bug，并在其基礎上研發(fā)了DMN支持，BPEL支持等等。相對開(kāi)源版，其商業(yè)版的功能會(huì )更強大。2.7. Camunda基于activiti5，所以其保留了PVM，最新版本Camunda7，開(kāi)發(fā)團隊也是從activiti中分裂出來(lái)的，發(fā)展軌跡與flowable相似，同時(shí)也提供了商業(yè)版。2.8. JFlow前身ccFlow，國產(chǎn)的工作流引擎，由濟南馳騁公司開(kāi)發(fā)維護，主打中國式的業(yè)務(wù)流程，由于是國產(chǎn)的軟件，中文化程度比較深，業(yè)務(wù)開(kāi)發(fā)也對用戶(hù)比較友好。國產(chǎn)的開(kāi)源工作流引擎還是挺多的，JFlow是其中功能比較完善的一個(gè)，同時(shí)對比activiti，流程上更加中國化，支持自定義流程跳轉，加簽等。其他國產(chǎn)工作流就不列舉了。還有很多工作流，比如ProcessMaker，SWF，oracle，Bonita，openwebflow，snaker等，不過(guò)做BPM的話(huà)，相對于上面列舉的產(chǎn)品還是有些缺陷，比如流程過(guò)于簡(jiǎn)單，資料過(guò)少等。3. 關(guān)于工作流標準#BPMN是聽(tīng)得比較多的工作流標準，但工作流的規范其實(shí)不止一種，還有XPDL，BPML等。甚至他們的出現時(shí)間比BPMN更早，只是因為一些技術(shù)和非技術(shù)原因，BPMN2.0被普遍使用了，而非BMPN2.0規范的廠(chǎng)商也逐漸轉移了。以下的內容是關(guān)于規范標準之爭中，BPMN2.0如何從眾多規范中戰勝并被普遍使用的。3.1. BPMN1.X在BPMN1.X里，BPMN是Business Process Modeling Notation的縮寫(xiě)，即業(yè)務(wù)流程建模符號，而在BPMN2.0里，BPMN變成了Business Process Model And Notation的縮寫(xiě)，即業(yè)務(wù)流程模型和符號，一個(gè)單詞的增加卻標示著(zhù)BPMN本身發(fā)生了巨大的變化。查看如下圖1 timeline:

圖1其中BPMN1.0在2004年5月由BPMI組織正式發(fā)布。這個(gè)階段WSFL和BPEL-WS都已經(jīng)被發(fā)布。這三種規范中，BPMN1.0僅僅作為業(yè)務(wù)流程建模的一系列符號標準，對業(yè)務(wù)比較友好。廠(chǎng)商們認為統一的建模標準能夠使他們圍繞核心建模工具提供其他更多的價(jià)值，更加愿意接受BPMN。但BPMN1.x只是一些建模符號，不支持元模型，不支持存儲和交換，也不支持執行。2008年，BPMN1.1發(fā)布，但仍然存在這些對開(kāi)發(fā)人員并不友好的缺點(diǎn)，XPDL、BPEL和BPDM圍繞著(zhù)BPMN1.x的存儲、交換和執行，產(chǎn)生了新的競爭。XPDL作為WfMC提出的流程定義語(yǔ)言規范，本身就是一個(gè)元模型，可以存儲，并且具備執行語(yǔ)義，因此理論上來(lái)講，將BPMN轉換為XPDL就可以解決存儲、交換和執行的問(wèn)題。XPDL2.0于2005年10月發(fā)布，在規范里，WfMC直接將XPDL的目標定義為BPMN的XML序列化格式。2008年4月23日發(fā)布的XPDL2.1規范，直接支持BPMN1.1到XPDL2.1的轉換。XPDL是面向圖的，BPMN也是面向圖的，因此BPMN到XPDL的轉換有著(zhù)天然的優(yōu)勢。如今有超過(guò)80個(gè)的不同公司的產(chǎn)品使用XPDL來(lái)交換流程定義，同時(shí)也有一些廠(chǎng)商在自己提供的BPMN工具中使用了XPDL作為交換和存儲格式。BPEL-WS規范在2003年4月提交給了OASIS（Organizationfor the Advancement of Structured Information Standards，結構化信息標準促進(jìn)組織）并更名為WSBPEL（Web Services Business Process Execution Language）規范， 2007年4月發(fā)布WSBPEL2.0版本，除了Microsoft、 BEA、 IBM、 SAP 和Siebel，Sun Microsystems和甲骨文公司也相繼加入了OASIS組織。除去政治因素，BPEL的流行還在于Web正成為分布式系統架構的平臺以及SOA的雄起，SOA強調服務(wù)的分解和解耦，而B(niǎo)PEL則對這些WEB服務(wù)進(jìn)行編制，兩者密不可分。但BPMN到BPEL的轉換存在著(zhù)先天上的缺陷，原因是BPMN是基于圖的，而B(niǎo)PEL是基于塊的，BPEL是一個(gè)結構化（塊[Block]）和非結構化（控制鏈和事件）的混合體。這個(gè)缺陷導致有些BPMN建模的流程無(wú)法映射到BPEL，兩者的雙向工程更是存在問(wèn)題。這個(gè)缺陷成為人們反復詬病的對象。許多支持BPEL的產(chǎn)品為了解決這一問(wèn)題，不得不在用戶(hù)建模時(shí)做出種種限制，讓用戶(hù)繪制不出無(wú)法轉換的模型。而B(niǎo)PDM（業(yè)務(wù)流程定義元模型，Business Process Definition Metamodel）則是OMG組織自己提出來(lái)解決BPMN存儲和交換問(wèn)題的規范。于2007年7月形成初稿，2008年7月被OMG最終采用。BPDM是一個(gè)標準的概念定義，用來(lái)表達業(yè)務(wù)流程模型。元模型定義了用來(lái)交換的概念，關(guān)系和場(chǎng)景，可以使得不同的建模工具所建模出來(lái)的流程模型進(jìn)行交換。BPDM超越了BPMN和BPEL所定義的業(yè)務(wù)流程建模的要素，它定義了編排和編制。3.2. BPMN2.0隨后，BPMN2.0發(fā)布了?？磮D2 timeline

圖2BPMN2.0 beta1版本于2009年8月發(fā)布，BPMN2.0 beta2版本于2010年5月發(fā)布，BPMN2.0正式版本于2011年1月3日發(fā)布。BPMN2.0正式將自己更名為Business Process Model And Notation（業(yè)務(wù)流程模型和符號），相比BPMN1.x，最重要的變化在于其定義了流程的元模型和執行語(yǔ)義，即它自己解決了存儲、交換和執行的問(wèn)題，BPMN由單純的業(yè)務(wù)建模重新回歸了它的本源，即作為一個(gè)對業(yè)務(wù)人員友好的標準流程執行語(yǔ)言的圖形化前端。BPMN2.0一出手，競爭就結束了，XPDL、BPEL和BPDM各自準備回家釣魚(yú)。BPMN2.0是最被廣泛使用的標準，也是當前熱門(mén)產(chǎn)品使用的標準，詳情請看整理的表1：工作流框架遵循規范備注Bonita BPMXPDL流程過(guò)于簡(jiǎn)單SharkXPDL不維護-2017Osworkflow自定義XML規范不維護JBPMBPMN2.0JBPM4.3后添加了對BPMN的支持，持續開(kāi)源Apache ODEWS-BPEL、BPEL4WS不維護ActivitiBPMN2.0，XPDL，JPDLActiviti7維護FlowableBPMN2.0，XPDL，JPDL持續開(kāi)源JFlowBPMN2.0，Ccbpm2015年后為了與國際接軌，開(kāi)發(fā)支持BPMNCamundaBPMN2.0，XPDL，JPDL持續開(kāi)源表1這個(gè)表格可以對一些工作流產(chǎn)品有一個(gè)初步印象。4. 分表對比#4.1. 對比須知為了方便查看匯總表格，有必要再深入展示幾個(gè)開(kāi)篇提到的概念：PVMPVM是在JBPM4的時(shí)候被納入的，activiti5沿用，activiti團隊在activiti6就已經(jīng)移除了，ActivitiImpl, ProcessDefinitionImpl, ExecutionImpl, TransitionImpl 都不可用了。所有的流程定義有關(guān)的信息都可以通過(guò)BpmnModel來(lái)獲得，通過(guò)org.activiti.engine.impl.util.ProcessDefinitionUtil來(lái)拿到BpmnModel。工作流中，由于flowable是基于activiti6開(kāi)發(fā)的，所以代碼中也沒(méi)有PVM，Camunda基于activiti5開(kāi)發(fā)的，所以PVM還在，更改這個(gè)核心引擎沒(méi)有絕對的好壞之分，但是由于我們的代碼是基于activiti5開(kāi)發(fā)的，所以對我們的代碼移植是有影響的。DMNBPMN是OMG公司發(fā)布的工作流規范，而DMN同樣是OMG公司發(fā)布規范，該規范主要用于定義業(yè)務(wù)決策的模型和圖形，1.0版本發(fā)布于2015年，目前最新的是1.1版本，發(fā)布于2016年。BPMN主要用于規范業(yè)務(wù)流程，業(yè)務(wù)決策的邏輯由PMML等規范來(lái)定義，例如在某些業(yè)務(wù)流程中，需要由多個(gè)決策來(lái)決定流程走向，而每個(gè)決策都要根據自身的規則來(lái)決定，并且每個(gè)決策之間可能存在關(guān)聯(lián)，此時(shí)在BPMN與PMML之間出現了空白，DMN規范出現前，決策者無(wú)法參與到業(yè)務(wù)中。為了填補模型上的空白，新增了DMN規范，定義決策的規范以及圖形，DMN規范相當于業(yè)務(wù)流程模型與決策邏輯模型之間的橋梁。圖3圖解：

圖3雖然DMN只作為工作流與決策邏輯的橋梁，但實(shí)際上，規范中也包含決策邏輯部分，同時(shí)也兼容PMML規范所定義的表達式語(yǔ)言。換言之，實(shí)現DMN規范的框架，同時(shí)也會(huì )具有業(yè)務(wù)規則的處理能力。CMMNCMMN具有與BPMN不同的基本范例。 CMMN沒(méi)有順序的流程。相反，它以某種狀態(tài)對案例建模。根據狀態(tài)，視情況而定，有些事情可能會(huì )處理，而有些事情可能不會(huì )?？刂浦饕扇藖?lái)執行。 CMMN是聲明性的，該模型說(shuō)明了要應用的內容，但沒(méi)有說(shuō)明如何實(shí)現它。相反，BPMN強制性地規定了流程中某些步驟必須進(jìn)行的工作。對于大多數人而言，聲明性建模更為復雜且較不直觀(guān)。結果，CMMN模型更加難以理解。您不能簡(jiǎn)單地用手指追蹤路徑！CMMN對可能的活動(dòng)和活動(dòng)限制進(jìn)行建模。它對活動(dòng)何時(shí)發(fā)生，何時(shí)必須發(fā)生以及何時(shí)不應該發(fā)生進(jìn)行建模。 CMMN同樣限制了流程中人員可以使用的操作范圍。事例模型必須事先經(jīng)過(guò)仔細考慮。重要的是要提出這一點(diǎn)，以應對人們經(jīng)常誤解的事實(shí)，即人們在案件管理方面可以做他們想做的任何事情。CMMN和BPMN都描述了業(yè)務(wù)流程中的活動(dòng)。這些標準之間的主要區別是：1、BPMN采用綁定方法。 它提供了活動(dòng)的確切順序。提供自由度比較困難。比如加個(gè)節點(diǎn)、任意跳轉就很麻煩。2、CMMN采用非約束性方法，然后增加了限制。建立排序比較困難。換句話(huà)說(shuō)，原則上您可以用任何一種表示法表達大多數問(wèn)題。但是，根據問(wèn)題的類(lèi)型，建模將在BPMN或CMMN中更好地工作，并且這些標準之一更可能產(chǎn)生整潔有效的模型。使用CMMN的指標包括：1、無(wú)需序列：如果序列無(wú)關(guān)緊要，并且可以按任何順序執行任務(wù)，則這將在BPMN中產(chǎn)生過(guò)多的連接-臨時(shí)建模。也許使用臨時(shí)子流程可以避免混亂。2、活動(dòng)取決于條件：定義條件是CMMN的強項?？梢远x許多任務(wù)，但是它們只能在某些情況下起作用。例如，這種情況可能是訂單超過(guò)一定數量或客戶(hù)具有VIP身份；其他已完成的任務(wù)也會(huì )影響條件?？蛇x因素和數據相關(guān)因素的這種組合不能在BPMN中反映出來(lái)。3、專(zhuān)用計劃階段：由于能夠處理任意任務(wù)，CMMN可以適應一個(gè)計劃階段，在該階段中，一個(gè)工人計劃一個(gè)案例并啟用任務(wù)。 其他工人將不得不遵守計劃。 BPMN不能做任何事情。包括BPMN標準，這三個(gè)標準都是由OMG提出的。多數機構認為DMN和CMMN是工作流發(fā)展趨勢。4.2. 對比表格經(jīng)過(guò)第二個(gè)章節的比較，我從支持的標準和社區活躍度表現比較好的工作流中篩選出幾個(gè)選項進(jìn)行進(jìn)一步對比，如表2：Activiti 7Flowable 6Camunda bpmJBPM 7JFLOW(國產(chǎn)的)功能會(huì )簽√√√√√回退×√√-√駁回×√√√√自定義流轉××√-√加簽、減簽×√√-√多實(shí)例√√√√√事務(wù)子流程√√√√√版本遷移××√××兼容性及二次開(kāi)發(fā)支持的流程格式BPMN2.0、XPDL、PDLBPMN2.0、XPDL、XPDLBPMN2.0、XPDL、XPDLBPMN2.0BPMN2.0開(kāi)源情況開(kāi)源提供商業(yè)和開(kāi)源版提供商業(yè)和開(kāi)源版開(kāi)源開(kāi)源開(kāi)發(fā)基礎jBPM4Activiti 5 & 6Activiti 5版本5之后Drools Flow自開(kāi)發(fā)直接支持的腳本JUEL、groovyJUEL、groovypython、ruby、groovy、JUEL--引擎核心（跟代碼兼容有關(guān)）去除PVM去除PVM流程虛擬機（PVM）（遷移上有優(yōu)勢）Drools自研Spring結合√√√√√二次開(kāi)發(fā)難度一般一般一般較難一般未來(lái)拓展CMMN支持×√√××DMN支持√√（6.4之前不穩定）√√×歷史數據處理（NoSql）×√√（只提供了解決方案）-×支持數據庫Oracle、SQL Server、MySQLOracle、SQL Server、MySQL、postgreOracle、SQL Server、MySQL、postgreMysql，postgreoracle,sqlserver,mysql集群部署√√（6.5版本支持）√√√云部署√-√-√其他特性持久化框架MybatisJPA二次封裝HibernateJPA-架構spring boot 2spring boot 1.5spring boot 2Kiespring boot 2(特別版本)事務(wù)管理MyBatis機制/Spring事務(wù)控制hibernate機制/Spring事務(wù)控制hibernate機制/Spring事務(wù)控制Bitronix，基于JTA事務(wù)管理-分布式事務(wù)MyBatis機制/Spring事務(wù)控制-補償機制，SAGA 模式Bitronix，基于JTA事務(wù)管理-開(kāi)發(fā)手冊https://activiti.gitbook.io/activiti-7-developers-guide/部分網(wǎng)頁(yè)打不開(kāi)http://www.shareniu.com/flowable6.5_zh_document/bpm/index.htmlhttps://docs.camunda.org/manual/7.13/user-guide/https://docs.jboss.org/jbpm/release/7.40.0.Final/jbpm-docs/html_single/http://ccbpm.mydoc.io/運行模式獨立運行和內嵌-獨立運行和內嵌-獨立運行和內嵌源碼活躍度相對活躍相對活躍比較活躍相對活躍一般源碼地址https://github.com/Activiti/Activitihttps://github.com/flowable/flowable-enginehttps://github.com/camunda/camunda-bpm-platformhttps://github.com/kiegroup/jbpmhttps://gitee.com/opencc/JFlow設計器集成idea eclipse，web自提供，eclipse自提供，eclipseEclipse自提供，.net開(kāi)發(fā)集成接口SOAP、Mule、RESTfulSOAP、Mule、RESTfulSOAP、Mule、RESTful消息通訊SOAP、Mule、RESTful內部服務(wù)通訊Service間通過(guò)API調用Service間通過(guò)API調用Service間通過(guò)API調用基于A(yíng)pache Mina異步通訊-表2特別說(shuō)明：1. 源碼活躍度：從分支數，提交數，參與者，最近提交時(shí)間等判斷2. Drools Flow (process/workflow)：該工作流引擎是Drools下的一個(gè)項目，JBPM的規則引擎正是Drools，由于activiti開(kāi)發(fā)自JBPM4，所以activiti，flowable以及Camunda都有Drools的影子。3. 空白處或者小短桿表示的代表的暫時(shí)未查證的內容4. 另外要說(shuō)明的是，表格中支持的功能需要有不少部分需要認真探討，比如Camunda宣稱(chēng)支持各種功能，以及Nosql存儲，但實(shí)際上，其支持的回退，撤回都是通過(guò)一個(gè)跳轉實(shí)現的，要打折扣，NoSql也只是提供了解決方案，要自己實(shí)現噢，后面一篇文章會(huì )再提及。5. 性能#關(guān)于工作流性能比較的文章比較少（少得可憐），因為沒(méi)有直接的數據能夠對比工作流之間的性能，所以獨立出一章介紹，基本情況：5.1. 概述以下內容來(lái)自：http://www.bpm-guide.de/2016/06/12/scientific-performance-benchmark-of-open-source-bpmn-engines/ 《Scientific performance benchmark of open source BPMN engines》據說(shuō)是16年的一份科學(xué)性能報告，可惜性能報告中，除了Camunda外，其他兩種被對比的WFMS產(chǎn)品名稱(chēng)并沒(méi)有寫(xiě)出來(lái)，所以這個(gè)報告只能作為參考：“In general, we may conclude that Camunda performed better and more stable for all metrics when compared with WfMS A and WfMS B.”“WfMS A and Camunda share many architectural similarities because Camunda was originally a fork of WfMS A.” 暗指WfMS A是activiti。為了得到更多的性能數據，接下來(lái)從各個(gè)官網(wǎng)尋找材料。5.2. Camundahttps://camunda.com/products/performance/該地址沒(méi)有描述具體的性能，但是列舉了一些措施，表示做了性能考慮：1. 緊湊型表：減少必要的存儲數據，在最好的例子中，修改一個(gè)活動(dòng)只需要更新一條數據2. 避免死鎖：采用樂(lè )觀(guān)鎖；用戶(hù)思考期間不持有鎖；批量刷新數據3. 控制保存點(diǎn)：在一個(gè)事務(wù)中保存多個(gè)活動(dòng)4. 智能緩存：使用一級緩存，減少查詢(xún)5. 并行：并行任務(wù)在數據庫中表現為不同行，實(shí)現真正并行6. 集群：多節點(diǎn)共用數據庫7. 最小資源占用：流程引擎無(wú)狀態(tài)，每個(gè)節點(diǎn)只需要分配少于10M的緩存，所以支持大批量任務(wù)在節點(diǎn)上運行8. 分庫：歷史庫和運行庫是分開(kāi)的，原則上，歷史數據可以轉移到任何大數據產(chǎn)品上5.3. Flowablehttps://flowable.com/open-source/docs/bpmn/ch18-Advanced/#async-executor這里沒(méi)有特別介紹提升性能的設計，但一些角落有提到，對性能是否提升未知：1.額外寫(xiě)了UUID id生成器，解決并發(fā)的bug，但其實(shí)不一定能提升性能；2.數據庫的批量插入3.async executor：異步執行器，能解決背壓，但是對性能的提升程度未知5.4. JBPM7https://jbpm.org/learn/jbpmPerformance.html這里也沒(méi)有介紹性能的具體情況。但提供了檢測性能的方法，指明了不跟任何工作流作對比，言辭謹慎。官網(wǎng)給的例子仍然可以作為參考數據，翻譯如下：客戶(hù)端：jmeter版本：社區版 7.8硬件：Macos 10.14.4Cpu i7 2.3GHZMemory 16GBDb Postgre測試內容：三個(gè)簡(jiǎn)單的流程，我做了簡(jiǎn)單的表格繼承他的測試結果；（利用執行1000個(gè)實(shí)例用時(shí)得出TPS）單位：TPS單線(xiàn)程四線(xiàn)程八線(xiàn)程簡(jiǎn)單腳本任務(wù)91240361簡(jiǎn)單用戶(hù)任務(wù)165272用戶(hù)任務(wù)+并行腳本任務(wù)1145705.5. Activiti 7https://activiti.gitbook.io/activiti-7-developers-guide/有提到一些提升查詢(xún)性能的地方，但是不明確。5.6. JFlow未提及性能6. 總結#大致總結以下調研的總體感受。Activiti7相對于5和6沒(méi)有太多功能上的變化，主要致力于一些輔助功能，對接一些基礎技術(shù)。比如云原生，ELK，spring cloud。分布式的應用或許會(huì )對性能有一定的提升。Flowable的NoSql方案和消息隊列比較特別，同時(shí)對DMN和CMMN的研究也比較多，是個(gè)不錯的選擇。JBPM近年來(lái)新的文檔少一些，應用和二次開(kāi)發(fā)可能會(huì )比較吃力。JFlow功能比較齊全，而且中文化的設計器對開(kāi)發(fā)人也和業(yè)務(wù)人也都比較友好，但是他的材料基本限于官網(wǎng)，后期不會(huì )保障。Camunda BPM支持的功能比較多，對DMN和CMMN的支持也是推出最早的，性能上看起來(lái)也做了比較多的應對，雖然商業(yè)版的推出減少了開(kāi)源版的維護，但仍然是幾個(gè)競品中綜合看起來(lái)比較符合當前需求的，PVM的保留也會(huì )使得遷移比較順滑，具體使用情況還需要進(jìn)一步嘗試，比較推薦。（如果不是舊產(chǎn)品遷移其實(shí)需要更多選擇，框架改革的優(yōu)化是可以考慮在內的，根據需求選擇）7. 一些參考網(wǎng)址#https://github.com/qiudaoke/flowable-userguide/blob/master/%E6%A1%86%E6%9E%B6bug%E5%88%97%E8%A1%A8/bug.txt 《Flowable 6.5未修復bug列表》https://flowable.com/blog/2016/09/decision-model-and-notation-dmn-how-to-start-a-project-2/  《decision-model-and-notation-dmn-how-to-start-a-project-2》https://blog.camunda.com/post/2016/10/migrate-from-activiti-to-camunda/ 《How to migrate from Activiti 5.21 to Camunda BPM 7.5》http://www.bpm-guide.de/2015/09/28/why-bpmn-is-not-enough/ 《Why BPMN is not enough》