开源工作流BPM比较
内容提要
本文分析了jBPM、Camunda、Flowable和Activiti这四个开源BPM项目，介绍了工作流、BPM和行业标准符号。选择开源BPM产品时需要考虑集成程度和业务流程的复杂性。这四个项目在模型和功能、规则引擎、部署方式、仪表板和云原生方面有不同特点。选择开源BPM产品时需要考虑社区活动的支持和增强。
延伸解读
开源模型差异影响长期成本
四个项目的开源模式并不相同：jBPM社区版与企业版功能一致，企业版主要增加红帽支持；Camunda引擎和建模器开源，但操作模块需企业版；Activiti和Flowable则只提供基础功能，高级功能需购买企业版。这意味着选型时不能只看社区版功能，还要评估未来可能的企业版支出和支持依赖。
部署模式与扩展性的权衡
jBPM、Activiti和Flowable支持进程内嵌入和独立部署两种模式，而Camunda仅支持独立模式。嵌入模式性能高但耦合紧，扩展时需同时扩展应用；独立模式解耦且可独立扩展，但网络调用可能降低性能。Camunda从v8起放弃嵌入模式，正是出于可扩展性考虑，选型时应结合自身架构权衡。
规则引擎与案例管理的独特定位
jBPM是唯一内置Drools业务规则管理系统的产品，支持前后向链接推理，能自动确定规则执行顺序；其他三个仅支持DMN决策表。在案例管理方面，jBPM和Flowable支持CMMN，而Camunda和Activiti不支持，Camunda甚至因社区反馈认为CMMN过于复杂而取消支持。若业务涉及复杂规则或不可预测的案例流程，这一差异至关重要。
社区活跃度反映支持与演进风险
社区活跃度直接影响开源产品的支持和增强能力。文章指出Camunda和Flowable的社区最活跃，jBPM过去三年活动水平稳定，Activiti近两年相对安静，提交量突然激增可能源于Flowable分叉后贡献者转移。选择社区活跃的产品，能更可靠地获得问题修复和功能迭代，降低独自维护的风险。
Q&A
开源BPM产品中，哪个内置了业务规则管理系统？
jBPM是唯一提供内置业务规则管理系统（Drools）的开源BPM产品。Camunda、Flowable和Activiti都支持利用决策表的DMN表示法，但Drools具有更多功能，包括使用增强版Rete算法的前向和后向链接推理引擎，能自动找出要执行的规则及执行顺序。
jBPM、Camunda、Flowable和Activiti在部署方式上有什么不同？
jBPM、Activiti和Flowable都支持进程内/嵌入模式以及独立模式。Camunda仅支持独立模式，这是有意的决定，因为进程内/嵌入模式给社区带来了可扩展性挑战，所以从Camunda v8开始采用仅独立模式。
哪个开源BPM产品在社区版中就提供仪表板功能？
jBPM是唯一在其社区版本中提供仪表板功能的产品。其他三个（Camunda、Flowable、Activiti）都在企业版中提供仪表板，分别是Camunda Optimize、Flowable Work和Activiti Process Analytics。
什么时候应该选择BPM产品而不是轻量级状态机方案？
一般经验法则是，当在模型中可视化构建工作流比在代码或配置中更容易构建时，使用BPM产品。用例通常涉及两个维度：集成程度和业务流程的复杂性。需要高度集成和/或高复杂性的业务流程通常是BPM产品的最佳选择。
开源BPM产品中哪些支持CMMN案例管理？
jBPM和Flowable提供对CMMN的支持，而Camunda和Activiti则不支持。Camunda基于社区反馈认为CMMN过于复杂，决定取消支持，用户发现在BPMN中构建案例流比在CMMN中更容易。
这四个开源BPM项目的社区活跃度如何？
Camunda和Flowable似乎是最活跃的项目，其次是jBPM（过去三年活动水平保持一致），然后Activiti在过去两年相对安静，提交量突然激增。Activiti提交的安静可能是Flowable分叉的结果（以前的Activiti贡献者现在专注于提交Flowable）。
开源BPM产品在云原生方面有哪些进展？
jBPM大力投资Kogito项目，这是迁移到云原生微服务部署的下一代jBPM和Drools，支持反应式消息传递（Kafka）和无服务器工作流（Knative）。Camunda 8被誉为流程协调器且高度可扩展，提供Kubernetes和Helm图表支持。Activiti以与Spring Boot轻松集成闻名，也支持Kubernetes。Flowable展示了引擎以无服务器方式运行（如AWS Lambda）的示例。
