介绍

BPM 是一个描述、建模和管理复杂业务流程的概念。使用 BPMN，我们可以轻松定义流程中的顺序，编排多个任务、决策和事件。有许多 IT 平台可以将 BPMN 设计变成工作代码。事实证明，协调服务、系统和业务任务的 BPM 模型和支持 IT 平台是实现业务流程的可靠来源。

那就是微服务出现的时候。也就是说，松散耦合的、基于事件的服务，旨在实现特定的业务功能，通过事件进行通信，并实现编排消息传递模型。微服务是否意味着 BPM 平台的终结？或者恰恰相反——像 Camunda 这样的 BPM 平台能否在复杂业务流程的微服务整合中发挥关键作用？

BPM 实施模型

当公司准备好启动 BPM 计划时，第一个决定是选择合适的实施模型和合适的 BPM 平台。

首先，让我们讨论该模型，它将定义整个 BPM 倡议方法本身。这是一个关键决策，需要深思熟虑，因为它将定义整个组织将如何创建和实现业务流程。有两种最流行的建模方法：

BPM 平台可以是一个单一的 IT 系统，它将在一个地方为业务流程编排和配置规则。
BPM 引擎可以是微服务的一部分，包含特定的子流程。这些微服务及其子流程将使用编排通信模式整合到业务流程中。

Camunda BPM Platform 可以从技术和业务角度实现这两种方法。这就是在 BlueSoft 中我们推荐该软件作为我们项目中主要 BPM 工具的主要原因之一，我们将使用它作为进一步概念的示例。

Camunda BPM 作为业务流程管理单体

自第一个 BPM 平台出现以来，这种方法已在许多组织中实施。它通常用于将集成层中的 ESB 服务编排成流程引擎层中定义良好的业务流程。我们可以从两个角度看待这种架构——业务和功能以及技术。

bpm

业务与功能视角

从业务和功能的角度来看，最重要的是业务流程本身。 Camunda 作为业务流程实现的核心，是业务定义规则和监控流程的第一层。每个业务流程都有其负责人负责业务成果和流程执行的可靠性。在流程引擎的顶部，作为最终用户的网关，通常有多个前端和门户，用户决定业务流程的实现。对于业务视角，集成层 API 就像负责数据供应和请求履行的“黑盒”，业务流程所有者不对其行为和数据管理负责。

正如我们所见，IT 团队和业务团队之间的合作主要集中在流程引擎上——而业务流程负责人定义需求和流程模型，而工程师则致力于他们的技术实现。集成和数据治理团队支持流程团队，但他们不负责业务流程和业务功能。

BPM

技术视角

从技术的角度来看，有一个多层的、集成的 IT 架构，它提供了实现业务流程实现的功能。最重要的是，有可以使用多种不同技术（Javascript、PHP、Angular、React 等）交付的前端。在较低级别，有 Camunda，它是业务流程定义的中心。它存储业务规则、决策图表并在前端编排后端集成层功能和 UI 表单。集成层是技术服务供应的中心。在实践中，像 MuleSoft、WebMethods、Oracle ESB 等 ESB 平台通常是集成层。他们的目标是为流程引擎提供具有标准化数据模型的 API。该层负责公开多个系统功能、集成数据、统一协议、管理服务治理和编排简单的技术处理。

BPM

优点与挑战

优点	挑战
这种方法的重要好处是在一个地方定义和监控整个业务流程的简单性。 Camunda BPM Engine 可以轻松跟踪流程，即使是复杂的流程。	变更管理——在变更流程时，可能需要协调前端和集成层中的多项调整。这些层通常由不同的技术（甚至业务）团队负责，从而使此类更改成为多个团队之间的多层计划。
决策规则、任务和业务流程定义在一个平台上处理，业务团队可以使用 Camunda Modeler 设计流程和 Camunda Task List 来完成处理。	数据所有权和治理。业务流程所有者只负责流程实现和结果，而系统所有者和集成架构师只关心数据治理和一致性以及从技术角度来看 IT 系统的可靠性。它可以围绕稳定、可靠的平台引发利益冲突，并推动业务流程调整。
IT 工程师也从他们的编码过程开始使用相同的 Camunda Modeler，因此团队之间在整个过程设计和实施方面的误解空间有限。	由于技术故障和安全方面的原因，拥有一个定义所有业务规则和流程的地方可能会带来潜在的风险。

微服务架构中的 Camunda BPM

微服务架构引入了一种不同的 IT 系统设计方法，其中具有大量业务功能的大型单一单体被专为业务目的设计的较小的自主服务所取代。这样的设计会对业务流程的实施方式产生影响。我们也可以从业务&功能和技术角度来看架构设计，但它们在一个微服务中密切相关，为一个业务领域提供业务功能。

业务与功能视角

