介绍
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 服务编排成流程引擎层中定义良好的业务流程。我们可以从两个角度看待这种架构——业务和功能以及技术。
业务与功能视角
从业务和功能的角度来看，最重要的是业务流程本身。Camunda 作为业务流程实现的核心，是业务定义规则和监控流程的第一层。每个业务流程都有其负责人负责业务成果和流程执行的可靠性。在流程引擎的顶部，作为最终用户的网关，通常有多个前端和门户，用户决定业务流程的实现。对于业务视角，集成层 API 就像负责数据供应和请求履行的“黑盒”，业务流程所有者不对其行为和数据管理负责。
正如我们所见，IT 团队和业务团队之间的合作主要集中在流程引擎上——而业务流程负责人定义需求和流程模型，而工程师则致力于他们的技术实现。集成和数据治理团队支持流程团队，但他们不负责业务流程和业务功能。
技术视角
从技术的角度来看，有一个多层的、集成的 IT 架构，它提供了实现业务流程实现的功能。最重要的是，有可以使用多种不同技术（Javascript、PHP、Angular、React 等）交付的前端。在较低级别，有 Camunda，它是业务流程定义的中心。它存储业务规则、决策图表并在前端编排后端集成层功能和 UI 表单。集成层是技术服务供应的中心。在实践中，像 MuleSoft、WebMethods、Oracle ESB 等 ESB 平台通常是集成层。他们的目标是为流程引擎提供具有标准化数据模型的 API。该层负责公开多个系统功能、集成数据、统一协议、管理服务治理和编排简单的技术处理。
优点与挑战
微服务架构中的 Camunda BPM
微服务架构引入了一种不同的 IT 系统设计方法，其中具有大量业务功能的大型单一单体被专为业务目的设计的较小的自主服务所取代。这样的设计会对业务流程的实施方式产生影响。我们也可以从业务&功能和技术角度来看架构设计，但它们在一个微服务中密切相关，为一个业务领域提供业务功能。
业务与功能视角
从业务和功能的角度来看，将业务流程分解为更小的子流程非常重要，这些子流程专注于在一个业务对象中提供价值和决策。由于没有集中的业务流程引擎，这些子流程对事件流层中的事件做出反应。然后，他们启用自己的业务逻辑并为其他子流程生成结果事件。与 Camunda Monolith BPM Platform 不同，跟踪业务流程实现是在两个层面上完成的：在 Camunda Engine 中的微服务层面提供特定功能，以及在事件流层中跟踪子流程之间的事件。这种流程管理导致不同的组织模型——我们仍然有业务流程所有者，但他们在管理和监控整个流程本身方面的责任较少。相反，他们像乐高积木一样构建他们的流程，使用为组合提供小型子流程的微服务。微服务团队有负责端到端数据管理、与遗留系统和外部系统集成、业务子流程实现甚至最终用户 UI 的领导——无论是从技术角度还是业务角度。这种方法导致小型、敏捷、独立的团队与业务专家和 IT 工程师相结合。
这个概念比经典的分层架构具有更大的灵活性——但也让提供每个业务功能的团队承担更多责任。它可以选择适当的技术、语言、数据库和框架来有效地满足需求。团队全权负责完成业务服务，并与技术和业务专家结合，密切合作——从数据定义开始，到业务处理，最后到最终用户的 UI 表示。
技术视角
从技术的角度来看，任何分解的子流程都会成为一组在微服务的业务层中实现的功能——在我们的示例中，一个用于客户数据更新，另一个用于风险计算更新。每个微服务都有自己的数据存储和结构，自己的集成 API 层，自己的 Camunda 引擎来实现子流程，甚至自己的 UI 表示。每一层都可以用不同的技术编写——但是在业务层中坚持使用 Camunda 对于构建跟踪和监控整个业务流程的外部架构很有用。子流程通信是通过在一个地方发布事件来完成的，其他子流程也在事件流层中发布和消费事件。在这个架构中至关重要的是，Event Streaming Layer 只是事件共享的管道，不包含任何消息编排逻辑。用于此目的的最常用技术是分布式流和队列平台，如 Kafka、Pulsar 或 Rabbit MQ。
优点与挑战
结论
重要的是要记住，并非每个 BPM 平台都可以实现微服务和独立实现模式。使用无代码平台，可能很难在微服务内部实现完整的业务逻辑，因此它们将作为业务流程管理的单一平台更好地工作。使用低代码平台，我们失去了 BPMN 图驱动的开发，只依赖于工程师和业务专家之间的密切理解。这种理解只发生在微服务团队中。BPM 平台在这里是最灵活的。它们将这两个好处结合在一起：业务分析师的 BPM 图表建模工具，感谢 IT 工程师，它变成了工作代码。Camunda BPM 是一个平台，可用于两种实现模型。
谢谢大家关注，转发，点赞和点在看。
