Camunda Platform 7 参考架构 Camunda Platform 7 Reference Architecture

Camunda Platform 7 Reference Architecture(Camunda Platform 7 参考架构)

Executive Summary (执行摘要)

Camunda Platform 7 offers significant flexibility with regards to architecture, deployment options, programming languages and supported infrastructure. This document covers Camunda process engine implementation options, supported infrastructure specifications, hardware sizing and recommended database management systems.

Camunda Platform 7 在架构、部署选项、编程语言和支持的基础架构方面提供了极大的灵活性。 本文档涵盖 Camunda 流程引擎实施选项、支持的基础架构规范、硬件规模和推荐的数据库管理系统。

Process Engine Implementation Options (流程引擎实施选项)

The flexibility of Camunda Platform 7 is demonstrated with this sampling of implementation options. Typically, initial forays with Camunda use Spring Boot or a shared container though Docker is becoming a more popular option. All options work equally well and as a result there is no one recommended implementation option. And you don’t have to stick to one approach for all use cases. Given our licensing flexibility you can create as many environments as needed in any topology required. Only execution metrics in your production environments count toward your license. No need to count CPUs or servers. Development and QA environments are unlimited.

Camunda Platform 7 的灵活性通过该实施选项示例得到了展示。 通常，Camunda 的初始尝试使用 Spring Boot 或共享容器，尽管 Docker 正在成为更受欢迎的选择。 所有选项都同样有效，因此没有一个推荐的实施选项。 而且您不必对所有用例都坚持一种方法。 鉴于我们的许可灵活性，您可以在所需的任何拓扑中创建任意数量的环境。 只有生产环境中的执行指标才计入您的许可证。 无需计算 CPU 或服务器。 开发和 QA 环境是无限的。

Embedded Process Engine (Microservice) (嵌入式流程引擎（微服务）)

The process engine is added as an application library to a custom application. This way, the process engine can easily be turned on or off with the application lifecycle. It is possible to run multiple embedded process engines on top of the same shared database.

流程引擎作为应用程序库添加到自定义应用程序。 这样，流程引擎可以在应用程序生命周期内轻松开启或关闭。 可以在同一个共享数据库之上运行多个嵌入式流程引擎。

Shared, Container-Managed Process Engine (共享的、容器管理的流程引擎)

The process engine is started inside the runtime container (servlet container, application server), provided as a container service and can be shared by all applications deployed inside the container.

流程引擎在运行时容器（servlet 容器、应用程序服务器）内启动，作为容器服务提供，并且可以被部署在容器内的所有应用程序共享。

Standalone (Remote) Process Engine Server (独立（远程）流程引擎服务器)

The process engine is provided as a network service. Different applications can interact with it through remote communication, usually via the built-in REST API. Other channels such as SOAP or JMS are possible but need to be implemented by users.

流程引擎作为网络服务提供。 不同的应用程序可以通过远程通信与它进行交互，通常是通过内置的 REST API。 其他渠道，如 SOAP 或 JMS 是可能的，但需要由用户实现。

Cluster Model (集群模型)

To provide scale-up and fail-over capabilities, the process engine can be distributed to different nodes in a cluster. Each process engine instance then connects to a shared database. The individual process engine instances do not maintain session state across transactions. Whenever the process engine runs a transaction, the complete state is flushed out to the shared database. This makes it possible to route subsequent requests which do work in the same process instance to different cluster nodes. This model is very simple and easy to manage.

为了提供扩展和故障转移功能，流程引擎可以分布到集群中的不同节点。 然后每个流程引擎实例连接到一个共享数据库。 各个流程引擎实例不跨事务维护会话状态。 每当流程引擎运行事务时，完整状态都会刷新到共享数据库。 这使得可以将在同一流程实例中工作的后续请求路由到不同的集群节点。 该模型非常简单且易于管理。

Multi-Tenancy Models (多租户模型)

To serve multiple, independent parties with one Camunda installation, the process engine supports the following multi-tenancy models:

为了通过一个 Camunda 安装服务多个独立方，流程引擎支持以下多租户模型：

• Table-level data separation by using different database schemas or databases
• 通过使用不同的数据库模式或数据库进行表级数据分离
• Row-level data separation by using a tenant marker
• 使用租户标记进行行级数据分离

Users should choose the model which fits their data separation needs. Camunda’s APIs provide access to processes and related data specific to each tenant.

