BPM工作流引擎常见的术语和概念介绍
Posted 专注于低代码平台、流程引擎技术研究
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了BPM工作流引擎常见的术语和概念介绍相关的知识，希望对你有一定的参考价值。
本文重点介绍BPM业务流程管理中常常用到概念和术语，这些概念同样适用于JBPM、Activiti、Flowable、Camunda等主流的开源流程引擎。
一、BPM模型符号协议
1、BPMN （业务流程模型和标记法）
BPMN：业务流程模型和标记法（BPMN, Business Process Model and Notation）是一套图形化表示法，用于以业务流程模型详细说明各种业务流程。它最初由业务流程管理倡议组织（BPMI, Business Process Management Initiative）开发，名称为"Business Process Modeling Notation"，即“业务流程建模标记法”。
2、CMMN （案例管理模型符号）
Case Management Model Notation 案例管理模型符号。CMMN是一种图形符号，用于捕获基于处理需要各种活动的案例的工作方法，这些活动可能以不可预测的顺序执行以响应不断变化的情况。使用以事件为中心的方法和案例文件的概念，CMMN扩展了可以用BPMN建模的界限，包括结构化工作量减少和知识工作者推动的工作量。使用BPMN和CMMN的组合允许用户覆盖更广泛的工作方法。
3、DMN（决策模型符号）
DMN是决策模型和符号（Decision Model and Notation）的英文缩写，是由BMN背后的组织OMG管理的一个标准。DMN 是一种用于精确规范业务决策和业务规则的建模语言和符号。DMN 旨在与 BPMN 和/或 CMMN 一起工作，提供一种机制来对与流程和案例相关的决策进行建模。虽然 BPMN、CMMN 和 DMN 可以独立使用，但它们经过精心设计以相互补充。BPMN、CMMN和DMN真正构成了流程改进标准的“三冠王”。
二、流程引擎相关术语
1、流程定义（Process Definition）
Process Definition即流程定义，指通过建模生成的一个符合BPMN规范的完整流程模型定义文件。Process Definition定义了流程的结构，或者说定义了业务活动的执行过程。Camunda bpm使用bpmn2.0作为其流程定义的主要建模语言。
2、流向/顺序流（Flow）：
顺序流是连接两个流程节点的连线。顺序流是一端带有箭头的实线，可在图中或单个池中链接流程内的各个元素，并显示各个元素的执行顺序。消息流是一端带有箭头的点线，可链接两个单独的池（或两个单独的池中的元素），并显示消息发送的方向。
3、流程实例（Process Instance）
Process Instance即流程实例。流程实例是流程定义的单独执行，流程定义和流程实例是一对多关系。流程实例与流程定义的关系与面向对象编程中对象与类的关系相同（在这种类比中，流程实例扮演对象的角色，流程定义扮演类的角色）。
流程定义设计完成后，发布到BPM，通过流程引擎解析流程定义，发起一次流程即创建了一个流程实例，比如：创建了一个“请假流程”，这是一个流程定义，张三发起了一次请假流程，即创建了一个流程实例，李四也发起了一次请假，就是创建了另一个流程实例，这两个实例均基于流程定义创建生成。
4、执行实例（Execution）
Execution即流程执行实例，如果流程实例包含多个执行路径（例如，在并行网关之后），则会同时产生多个执行实例，即execution, 通过excutionId能够区分流程实例内的当前活动路径。
Execution（执行）是分层的，流程实例中的所有Execution（执行）组成一个树，Process Instance（流程实例）是树中的根节点，Process Instance（流程实例）本身就是一个Execution（执行）。
5、活动实例（Activity Instance）
Activity Instance即活动实例，活动实例概念与执行概念类似，但采用了不同的视角。虽然可以将执行想象为在流程中移动的令牌，但活动实例表示活动（任务、子流程等）的单个实例。因此，活动实例的概念更面向状态。
6、任务（Task）
task 所有的任务都是活动，但是活动不全是任务，任务是一个流程的节点，但是并非所有流程节点都是任务。
用户任务： 就是需要用户参与触发的任务。
服务任务： 服务任务又可以划分为各种各样的服务任务。
7、服务任务（Service Task）
Camunda中的Service Task（服务任务）用于调用服务。在Camunda中，可以通过调用本地Java代码、外部工作项、web服务形式实现的逻辑来完成的。
8、脚本任务（Script Task）
在Camunda中，脚本任务是一个自动活动，当流程执行到脚本任务时，相关的脚本自动执行。camunda支持大多是兼容JSR-223的脚本引擎实现，比如Groovy, JavaScript, JRuby and Jython。
9、定时任务（Job and Job Definition）
Job and Job Definition即作业执行器，Camunda流程引擎包含一个名为Job Executor的组件。作业执行器是一个调度组件，负责执行异步后台工作。考虑一个计时器事件的例子：每当流程引擎到达计时器事件时，它将停止执行，将当前状态保存到数据库，并创建一个作业以在将来继续执行。部署流程时，流程引擎会为流程中的每个活动创建作业定义，这些活动将在运行时创建作业。
10、事件（event）
event 事件是BPMN流程建模元素，表示在流程过程中“发生”的事情，事件会影响流程的走向。BPMN定义了不同的事件类型。事件包含开始（Start）、中间（Intermediate）、边界（Boundary）和结束（End）四种类型。根据触发方式不同，可以分为捕获事件（Catching Event）和抛出事件（Throwing Event）。
详细参考：https://lowcode.blog.csdn.net/article/details/122886122
11、流程变量（Process Variable）
Process Variable即流程变量，流程变量在整个工作流中扮演很重要的作用，是业务和流程引擎之间交互信息的载体，业务可以把数据放到流程变量里传递给流程引擎，流程引擎也可以把信息放到流程变量给传递给业务，流程变量最常见的用途有路由条件表达式、流程执行事件参数等。例如：请假流程中有请假天数、请假原因等一些参数都为流程变量的范围。流程变量的作用域范围是流程实例，也就是说各个流程实例的流程变量是不相互影响的。
12、网关（Gateways）
Gateway是BPMN2规范中的流程定义元素，中文可称为“网关”、“决策”、“判断”。网关用来控制流程的执行流向，当在拆分路径时产生令牌，在合并路径时消费令牌。常用网关可分为排他网关（XOR）、并行网关（AND）和包容网关（OR）。BPMN2.0规范中提供了bpmn:exclusiveGateway排他网关标签、bpmn:parallelGateway并行网关标签来定义，activiti、flowable、camunda等开源工作流引擎均支持该标签。
13、泳道（Swimlanes）
BPMN中的泳道对象(也称为泳道)是表示业务流程参与者的矩形框。泳道可能包含由该泳道(参与者)执行的流对象，除了必须有一个空体的黑盒子。泳道可以水平排列，也可以垂直排列。它们在语义上是相同的，只是表示不同。对于水平泳道，流程从左到右流动，而垂直泳道中的流程从上到下流动。泳道的例子包括客户、客户部门、支付网关和开发团队。
池（Pools）：pool代表业务流程中的参与者。它可以是一个特定的实体(如部门)或一个角色(如助理经理、医生、学生、供应商)。
游道（Lanes）：lane是池的子分区。例如，当您有一个池部门时，您可以将部门主管和普通职员作为泳道。与池一样，您可以使用lane来表示流程中涉及的特定实体或角色。
14、子流程（SubProcess）
子流程是包含其他活动、网关、事件等的活动，其本身形成的流程是更大流程的一部分。子流程完全在父流程中定义(这就是为什么它通常被称为嵌入式子流程)。
BPMN 2.0区分了嵌入式子流程（Embedded Subprocess）和调用活动（Call Activity）。从概念上看，当流程执行到达活动时，两者都将调用子流程。
不同之处在于，调用活动引用流程定义外部的流程，而子流程嵌入在原始流程定义中。调用活动的主要用例是拥有可重用的流程定义，可以从多个其他流程定义调用该定义。子流程的流程定义是在运行时解析的。如果需要，也可以独立调用子流程。
当流程执行到达调用活动时，将创建一个新的流程实例，该实例用于执行子流程，可能会像在常规流程中那样创建并行子执行。主流程实例将一直等待，直到子流程完全结束，然后继续原始流程。
子流程允许分层建模。许多建模工具允许折叠子流程，隐藏子流程的所有细节，并显示业务流程的高级端到端概述。
15、特别流程（Ad-hoc）
临时流程是一组业务活动和相应的工件（例如，信息，决策和产品），只能在高级别的聚合中进行标准化。实际的活动种类及其排序因个案而异。临时流程在国内也被称为“任意流”。以下是Ad-hoc流程的特征：
虽然可以预测某些活动，但是一开始就无法完全指定大部分过程，因为它需要的信息只能以某种方式进入项目。
如果我们假设在ad-hoc流程的上下文中永远不会确定下一步，则它们的执行不能由传统的基于流程的信息系统控制，在大多数情况下，知识工作者可以控制流程。
似乎不可能在设计时考虑临时过程的所有可能性，这样的过程模型将变得复杂且难以管理。
16、部署（deployment）
Deployment（部署）是指将流程定义发布到工作量引擎中之后称为deployment。
17、身份管理（IDM）
提供SSO功能凭证管理工作，可以用来管理权限、用户、组
18、流程设计器（Modeler）
模型管理工具，用于定义流程模型、表单及应用定义。在Camunda BPM中，提供了C/S流程建模工具（Modeler）和B/S流程建模工具（Web-based tooling for BPMN, DMN, CMMN, and Forms | bpmn.io），用户通过拖拉拽的方式设计流程图，这个设计完的xml文件就是流程定义。
19、表单（Form）
form 表单配置给每个流程节点使用，如请假申请中需要用户填写请假天数事由，审批节点中需要审批人填写审批意见等。
三、中国特色流程操作概念
1、会签
会签是一种联合审批的特殊审批流程，可理解为一种多人投票机制，一个任务需要多个人同时处理，然后汇总多个人的意见，决定流程下一步该如何执行。流程设计时，若会签审批节点中设置多个参与人，流程运行时，会签节点任务需要多人共同处理，然后汇总多人的处理意见，决定会签节点的处理结果。
会签分并行会签和顺序会签两种：
- 并行会签：指同一个审批节点设置多个人，如A、B、C三人，三人会同时收到待办任务，需全部同意之后，审批才可到下一审批节点。
- 顺序会签：指同一个审批节点设置多个人，如A、B、C三人，三人按顺序依次收到待办，即A先审批，A提交后B才能审批，需全部同意之后，审批才可到下一审批节点。
免费在线体验系统：http://www.yunchengxc.com
2、或签
一个流程审批节点里有多个处理人，任意一个人处理后就能进入下一个节点。例如：员工发起采购申请，提交给多名领导审批，只要有一名领导同意即可提交到下一节点。
BPMN2.0规范中提供了bpmn:multiInstanceLoopCharacteristics多实例循环的模型定义，并通过bpmn:completionCondition标签定义多实例完成条件，activiti、flowable、camunda等开源工作流引擎均支持该属性。
3、抄送
抄送：将审批结果通知给抄送列表对应的人。
4、驳回
驳回：将审批重置发送给某节点，重新审批。驳回也叫退回，也可以分退回申请人、退回上一步、任意退回等。
- 退回申请人： 直接把流程退回给申请节点
- 退回上一步： 退回流程上一节点
- 退回任意节点： 退回到流程走过任意一个节点
5、转办
转办：A转给其B审批，B审批后，进入下一节点。
6、委派
委派：A转给其B审批，B审批后，转给A，A审批后进入下一节点。
7、跳转
跳转：可以将当前流程实例跳转到任意办理节点
8、拿回
拿回：在当前办理人尚未处理文件前，允许上一节点提交人员执行拿回
9、撤销
撤销：流程发起者可以对流程进行撤销处理
10、催办
催办：可以给当前办理人员发送催办通知消息
11、加签
加签：允许当前办理人根据需要自行增加当前办理节点的办理人员
12、减签
减签：在当前办理人操作之前减少办理人
BPM技术Zeebe是一个用于微服务编排的工作流引擎。
Zeebe是一个用于微服务编排的工作流引擎。
这篇文章将帮助你确切地了解什么是Zeebe以及它如何可能与你相关。我们将简要介绍Zeebe以及它所解决的问题，然后再进行更详细的介绍。
我们将在整个写作过程中使用“工作流”这个词，根据您的背景，在微服务的环境中您可能不熟悉这个词。当我们说“工作流”时，我们的意思是“允许我们实现某个目标的一系列任务”。“工作流”可以与“业务流程”或“流程”同义使用。
在Zeebe编排的工作流中，每个任务通常由不同的微服务执行。
介绍
公司的端到端工作流几乎总是跨越多个微服务。例如，在电子商务公司中，“客户订单”工作流可能涉及支付微服务、库存微服务、配送微服务等等。
这些跨微服务工作流是公司的核心收入驱动因素，但它们很少被建模和监控;通常，通过不同微服务的事件流仅在代码中隐含地表示。
如果是这样，我们如何确保工作流的可见性并提供状态和错误监视?我们如何保证整个流始终是完整的，即使单个微服务失败?或者我们如何至少认识到一个流程被卡住了所以我们可以进去并修复它?
Zeebe是一个免费的、源代码可用的微服务编制工作流引擎，它提供:
对公司端到端的工作流状态的可见性，包括正在运行的工作流的数量、平均工作流持续时间、工作流中的当前错误，等等。
根据工作流的当前状态编制工作流;Zeebe将“命令”作为事件发布，可以由一个或多个微服务使用，确保工作流按照其定义进行。
监视超时或其他流程错误，以及配置错误处理路径的能力，例如有状态重试或向能够手动解决问题的团队升级，确保工作流始终按计划完成。
Zeebe被设计用来解决非常大规模的微服务编排问题，为了实现这一点，它提供:
横向可伸缩性，不依赖于外部数据库;相反，Zeebe直接将数据写入部署它的服务器上的文件系统，并且可以轻松地跨计算机集群分发处理，从而提供高吞吐量。
通过易于配置的复制机制实现容错，确保Zeebe可以从机器或软件故障中恢复，而不会造成数据丢失和最小的停机时间。
一种消息驱动的体系结构，其中所有与工作流相关的事件都被写入仅用于追加的日志。这些事件可以导出到外部系统进行长期存储，以提供一个完整的工作流审计日志。
发布-订阅交互模型，它允许连接到Zeebe的微服务在提供处理反压力机制的同时保持高度的控制。
在iso标准BPMN 2.0中建模的可视化工作流，使得技术和非技术涉众可以用一种公共语言协作进行工作流设计。
与语言无关的客户机模型，使得用组织用来构建微服务的几乎任何编程语言构建Zeebe客户机成为可能。
您可以在文档中了解有关这些技术概念的更多信息。
如果您只需要看这些，并且您认为Zeebe可能适合您，我们鼓励您尝试一下。现在就可以下载了。入门教程是不需要编写任何代码就可以动手操作的好方法。
如果你有问题，请联系Zeebe社区。你可以在Zeebe论坛上发布一个问题，或者在我们的Slack频道与Zeebe开发者合作。我们希望收到你的来信。
Zeebe现在可以用于生产。您可以在这里看到路线图。
如果你想了解更多关于Zeebe的信息，你可以继续阅读。在这篇文章的其余部分，我们将更详细地讨论三个主题:
Zeebe解决的问题和它的重要性
Zeebe如何解决这个问题
为什么Zeebe很适合解决这个问题
Zeebe解决的问题和它的重要性
微服务体系结构近年来变得越来越流行，这是有原因的。专注的、跨功能的团队在使用他们选择的技术堆栈时可以快速、独立地交付价值。
但是使微服务体系结构如此吸引人的原则——松耦合、独立的部署周期——也带来了重大的挑战。
微服务体系结构的核心原则是每个微服务只负责一种业务功能。我们将再次引用引言中的电子商务示例，其中一个微服务负责支付处理，另一个负责库存，另一个负责运输，等等:
每个微服务的存在都是为了促进更广泛的工作流程:尽可能快速有效地为购物者提供他们想要的服务。而只有在端到端工作流成功的情况下，公司才会成功，因此确保工作流的质量至关重要。
在微服务体系结构中，每个微服务只负责严格限定范围的业务功能，谁负责端到端工作流?
默认情况下，没有人。实际上，端到端工作流甚至可能没有在公司内部正式文档化，从微服务到微服务的事件流仅在代码中隐式地表示。
许多微服务体系结构依赖于纯编舞（choreography）模式进行通信，其中微服务通过在没有中央控制器(也称为发布-订阅或发布-订阅模型)的情况下向消息传递平台发布事件和使用事件进行协作。编舞（choreography）确实为微服务的开发人员提供了一定程度的灵活性。
然而，在其典型的实现中，编舞（choreography）并不提供:
对业务当前状态的可见性:有多少端到端工作流实例正在进行中，它们的状态是什么?在过去24小时内，有多少工作流实例没有成功完成?为什么这些工作流实例没有成功完成?完成一个工作流实例或工作流中的一个特定步骤的平均时间是多少?
故障处理以确保即使在错误发生时工作流也能完成:如果作为工作流一部分的服务失败，谁负责处理该故障?工作流的重试逻辑是什么?如果需要人为干预，我们有什么规则来及时解决问题升级?
注意:当我们说“工作流实例”时，我们指的是“工作流的一次出现”。在电子商务示例中，单个工作流实例将是单个客户订单。
因此，微服务体系结构面临产生好的软件(在微服务级别)但产生坏的业务结果的风险。毕竟，工作流的成功最终决定了业务的成败。
开发团队如何在确保健壮的端到端工作流的同时获得微服务体系结构的好处?
这就是Zeebe的作用。
Zeebe如何解决这个问题
Zeebe是一个工作流引擎。如果你是工作流引擎的新手，这里有一个维基百科提供的通用定义:
工作流引擎是管理业务流程的系统。它监视工作流中活动的状态，并根据定义的流程确定要转换到哪个新活动。
标签“工作流引擎”与缓慢、低吞吐量的用例(如人工任务管理)有遗留关联。
另一方面，Zeebe提供高吞吐量、低延迟和水平可伸缩性（provides high throughput, low latency, and horizontal scalability. ）。为了解释原因，让我们介绍一些Zeebe的关键架构概念。
首先，Zeebe不需要中央数据库组件，而是利用了事件源，这意味着对工作流状态的所有更改都作为事件捕获，并存储在仅用于追加的日志中。在Zeebe中，这个日志被称为“主题”。主题被直接写入运行Zeebe的服务器上的文件系统，工作流的当前状态可以从存储在主题中的事件中派生出来。
为了实现可伸缩性，主题可以很容易地分布在集群(分区)中的多个节点上，分区通常存储在多个节点上(复制)，以实现容错。
Zeebe使用客户机/服务器模型。服务器(代理)是一个远程引擎，作为它自己的程序在Java虚拟机上运行。代理负责存储与工作流相关的主题，在适当的时候将工作项分发给客户端，并通过发布-sub将工作流事件流公开给Zeebe客户端。Zeebe客户机可以嵌入到应用程序中以连接到代理。
如果您使用过Apache Kafka、Apache Pulsar或类似的消息传递系统，那么您可能对这种架构很熟悉。如果您想了解更多关于Zeebe的核心概念，请查看文档。
现在让我们讨论一下Zeebe如何在更实际的术语中解决端到端工作流问题。Zeebe使用户能够:
显式地定义和建模跨越多个微服务的工作流
获得工作流如何执行的详细可见性，并了解哪里存在问题
编排完成已定义工作流的微服务，以确保所有工作流实例都按照计划完成——即使在过程中出现问题
在下面的部分中，我们将讨论如何在一般意义上使用Zeebe，而不使用代码示例。在未来，我们可能会分享“蓝图”来演示如何准确地构建这些解决方案，如果社区认为它有用的话。
用Zeebe解决工作流问题，第1步:感知工作流的事件监控
工作流感知事件监视是Zeebe对我们上面定义的可见性问题的回答。
回顾一下:
您的业务依赖于一个或多个长时间运行的工作流的成功完成
这些工作流是由独立开发和独立部署的微服务执行的，这些微服务通过发布-订阅进行通信，没有中央控制机制
尽管您可以洞察到给定微服务的性能，但您对工作流的端到端运行状况以及业务的当前状态几乎没有可见性
Zeebe可以与已经在事件驱动架构中使用的组件一起工作，而不需要替换或删除任何现有系统来提供工作流可见性。
下面是一个简单的图表，展示了Zeebe如何用于跨微服务的工作流的可见性:
在本例中，Zeebe订阅发布到您的消息传递平台的事件，并将它们与预定义的工作流相关联，工作流已在BPMN 2.0中可视化建模并部署到Zeebe代理中(要了解有关Zeebe工作流的更多信息，请参阅文档)。
Zeebe处理的与工作流相关的事件可用于为仪表板提供动力，构建揭示工作流中问题区域的热图，以及在工作流实例出现问题并需要关注时构建警报工具。
在此实现中，Zeebe超出了监视单个微服务运行状况的范围，并提供了以下可见性:
业务的当前状态:当前有多少跨微服务工作流正在运行，它们的状态是什么?
是否有正在运行的进程由于错误或其他问题而“卡住”?
我们的平均端到端流程持续时间是多长?我们在流程的哪些地方遇到了问题?
在本例中，Zeebe纯粹作为“侦听器”操作，不直接与参与工作流的微服务交互。让我们讨论一下如何扩展这个“可见性”解决方案，以利用Zeebe的编排功能。
用Zeebe解决工作流问题，步骤2:微服务编制
Microservices编排是Zeebe对我们在本文前面讨论的失败处理和重试问题的回答。
在微服务社区中，微服务编排有时被认为与核心微服务原则(如松散耦合和独立可部署性)不一致。但事实并非如此!微服务编排可以按照符合这些原则的方式实现，Zeebe也相应地设计了。
下面是一个简单的图表，展示了Zeebe如何用于微服务编排:
该体系结构与我们上面描述的“Zeebe for visibility”体系结构非常相似。一个显著的区别是，在我们的图中，我们删除了消息传递平台层，而Zeebe直接与参与工作流的微服务通信。
仍然可以在不删除现有消息传递平台的情况下使用Zeebe进行微服务编排——除了订阅与工作流相关的事件(如“可见性”解决方案中所示)之外，Zeebe还可以简单地将事件发布到消息传递平台。
但是Zeebe也可以在没有消息传递平台的情况下使用，这里我们想强调一下这种方法。
您可以将Zeebe的工作流编制方法视为状态机。当工作流实例进展到某个任务时，Zeebe发送一条消息通知负责的worker服务，然后等待该worker完成任务。
任务完成后，worker服务通知Zeebe，流继续执行下一个步骤。如果工作人员未能完成任务，工作流将保持在当前步骤，可能会重新尝试该任务，直到最终成功，或者如果需要人工干预，将其升级到另一个团队。
Zeebe将任务通知消息的创建与工作的实际执行分离开来，这意味着Zeebe可以以最大的可能速率发送任务通知消息，而不管是否有工作人员服务可用来承担工作。
Zeebe将任务通知排队，直到它能够将它们推送给工作人员。如果当前没有工作人员服务可用，工作消息将保持排队状态。如果工人服务订阅了，Zeebe的背压协议确保工人可以控制他们接收任务的速度。
这种微服务编排方法仍然提供了工作流和工作流实例的完整可见性，同时也确保工作流按照其定义完成，即使在过程中出现了故障。
为什么Zeebe很适合解决这些问题?
Zeebe 支持横向扩展
扩展以处理高吞吐量工作负载的能力对于Zeebe在微服务编排中的角色至关重要。为了处理大量的工作流实例，可能需要跨计算机集群分发Zeebe，以满足吞吐量需求。
Zeebe使用分区来提供水平可伸缩性，并且基于我们的内部基准测试，分区提供了一种有效的方法来扩展到每秒启动数千个工作流实例，即使在一个相对较小的(5个节点)集群上也是如此。
Zeebe具有容错能力和高可用性
Zeebe允许用户在创建主题时配置复制因子。复制因子决定在其他代理上存储一个分区的多少个“热备用”副本。如果一个代理宕机，另一个代理可以替换它，不会造成数据丢失。由于数据分布在集群中的多个代理中，Zeebe提供了容错和高可用性，而不需要外部数据库，直接将数据存储在部署数据的服务器的文件系统上。Zeebe也不需要外部集群协调器(如ZooKeeper)。Zeebe是完全自给自足的。
Zeebe允许可视化地定义工作流
ISO-standard BPMN 2.0是在Zeebe中定义工作流的默认建模语言。工作流是在技术和非技术涉众的充分参与下可视化地定义的。虽然Zeebe对BPMN符号的覆盖不如Camunda BPM等更成熟的BPM平台那么全面，但Zeebe的路线图包括定期添加对新符号的支持。
Zeebe是语言不可知论者
目前，Zeebe提供了两个开箱即用的Java客户机和Go客户机。Zeebe客户机基于gRPC，这意味着可以用组织通常用于构建微服务的许多编程语言轻松生成Zeebe客户机。这里提供了grpc支持的编程语言列表。
Zeebe是完全消息驱动的
Zeebe代理和客户端完全通过发布-订阅进行通信，这使得遵循松耦合原则并支持Zeebe和参与工作流的微服务之间的异步通信成为可能。Zeebe的订阅协议包括一个backpressure机制，以确保客户机不会因来自Zeebe的工作而超载。
Zeebe可以方便地存储用于审计的事件的完整历史
Zeebe导出器使工作流事件数据流化到存储系统变得很容易，因此这些数据可以无限期地使用。这对于报告和可见性很重要，而且根据您的行业，出于监管原因，这可能也是必要的。
Zeebe听起来不错，但我有一个在microservices编配之外的用例。我能用Zeebe吗?
是的,当然!我们经常在微服务编制用例的上下文中讨论Zeebe，因为Zeebe能够很好地解决这个问题，但是Zeebe可以应用于微服务编制之外的用例。
Zeebe是一个工作流引擎，可以处理广泛的高吞吐量用例。以下是Zeebe的一些一般特点:
Zeebe在设计时考虑了大规模工作流(每秒最多可以启动数万个新的工作流实例)。Zeebe不依赖于外部数据库，而是将数据以不可变日志的形式直接存储在部署Zeebe的服务器上;这个体系结构对于Zeebe处理高吞吐量和水平伸缩的能力非常关键。
目前，Zeebe代理和外部服务之间的所有通信都由Zeebe的客户端处理。Zeebe的客户机协议与编程语言无关，这意味着可以用许多常用编程语言轻松生成客户机。
Zeebe目前涵盖的BPMN符号比Camunda BPM等更成熟的工作流引擎还少。然而，Zeebe定期添加对新符号的支持，并且最终，Zeebe将提供对工作流自动化有意义的BPMN符号的完整覆盖。
我如何开始用Zeebe?
首先，感谢您的阅读!我们希望您能够清楚地理解我们为什么要构建Zeebe以及它如何能够帮助您。
要开始使用Zeebe，我们建议您:
阅读Zeebe的核心技术概念:Zeebe文档的“概述”部分介绍了Zeebe背后的一些关键思想和概念。
安装Zeebe:安装指南向您展示在哪里可以找到Zeebe的最新发行版，以及如何在Docker上运行Zeebe，然后指导您完成成功的安装。
尝试入门教程:获得动手和学习端到端Zeebe经验，从在Zeebe Modeler中建模，到使用Zeebe命令行界面创建和完成工作流实例，再到可视化操作中发生的事情。
在论坛中问一个问题:Zeebe文档中的“获取帮助和参与”页面包含了Zeebe论坛和我们的公共Slack频道的链接，这两个链接都可以用来与Zeebe工程团队取得联系。我们渴望听到问题和反馈。
本文：http://jiagoushi.pro/node/1211
| 微信公众号 | 【首席架构师智库】 适合物业仔细反复阅读。 精彩图文详解架构方法论，架构实践，技术原理，技术趋势。 我们在等你，赶快扫描关注吧。 |
 |
| 微信小号 | 50000人社区，激烈深度讨论：企业架构，云计算，大数据，数据科学，物联网，人工智能，安全，全栈开发，DevOps，数字化. |
 |
| QQ群 | 深度交流企业架构，业务架构，应用架构，数据架构，技术架构，集成架构，安全架构。以及大数据，云计算，物联网，人工智能等各种新兴技术。 |
|
| 视频号 | 【首席架构师智库】 1分钟快速了解架构相关的基本概念，模型，方法，经验。 每天1分钟，架构心中熟。 |
|
| 知识星球 | 向大咖提问，近距离接触，或者获得私密资料分享。 | |
| 微信圈子 | 志趣相投的同好交流。 | |
| 喜马拉雅 | 路上或者车上了解最新黑科技资讯，架构心得。 | |
| 知识星球 | 认识更多朋友，职场和技术闲聊。 |
以上是关于BPM工作流引擎常见的术语和概念介绍的主要内容，如果未能解决你的问题，请参考以下文章