【42】Camunda8-与Camunda7.x的对比

Camunda8.0是22年4月发行的第一版；截止博文发布时，Camunda7的最新版本的是7.21。

---

Camunda8.0与camunda7.x

Camunda Platform 8保留了用户对于Camudna所喜爱的全部功能并带来了一些新的特性，同时提升了性能、可扩展性、可用性、连接性和协作性。

现对Camunda8.0与7.x的差异对比总结如下：

• Zeebe流程引擎内核：camunda7流程引擎内核是基于activiti5发展而来的，本质是上流程虚拟机pvm。Camunda8流程引擎内核是Zeebe，Zeebe是为Camunda平台8提供动力的过程自动化引擎。camunda7和camunda8的流程引擎完全不同，所以说camunda7和camunda8是两个完全不同的流程平台。
• 新增GrpcAPI：Camunda7版本是JAVA/REST API。由于API的更改，您将需要重写旧的应用程序，以确保与新协议的兼容性。Camunda8.0不再事宜基于Spring等集成于应用系统中。
• 可用的BPMN实现：如果您已经对流程进行了建模，则无法将它们以1:1的比例移植到新版本。它们可能需要改造。Camunda8.0建模的图元正在不断丰富中，但也不是能全部覆盖Camunda7已支持的全量图元的。
• 流程引擎部署策略：Camunda8是云原生解决方案。不同的过程状态管理方法和数据持久层：在Camunda 7中，所有过程变量和过程状态都保存在数据库中。Camunda 8中的数据库已被删除。这意味着性能的大幅提升，但也可能对具有ACID事务需求的客户端构成挑战。您可以做的是实现一个专用机制，使您能够保持新体系结构的改进性能，同时满足ACID需求。
• 不同的扩展和集群机制：Camunda8大幅提升了横向扩展的速度和灵活性，实现了集群化和弹性化。
• 新的容灾架构：在Camunda 8中，预配置的复制机制将允许Camunda从软件或硬件故障中恢复，而不会丢失任何数据。Camunda8原生支持异地灾备。
• 商业授权差异较大：Camunda7也分社区版和企业版，但社区版开源部分提供的功能已较为丰富，已能较好满足一般工作流需求，无需升级到企业版。而Camunda8开源组件较少，大部分组件是需要单独购买授权。
• 产品定位不同：Camunda7定位企业级流程引擎，支撑客户私有化部署；Camunda8定位是SaaS化流程引擎。
• 部分功能的优化：Connector、WEB设计器等。

Camunda官方将Camunda Platform 8与Camunda Platform 7的默认发行版进行了对比，即Camunda Run，这是一个独立的 Java 应用程序，包含所有持久化到关系数据库的Web应用程序。使用工作流引擎的应用程序通过REST 进行连接。

在 Camunda Platform 8 中，默认环境是SaaS版本，其中Camunda 在 Kubernetes 环境中托管了一组 Zeebe 工作流引擎。该引擎将数据导出到 Elasticsearch，即 Web 应用程序使用的数据存储。使用工作流引擎的应用程序通常会为所选编程语言嵌入提供的 SDK。

对于Camunda Platform 7用户来说，这些应用程序似乎非常熟悉。Operate 相当于 Cockpit。有一个新的任务列表，它也被称为任务列表，对于那些使用优化的人来说，你会很高兴知道它与 Camunda Platform 8 和 Camunda Platform 7 兼容，所以没有变化。Desktop Modeler 现在还支持两个版本的Camunda建模，您只需要下载最新版本即可。

这两个平台的用例完全相同：通过执行预定义的BPMN 2.0流程模型来编排系统、服务和人员。Camunda Platform 7 和 Camunda Platform 8 之间的区别不在于用例，而在于底层引擎的技术实现。

Camunda Platform 8的5项主要改进：

• 架构：允许真正的群集、弹性、水平可伸缩性和地域冗余。
• 安装：Camunda Platform 8在Kubernetes集群上运行，并自动拥有您需要的所有工具
• Web建模器：执行和部署的建模最终可以在基于Web的工具中进行
• Connectors连接器：使与外部系统集成的管理变得更加容易
• 功能改进：Camunda Platform 7中用户喜爱的现有功能都经过了大修和改进

Clustering

在Camunda Platform 7中，集群模型是通过运行多个工作流引擎实例，并将它们指向同一个关系数据库而实现的。然后，用户可以预先添加负载均衡器，以在节点之间分配传入流量。但是数据库是单点的，可能成为此体系结构中的瓶颈。

Zeebe引擎内置了集群，默认建议始终至少运行三个代理（一个Broker类似于 Camunda Platform 7工作流引擎节点）以实现弹性，因为这消除了任何单点故障。

提供的Gateway用于处理传入请求并将其路由到正确的Broker，同时还负责实现负载平衡。Broker将其数据存储为事件流，本地存储在磁盘上（就像 Kubernetes中的磁盘一样“本地”），并且此状态在Brokers之间复制。这就是为什么不需要像 Camunda Platform 7那样需要关系数据库的原因。

Scaling缩放

Camunda Platform 7的扩展方式有一个非常明显的局限性，即中央数据库。集群中的所有引擎都必须连接到同一数据库实例。这会将引擎的吞吐量限制在数据库可以处理的范围内，因此在某些时候，用户将达到集群可以执行的操作的硬性限制。Camunda Platform 8没有这种限制，性能会随着每个节点的不断扩展而不断扩展，这称为水平扩展性。如果运行的Brokers更多，则可以扩展以获得更高的负载。