从业务和功能的角度来看，将业务流程分解为更小的子流程非常重要，这些子流程专注于在一个业务对象中提供价值和决策。由于没有集中的业务流程引擎，这些子流程对事件流层中的事件做出反应。然后，他们启用自己的业务逻辑并为其他子流程生成结果事件。与 Camunda Monolith BPM Platform 不同，跟踪业务流程实现是在两个层面上完成的：在 Camunda Engine 中的微服务层面提供特定功能，以及在事件流层中跟踪子流程之间的事件。这种流程管理导致不同的组织模型——我们仍然有业务流程所有者，但他们在管理和监控整个流程本身方面的责任较少。相反，他们像乐高积木一样构建他们的流程，使用为组合提供小型子流程的微服务。微服务团队有负责端到端数据管理、与遗留系统和外部系统集成、业务子流程实现甚至最终用户 UI 的领导——无论是从技术角度还是业务角度。这种方法导致小型、敏捷、独立的团队与业务专家和 IT 工程师相结合。

这个概念比经典的分层架构具有更大的灵活性——但也让提供每个业务功能的团队承担更多责任。它可以选择适当的技术、语言、数据库和框架来有效地满足需求。团队全权负责完成业务服务，并与技术和业务专家结合，密切合作——从数据定义开始，到业务处理，最后到最终用户的 UI 表示。

BPM

技术视角

从技术的角度来看，任何分解的子流程都会成为一组在微服务的业务层中实现的功能——在我们的示例中，一个用于客户数据更新，另一个用于风险计算更新。每个微服务都有自己的数据存储和结构，自己的集成 API 层，自己的 Camunda 引擎来实现子流程，甚至自己的 UI 表示。每一层都可以用不同的技术编写——但是在业务层中坚持使用 Camunda 对于构建跟踪和监控整个业务流程的外部架构很有用。子流程通信是通过在一个地方发布事件来完成的，其他子流程也在事件流层中发布和消费事件。在这个架构中至关重要的是，Event Streaming Layer 只是事件共享的管道，不包含任何消息编排逻辑。用于此目的的最常用技术是分布式流和队列平台，如 Kafka、Pulsar 或 Rabbit MQ。

BPM

优点与挑战

优点	挑战
业务流程和技术组合变化的灵活性。业务流程实现被分成小的、独立的、功能性的元素，当新的需求出现时更容易调整。关注这些功能服务的专家团队有责任、知识和权力不断改进它们，从而消除分层架构中单独的技术和业务组之间潜在的利益冲突。工程师和业务部门在 Camunda BPM 上一起工作的好处更加明显，因为在这种模式下，这些专家专注于业务流程的一小部分，因此他们之间可以更有效地共享技术和业务观点。	由松散耦合的子流程组成的业务流程并不容易跟踪和监控。使用一个技术堆栈——Camunda BPM——构建业务处理可以简化这部分，但它仍然不如在 BPM Monolith IT Platform 中跟踪那么简单。
技术的灵活性。在 BPM Monolith Platform 中，当当前的解决方案从技术角度来看已经过时或难以在特定业务需求中使用时，有一个很大的举措是重新编写在那里实现的整个业务流程。借助微服务和分布式子流程，我们可以逐步规划这样的举措，甚至可以尝试多种技术以选择最佳技术。	业务服务组合管理。借助集成平台，所有外部系统功能都具有代表性的 ESB 服务，易于通过标准化合同使用。对于微服务，每一个都暴露了功能性 API，因此制定治理规则至关重要，不仅要规定如何构建和使用它们，还要规定在哪里可以找到它们。
错误的技术决策或重新实施整个业务流程中的人为错误的风险非常低。使用这种方法，即使您认为 Camunda BPM 不再满足所有需求，也可以轻松地以小功能块迁移到其他解决方案。	遗留系统与微服务共存的情况可能具有挑战性。微服务团队和遗留系统业务团队应该围绕数据一致性和数据所有权展开合作。事实上，拥有微服务迟早会导致遗留系统分解，这对整个组织和 IT 系统管理都是一个挑战。

结论

重要的是要记住，并非每个 BPM 平台都可以实现微服务和独立实现模式。使用无代码平台，可能很难在微服务内部实现完整的业务逻辑，因此它们将作为业务流程管理的单一平台更好地工作。使用低代码平台，我们失去了 BPMN 图驱动的开发，只依赖于工程师和业务专家之间的密切理解。这种理解只发生在微服务团队中。 BPM 平台在这里是最灵活的。它们将这两个好处结合在一起：业务分析师的 BPM 图表建模工具，感谢 IT 工程师，它变成了工作代码。 Camunda BPM 是一个平台，可用于两种实现模型。

在 BlueSoft 中，我们设法将 Camunda BPM 合并到两种实施模型中：