用户应选择适合其数据分离需求的模型。 Camunda 的 API 提供对每个租户特定的流程和相关数据的访问。

Supported Infrastructure Options (支持的基础架构选项)

Camunda Platform 7 can run in any Java-runnable environment. As of version 7.17, Camunda Platform 7 is supported with our QA infrastructure in the following environments.

Camunda Platform 7 可以在任何 Java 可运行环境中运行。 自 7.17 版起，Camunda Platform 7 在以下环境中受我们的 QA 基础设施支持。

Containers for Runtime Components (运行时组件的容器)

Application-Embedded Process Engine: 应用程序嵌入式流程引擎：

• All Java application servers
• 所有 Java 应用程序服务器
• Camunda Spring Boot Starter: embedded Tomcat
• Camunda Spring Boot Starter：嵌入式 Tomcat
• Camunda Engine Quarkus Extension
• Camunda 引擎 Quarkus 扩展

Container-Managed Process Engine and Web Applications: 容器管理的流程引擎和 Web 应用程序：

• Apache Tomcat 9.0
• JBoss EAP 7.0 / 7.1 / 7.2 / 7.3 / 7.4
• Wildfly Application Server 13.0 / 14.0 / 15.0 / 16.0 / 17.0 / 18.0 / 19.0 / 20.0 / 21.0 / 22.0 / 23.0 / 26.0
• IBM WebSphere Application Server 9.0 (Enterprise Edition only)
• Oracle WebLogic 12c (12R2) / 14 (Enterprise Edition only)

Docker

Pre-built Docker images of Camunda Platform 7 — Enterprise Edition are available via registry. camunda.cloud. Packaging the components shown below, the Camunda Docker images are suitable for the remote process engine architecture.

Camunda Platform 7 - Enterprise Edition 的预构建 Docker 映像可通过注册表获得。 camunda.cloud。 封装如下所示的组件，Camunda Docker 镜像适用于远程流程引擎架构。

Hardware and Sizing (硬件和尺寸)

Process Engine （流程引擎）

High Availability: It is recommended to run the process engine on at least two nodes to ensure high availability. The nodes do not have to form a proper cluster in terms of an application server cluster. It is sufficient to connect two identical nodes to the same database schema.

高可用性：建议至少在两个节点上运行流程引擎，以确保高可用性。 就应用服务器集群而言，节点不必形成适当的集群。 将两个相同的节点连接到相同的数据库模式就足够了。

Virtualization: Camunda can be run on virtualized systems. This does not impact licensing because licenses are not bound to CPU cores.

虚拟化：Camunda 可以在虚拟化系统上运行。 这不会影响许可，因为许可证未绑定到 CPU 内核。

Resource requirements are based on expected workloads. Listed below are Camunda’s recommendations:

资源需求基于预期的工作负载。 下面列出的是 Camunda 的建议：

• Small

Supports most use cases, typical server configuration 1-2 CPU cores, 1-8 GB RAM 支持大多数用例，典型服务器配置 1-2 个 CPU 内核，1-8 GB RAM

• Medium

Higher volume environments averaging more than 100 instances per second, typical server configuration 2-4 CPU cores, 4-16 GB RAM 平均每秒超过 100 个实例的高容量环境，典型的服务器配置 2-4 个 CPU 内核，4-16 GB RAM

• Large

Extreme volume environment or one where CPU intensive code has been deployed, typical server configuration 4-64 CPU, 16-128 GB RAM 超大容量环境或已部署 CPU 密集型代码的环境，典型服务器配置 4-64 CPU，16-128 GB RAM

A cluster of two small servers should suffice most common projects. Larger configurations should be considered when: 一个由两台小型服务器组成的集群应该足以满足最常见的项目。 在以下情况下应考虑更大的配置：

• The system needs to handle more than 100 process instances/second
• 系统需要处理超过100个流程实例/秒
• The system needs to support CPU intense delegation code or locally running services like data aggregation or transformation
• 系统需要支持 CPU 密集型委托代码或本地运行的服务，如数据聚合或转换
• The code or deployment call for unique requirements
• 代码或部署要求独特的要求

Load testing of deployed applications is the best approach for determining hardware sizing. 已部署应用程序的负载测试是确定硬件规模的最佳方法。