Geographic redundancy地域冗余

多年来，随着Camunda引擎的成熟和稳定，它在越来越多的关键任务流程中受到信任。因此，我们经常被问到我们将如何处理整个数据中心宕机的问题。一般的解决方案是跨地域冗余，即在两个不同的物理位置运行应用程序。

使用Camunda Platform 7可以做到这一点，但由于我们需要通过低延迟连接同步到关系数据库实例，因此性能受到了巨大影响。由于这需要作为技术数据库事务的一部分来完成，因此导致事务打开的时间很长，从而导致级联问题。长话短说——虽然这是可能的，但它是痛苦的，而且从来都不是一件容易的事。

在设计Camunda Platform 8时，我们首先考虑了这个问题。通常，Zeebe 现在可以将其数据复制到不同物理数据中心中的Brokers，而不会损害整体吞吐量或稳定性。当然，复制的延迟仍然存在，但这只是一个恒定延迟，根本不是问题。

True parallel execution并行执行

为了保持一致的状态，Camunda Platform 7广泛利用锁定机制。在你即将阅读的实验中，你会清楚地看到，当你通过并行分支或并行多实例任务执行大量任务时，这会打击你。Camunda Platform 7引擎将产生大量 OptimisticLockExceptions，或者您需要将其配置为在一个流程实例中按顺序执行操作，从而导致此用例的性能不佳。

Camunda Platform 8不依赖相同的系统来确保一致的状态，而是使用仅追加日志、缓冲区和单个写入器的巧妙布局。这种设计消除了数据存储层（如 Camunda Platform 7 中的数据库）上的争用，并且您不需要按顺序运行，这大大加快了上述示例的速度。

简化的部署与架构

作为一个喜欢通过在我们的论坛上回答问题或举办研讨会来提供帮助的人，我可以自信地说，人们开始使用 Camunda Platform 7 的最大痛苦是：

• 学习了解不同的架构，以及这如何影响诸如在哪里编写代码之类的事情
• 如何部署模型
• 如何更新引擎

Camunda Platform 8大大简化了事情。我们提供一种用于运行和部署进程的方法，以及一种用于运行代码的单一方法，即通过gRPC或REST远程部署模型，然后以与外部任务模式相同的方式在外部运行代码。

所有组件的安装部署

使用Camunda Platform 7，用户必须定义组件的确切配置并负责安装。虽然这相对简单，但设置完全解耦的组件（如 Camunda Optimize）仍然需要付出一定的努力。Camunda Platform 8 的整个安装过程现在依赖于 Kubernetes，我们提供了 Helm 图表来设置和连接整个环境，包括 Camunda Optimize。如果用户使用的是 Camunda Platform 8 SaaS，用户甚至不必考虑 Kubernetes 或 Helm，只需单击一个按钮即可访问所有组件。

内部SaaS产品

使用Camunda Platform 8，用户可以设置自己的组织内部SaaS服务。用户只需要一个Kubernetes环境来安装 Camunda Platform 8 集群（我们计划很快提供 Web 控制台，以便为自我管理的用户提供新引擎）。虽然这个SaaS可以集中操作，但它可以使用 Camunda Platform 8，用户可以设置自己的组织内部 SaaS 服务。用户只需要一个 Kubernetes 环境来安装 Camunda Platform 8 集群（我们计划很快提供 Web 控制台，以便为自我管理的用户提供新引擎）。虽然此 SaaS 可以集中操作，但它可以被自助服务中的所有项目使用（正如用户对任何其他云服务所期望的那样）。它通过单点来配置新引擎、监控它们或升级到更新版本，从而大大简化了维护。

WEB设计器

Camunda Platform 7 一直与其 Web 应用程序有很好的集成，但我们总是发现以一种技术和UX（用户体验）适合的方式正确集成Modeler具有挑战性。由于Camunda Platform 8托管在云中，它为我们提供了更大的灵活性，让我们可以设置建模器以更好地与流程引擎集成，因为我们不再需要最终用户修改设置。从最终用户的角度来看，构建和部署流程模型与云中托管的所有必需组件一样无缝。这并不意味着您需要更改部署方式。您还可以在本地保存和维护模型，并像使用 Camunda Platform 7一样从Desktop Modeler部署模型。

基于Connector的简单调用设计

业务流程协调程序最常见的工作是与外部系统进行通信。在使用Camunda 的项目中，这些连接通常由构建流程解决方案的人员从头开始编程。但其中一些逻辑最终是相当通用的。是否需要调用REST端点、发送 AMQP 消息或者连接到任何其他项目中的定制内部系统。对于这些情况，我们希望提供更多的便利性，并使可重用性更容易。

因此，在Camunda Platform 8中，我们将添加添加预定义连接器的功能。Camunda将提供一些连接器，但也应允许用户构建自己的连接器，以便在组织内重复使用。我们还研究了连接器的整个用户体验，并决定将其添加为Web Modeler的一部分，希望这些连接器能够在构建流程时为开发人员节省大量时间和精力，同时仍然不会限制他们可以做什么。我们不打算让人们将Camunda视为一个低代码平台。