腾讯开发工程师写万字长文：读懂微服务编排利器Zeebe，超详细

1.工作流与微服务编排

1.1工作流

提到工作流，印象里都是OA系统各种请假审批流。事实上，广义上的工作流是对工作流程及其各操作步骤之间业务规则的抽象、概括、描述。简单理解，我们为了实现某个业务目标，抽象拆解出来的一系列步骤及这些步骤之间的协作关系，就是工作流。例如订单发货流、程序构建流等。业界通常用BPMN流程图来描述一个工作流。

1.1.1没有工作流时的任务协作

以实现一个用户购买逻辑为例，如果不应用工作流模型，我们串联多个任务(步骤)一般是通过显示的代码调用：

校验、支付、发货一气呵成，流畅自然。正喝着枸杞红枣，产品一脸笑意跑过来：“我们新搞个充会员卡的业务，大概步骤就校验 -> 推荐 -> 支付 -> 充值。校验和支付前面都做过了，应该很快实现吧？”

精通if-else的你，听完的瞬间就已经构思好了代码：

一通写下来，总感觉哪里不对，“为什么加新的任务节点，要改已有的代码呢？这不符合开闭原则啊！”。

1.1.2应用工作流模型的任务协作

工作流模型正是为了解决这类问题而生：分离任务的实现和任务的协作关系。上面同样的用户购物逻辑，有了工作流模型，各个任务只实现自己原子的逻辑，任务协作关系使用流程图来表达。

当新的逻辑需要复用已有任务节点时，只需要要调整流程图，无需修改已有代码。

1.2工作流引擎

将任务实现与任务协作关系分离之后，就诞生了专门维护任务协作关系的程序 - 工作流引擎(也常称作流程引擎)。

其中最具有代表性的就非Activiti莫属了。在企业应用蓬勃发展的21世纪初，它几乎是实现流程自动化的标配。关于Activiti的介绍，网上已经有足够多的文章。今天我们要介绍是由Activiti的核心成员打造的另一款专为微服务编排而生的工作流引擎 - Zeebe。在开始之前，我们先理解下什么是微服务编排。

1.3微服务编排

微服务架构的一大核心是把大的复杂的业务系统拆分成高内聚的微服务，每个服务负责相对独立的逻辑。例如一个电商系统，可能会拆分出支付微服务、订单微服务、仓储微服务、物流微服务等。服务拆分的好处无需赘述，但是要实现业务价值，不是看单个服务的能力，而是要协调所有服务保证企业端到端业务流的成功。那么，哪个服务来负责端到端业务流的成功呢？答案是没有。事实上，在公司内，端到端的业务流可能都没有正式的文档说明，从一个微服务到另一个微服务的事件流转都是在代码里隐式表达的。

很多微服务架构依赖一种相对纯粹的编舞模式(choreography pattern)来解决这个问题。在这种模式下，微服务通过向一个消息队列发送和接收事件来相互协作。编舞模式给开发者提供了很高的灵活度，但是编舞模式仍不能解决：

• 可见性：多少端到端业务流正在运行中，它们的状态是什么样子。过去24小时，有多少业务流实例没有成功结束？为什么这些业务流实例没有成功结束？一个业务流或者某个任务完成的平均时间是多少？
• 异常处理：如果业务流里有一个微服务失败，谁负责处理这个异常？业务流的重试逻辑是怎么样的？如果需要人工介入，问题的升级处理规则是怎么样的？ 于是便诞生了一种更严格的编排模式(orchestration pattern)，用于协调各个微服务。在这种模式下，会有一个中控的引擎：
• 按照业务逻辑的蓝图，编排各个微服务的调用关系；
• 监控整个业务流的状态；
• 提供自动化的机制处理单个服务的失败，保证整个业务流的成功。 可以借用下面的图，来进一步理解微服务编排和微服务编舞模式的区别：
  
  按照我们前面对工作流模型的阐述，工作流引擎很适合作为中控引擎，来编排调度微服务。那为什么诸如Activiti等传统的工作流引擎没能继续占领微服务编排的市场，而是诞生了新的微服务编排引擎-Zeebe？更有趣的是，Zeebe的核心开发，也是来自最初的Activiti团队。

答案是诸如Activiti等传统工作流引擎的架构无法适应当下微服务的场景：