In addition, depending on the container the system requires approximately 500 MB to 1 GB of disk space. Camunda recommends at least 2 GB of storage in order to store enough logs for troubleshooting purposes. 此外，根据容器的不同，系统需要大约 500 MB 到 1 GB 的磁盘空间。 Camunda 建议至少有 2 GB 的存储空间，以便存储足够的日志以进行故障排除。

Database Management Systems （数据库管理系统）

To ensure availability, databases should be clustered and running on at least two nodes at any given time. 为确保可用性，数据库应在任何给定时间集群并在至少两个节点上运行。

Recommended Database types （推荐的数据库类型）

A large variety of database management systems (DBMS) are supported. Camunda recommends Oracle or PostgreSQL for production and H2 for development.

支持多种数据库管理系统 (DBMS)。 Camunda 建议将 Oracle 或 PostgreSQL 用于生产，将 H2 用于开发。

A large variety of database management systems (DBMS) are supported. Camunda recommends Oracle or PostgreSQL for production and H2 for development.

支持多种数据库管理系统 (DBMS)。 Camunda 建议将 Oracle 或 PostgreSQL 用于生产，将 H2 用于开发。

• MySQL 5.7 / 8.0
• MariaDB 10.3 / 10.6
• Oracle 12c / 19c
• IBM DB2 11.1 (excluding IBM z/OS for all versions)
• PostgreSQL 10 / 11 / 12 / 13
• Amazon Aurora PostgreSQL compatible with PostgreSQL 10.4 / 10.7 / 10.13 / 12.4
• Microsoft SQL Server 2014 / 2016 / 2017 / 2019 (more information)
• Microsoft Azure SQL with Camunda-supported SQL Server compatibility levels (more information)
• H2 2.0 (not recommended for production or cluster mode; (more information)
• CockroachDB v20.1.3 (more information)

Database Clustering and Replication （数据库集群和复制）

Clustered or replicated databases are supported when: 在以下情况下支持集群或复制数据库：

• The communication between Camunda Platform 7 and the database cluster matches the corresponding non-clustered, non-replicated configuration
• Camunda Platform 7与数据库集群的通信匹配对应的非集群、非复制配置
• The cluster configuration guarantees the behavior of READ-COMMITTED isolation level
• 集群配置保证READ-COMMITTED隔离级别的行为

Java

Java runtimes are supported as long as they are supported by the application server or container.

只要应用服务器或容器支持 Java 运行时，它们就会受到支持。

Database Sizing （数据库大小调整）

The amount of space required on the database depends on 数据库所需的空间量取决于

1. History Level: Turning off history saves a huge amount of tablespace as you only keep current runtime data in the database. However, it is advised to keep it to “FULL” to get the maximum audit logging from the process engine.
2. 历史级别：关闭历史可以节省大量的表空间，因为您只将当前运行时数据保留在数据库中。 但是，建议将其保持为“FULL”以从流程引擎获得最大的审计日志记录。
3. Process Variables must be written to the database (in a serialized form such as JSON). With the history level “FULL,” an entry is inserted into history tables every time a variable is changed, remembering the old value. With big data objects stored and changed often, this requires a lot of space.

2.流程变量必须写入数据库（以JSON等序列化形式）。 对于历史级别“FULL”，每次更改变量时都会在历史表中插入一个条目，并记住旧值。 由于经常存储和更改大数据对象，这需要大量空间。

When calculating database size, you should also clarify if and how often you will be cleaning up historical data. The real space occupied within your database depends very much on your database product and configuration and there is no simple formula to calculate this space.

在计算数据库大小时，您还应该明确是否以及多久清理一次历史数据。 数据库中占用的实际空间很大程度上取决于您的数据库产品和配置，并且没有简单的公式来计算该空间。

ABOUT CAMUNDA

Camunda is the leader in process orchestration software. Our software helps orchestrate complex business processes that span people, systems, and devices. With Camunda, business users collaborate with developers to model and automate end-to-end processes using BPMNpowered flowcharts that run with the speed, scale, and resiliency required to compete in today’s digital-first world.

Camunda 是流程编排软件的领导者。 我们的软件有助于协调跨人员、系统和设备的复杂业务流程。 借助 Camunda，业务用户与开发人员协作，使用 BPMN 支持的流程图对端到端流程进行建模和自动化，这些流程图以在当今数字优先世界中竞争所需的速度、规模和弹性运行。

To learn more, please visit our Best Practices resource center.

Q.E.D.