category
我们正在构建Zeebe作为下一代工作流引擎，用于新兴用例，例如微服务编排用例，这些用例可能需要引擎每秒处理数十万（或数百万）个新工作流实例。
为此，我们使用的图形建模标准已经存在了近15年：BPMN（业务流程模型和表示法）。
尽管BPMN是经过实战考验的ISO标准，但很可能你们中的许多人从未亲自动手或者甚至没有听说过它。
或者更糟糕的是，您已经听说过BPMN，但您已将其作为一种仅在单片或SOA世界中相关的遗留技术编写。
上个月，我们从黑客新闻评论者那里得到了这句话（我们保证他们不是Zeebe团队的隐身成员）：
“BPMN是我们IMO领域最被低估的技术。”
我们不能同意，并且本着这种精神，我们将发布一个关于BPMN和微服务编排的两部分博客系列 - 更具体地说，为什么BPMN非常适合工作流程中的新兴用例世界。
在第1部分中，我们将：
- 提供BPMN的快速介绍
- 说明为什么过去蓬勃发展的成熟标准也能在未来蓬勃发展
- 查看BPMN支持的常见业务流程模式
- 讨论Zeebe中BPMN的当前状态和未来计划
在第2部分中，我们将：
- 深入了解BPMN的图形模型（以及定义工作流程的其他方法）
- 看一下使用图形模型而不是基于代码的模型大大简化工作流程定义的示例
关于BPMN的简短入门
BPMN是一种广泛使用的建模标准，用于定义和执行业务流程。 2004年首次发布（随着2011年的现代BPMN 2.0规范 - 这是Zeebe使用的），BPMN自2013年以来一直是ISO标准。
BPMN用于定义图形模型和所谓的执行语义。换句话说，可视模型存储为XML文件，该文件可以直接在引擎上执行，该引擎保持运行工作流实例的持久状态。
举一个例子，下面的模型用这个XML表示。
重要的是要说BPMN不涉及代码生成而且没有转换！ XML本身就是源代码。 BPMN只关注流程 - 您可以将正常代码用于解决方案的所有其他方面。
这是微服务编排的关键点，外部工作人员在您的工作流程中执行任务。 当与正确的引擎结合使用时，BPMN可以轻松地将工作流中的任务连接到微服务，并且这样做的方式不会违反松散耦合和服务独立性的原则。
扩展上面的示例订单工作流程，我们可以构建3个不同的微服务来处理付款，库存和运输。 工作流引擎负责在流程的正确位置将工作发送到正确的服务。
最后，有BPMN的成熟度。 BPMN非常受欢迎且已经成熟，并且已经证明了它在大型和小型公司的许多工作流程自动化项目中的价值。出于这个原因，市场上已经有很多经验丰富的BPMN人才以及教程和书籍，使新手很容易学习这个标准。
一切听起来都不错。但BPMN可以处理我喜欢的新架构吗？
我们暂时进入隐喻模式。
虽然有关汽车历史的具体细节尚未引起争议，但很多人都赞扬卡尔·奔驰在1886年建造了第一辆汽车并将其带到德国曼海姆附近。在过去130年左右的时间里，汽车 - 在这种情况下，字面意思是“引擎” - 已经发展了很多。
然而，“流动”仍然是相当静止的。帮助我们从A点安全地到达B点的道路，标志和法律仍然遵循许多几十年前实施的相同模式。这可能最终会改变（参见：Hyperloop，无人机），但重点是给定的“流动模式”可以支持许多重要的“引擎”进步。
因此，当我们评估像BPMN这样完善的标准时，我们必须区分“流量要求”和“引擎要求”。
BPMN已经围绕流动提出了许多模式，这些模式是永恒的。按顺序或并行执行一系列活动可以应用于更传统的BPMN用例，例如人工任务管理以及在AWS中调用无服务器功能。等待打印和签名文档的传入副本在模式方面与在事件流体系结构中关联多个消息具有可比性。
确实改变的是吞吐量（工作流实例的数量）以及性能和可伸缩性要求。这些问题可以通过执行相同流语言的新引擎来解决 - 这就是我们使用Zeebe所采用的方法，Zeebe可以扩展到每秒数百万个新的工作流实例。
另一种方法是构建一个新引擎，并在您使用时发明一种新的流语言。但是使用新的流语言，你不可避免地会花时间解决BPMN中已经解决的问题。而且您可能无法有效地或以所有利益相关者都能轻易理解的方式解决这些问题。
我们将在本系列的第2部分详细阐述这个想法，我们将比较BPMN中表达的复杂的现实工作流模式与Amazon States Language。
现在，让我们回顾一下常见工作流模式的示例，以帮助说明为什么我们非常有信心BPMN是微服务编排和其他下一代工作流用例的正确流程语言。
在BPMN中定义业务流程模式
我们不打算在这篇文章中提供完整的BPMN教程。我们的目标是让您了解您可以使用的构建块的子集，并提供一些如何使用它们的示例。
如果您愿意，这不应该阻止您深入了解BPMN。我们上面提到的Camunda的BPMN教程是一个开始的好地方，我们的BPMN参考也是如此。
您也可以开始使用我们的Zeebe特定的图形建模工具，我们将在本系列的第2部分中详细介绍图形模型。
现在进入模式。
顺序流程，决策和并行处理
BPMN的核心是序列流，它定义了工作流中的步骤的执行顺序。
正如您可能想象的那样，将工作流限制为一个简单的一个接一个的任务序列会使许多现实世界的业务逻辑无法解决。除了任务（工作单元）之外，BPMN工作流还包括网关（引导流程）和事件（代表工作流可以响应或通知其他系统的事件）。
BPMN提供用于基于关联数据（专用网关）将工作流实例路由到单个序列流的构造，以及用于需要并行执行的一个或多个序列流（并行网关）的构造。
消息与超时的关联
BPMN的接收任务是标准为消息关联提供支持的一种方式，这是一种非常强大的功能，可以将等待的工作流实例向前移动，或者只有在消息可以正确匹配（“关联”）时才能执行其他操作 正在使用公共标识符等待它的特定工作流实例。
这是一项特别难以从头开始构建然后大规模支持的功能 - 并且BPMN与正确的引擎相结合，您可以开箱即用。
BPMN对发送和接收消息的支持意味着模型可以与消息驱动的体系结构无缝集成，这种体系结构在微服务领域尤为常见。
工作流程可以通过某些类型的消息启动; 它们还可以发出要由下游系统使用的消息。 或者工作流实例可以基于接收的消息结束。 例如，可以响应于与特定订单相关联的传入订单取消消息来终止正在进行的工作流实例 - 诸如电子商务公司中的订单履行过程。
正如您将看到的那样（我们将经常重复），可以轻松组合不同元素，这是BPMN如此强大的原因。
例如，接收任务可以与Timer事件组合，以便如果所需消息未在4小时内到达，则任务“超时”并且工作流实例遵循不同的路径。
多条消息的相关性
将一条消息与工作流实例相关联是有帮助的，但如果需要关联两个，三个或十个，该怎么办？
BPMN也涵盖了这种模式。 通过将接收任务与并行网关相结合，您可以等待两个或多个消息同步并合并其有效负载，然后再向前移动工作流实例。
让我们更进一步，将此模式与超时结合起来。
同样，下图中添加的计时器和子流程只是一个例子，说明了如何组合不同的BPMN元素来表达复杂的流程; 当然，某些组合在某种程度上没有逻辑意义，对于如何连接BPMN符号以定义工作流程基本没有限制。
等待任意数量的消息
在某些情况下，我们可能不知道需要等待多少消息将与给定的工作流实例相关联。
考虑一个示例，在我们继续工作流程之前，我们需要为订单中的每个项目接收itemAvailable消息。 每个订单中的项目数量可能差别很大，我们可以使用BPMN的多实例活动在我们的模型中对其进行说明。
错误处理
您可能需要在工作流程中设计某些“业务逻辑错误”。 在这里，我们不讨论服务因技术原因而失败的错误，而是由于我们可以提前计划的业务问题导致工作流无法进行的情况。 BPMN的错误边界事件是针对这种特殊情况而设计的。
在此示例中，我们尝试向客户的信用卡收费。 如果由于客户帐户中的资金不足而导致费用下降，我们会通知客户该问题。
我们可以继续......
谈到BPMN支持的模式，我们只是略微划清界限。 我们希望您能够了解仅使用这些BPMN符号可以表达多少个不同的用例。
我们在这些示例中展示的内容并不是说明性的，也不会告诉您应该如何使用BPMN。 相反，我们的目标是激发您对可以构建的模型类型的想象。
Zeebe的BPMN状态
希望您在这篇文章中了解BPMN在定义和执行复杂工作流程时的可能性。
但真正的问题是：我们在Zeebe中支持多少BPMN？
从长远来看，Zeebe将支持所有对工作流自动化有意义的符号，就像我们使用Camunda BPMN工作流引擎一样。
目前，Zeebe 0.11（最新版本）支持：
当然，这是一个有限的范围，到目前为止，我们主要关注Zeebe的引擎 - 即确保Zeebe具有处理高吞吐量用例的可扩展性和性能。
但是本季度我们一直在大力投资Zeebe的BPMN支持，我们将在不久的将来支持消息关联：
随着我们在2018年准备生产Zeebe，我们计划增加对更多符号的支持，例如：
- 计时器，
- 范围（子流程）和
- 并行执行
在2019年，我们将根据用户反馈以及我们对Zeebe将要解决的用例的了解来扩展符号支持。
我们处于BPMN系列第1部分的末尾。 我们在这篇文章中只提到了BPMN的一个非常重要的方面：模型可以用图形方式定义，然后由引擎直接执行。
因此，我们将很快回到第2部分，我们将在BPMN中了解图形模型的诸多优势，特别是与为业务流程用例构建的其他流语言相比时。 我们还将解决那些对图形模型有负面经验的开发人员的担忧。
如果您对此帖有任何问题或意见，我们很乐意听取您的意见。
讨论：请加入知识星球或者小红圈【首席架构师圈】