云原生时代的业务流程编排

既然今天要聊一聊云原生时代的业务流程编排，那咱们首先得定义什么是流程编排以及传统的流程编排是做什么的。传统的流程编排一般分两类：bussiness process management（BPM 业务流程管理）和 workflow engine (工作流引擎)，在过去十几年里，商业领域主要是以BPM为主，软件服务厂商以平台化的产品为企业客户提供流程设计、流程管理、流程自动化相关的能力。

BPM可以及时响应企业的组织架构、业务交互及运营模式的灵活多变，并且可以满足企业内部、企业与伙伴之间的业务交互需求。这一块的产品基本上都是厂商锁定的，寄希望于业务人员（非技术专业人士）以零代码托拉拽的方式来设计业务流程，虽然有一个开放的规范叫BPMN，但是这个规范本身就挺复杂，导致产品使用门槛也不低。除了企业级的，还有一些开源BPM项目，比较有名的几个（按时间先后顺序）：jBPM、Activiti、flowable、Camunda。本文重点不是BPM（其实我看到BPMN就头大，因此兴趣也不在这一块），不必多言。

Workflow engine(工作流引擎) 相比BPM而言通常更轻量，其核心专注于状态机、任务调度、定时器管理、事件处理。工作流引擎是面向专业开发人员的，有代码编排和DSL编排两种方式，也有个别的DSL直接采纳BPMN，轻量也常常意味着很多BPM软件具备的复杂功能在工作流引擎中是缺失的，优势是引擎各有千秋，轻量灵活性让开发人员能够根据业务场景选择特定的流程引擎来解决特定的问题，我们并不需要为审批流程和微服务编排选择同一款引擎。开源界做的不错的已经有很多了，有兴趣可以看看这个链接：棒棒哒的开源工作流引擎。在这些开源项目中，Netflix Conductor和Uber Cadence的实现代码我有深入研究，并且两个都在生产项目中应用过。Conductor的核心代码与它自己的DSL是紧耦合的，扩展能力差，在Netflix内部的应用场景也很小。这个开源列表中个人觉得设计优秀功能强大的当属Cadence，当然它的作者也坚持这么认为，以至于一直想摆脱workflow或者orchestrator这些看起来比较老套的名词术语，目前它的定位是Fault-Oblivious Stateful Code Platform，不知道怎么翻译才合适，还是意会把。

Cadence作为一个engine，将core的部分高度抽象，覆盖流程编排所需要的几乎所有原子能力，将构建和编排流程的具体工作交由开发者自己去用代码定制，设计更优秀，功能更强大，适用业务场景也非常多。据说Cadence作者早年是在AWS干SWF(amazon simpe workflow service)的，SWF是AWS与2012年发布的工作流服务。后来SWF的tech lead去了Uber，在Uber把工作流引擎发扬光大，由专门的引擎团队负责用Go语言打造Cadence平台，多个业务部门基于Cadence平台开发出支撑几十个业务的流程编排服务，也有一些业务部门根据自身业务特点定义特定的DSL和流程设计器，以更灵活的配置化方式来管理业务流程。该团队对cadence的应用场景列了一个不完全清单：

• 周期性/定时执行的业务流程（分布式Cron）
• 微服务编排和SAGA模式
• 轮询服务状态
• 事件驱动的应用
• 批处理任务
• 基础平台管理
• CI/CD和运维管理
• 交互式应用
• DSL工作流
• 大数据和机器学习控制面

以上列表中的用例当然也可以用工作流引擎之外的各种方式来实现，但不可忽视cadence的主要贡献在于：有效降低了开发分布式架构中有状态（stateful）且对容错（fault-tolerant）有较高要求业务的门槛。这对关键业务系统的开发效率、质量、鲁棒性带来极大提升，随着业务流程越复杂多变、涉及的分布式服务越多，效果就越显著。本人有基于cadence实现DSL做微服务编排的经历（包含设计器和运行时），开发过程中体验不错，实现出来的效果也挺好，DSL的设计借鉴参考AWS States Language的规范。Cadence也不是没有缺点，譬如，比较棘手的一个问题：DSL中实现的状态和Cadence自身的event（Cadence使用event记录调度决策和任务执行的每个状态转换）不能产生关联，event id对开发者是不可见的，这可能是设计上有意为之，因为Cadence作者对DSL没有好感，支持用代码直接编排业务流程。如果开发者希望将DSL中的state/step和Cadence event做映射以方便调试或理解内部运行的逻辑，则需要修改Cadence核心代码，第一，方面不利于维护；第二，Cadence的主要服务组件设计文档缺乏、代码也很绕，要修改并非易事，核心功能的扩展成本比较高。另一个缺点，性能堪忧，单机每秒创建一百多个流程实例，这不是Cadence独有的问题（瓶颈在状态持久化），即便是商业的fault-tolerant stateful流程编排在性能上差别也不大，考虑到Cadence的架构设计有不错的水平扩展能力，用堆机器的手段仍然可以应付很多业务场景的需求，我估计Uber内部用来运行Cadence集群的服务器数量一定不少 ^_^

前面介绍了工作流引擎/流程编排的概念和相关优秀开源项目，然后再来简单介绍一下云原生技术(Cloud Native)。尽管云原生应用的概念在过去一两年非常火热，然而，即便是业内人士也常常无法很清楚的描述它的含义，或是每个人的理解不同，或是人云亦云。云原生的定义也许会在接下来的一年或更长时期发生变化，但其本质是关于效率和敏捷性的，是应对业务快速变化、大规模和弹性的架构方式，是以业务为核心以云为基础的应用开发模式。CNCF官方对这个术语的定义：云原生技术使组织能够在现代动态环境（例如公共云，私有云和混合云）中构建和运行可扩展应用程序。这些技术使松散耦合的系统具有弹性，可管理性和可观察性。结合强大的自动化功能，使工程师能够频繁且可预测地以最小的工作量进行高影响力的更改。

云原生技术以云基础架构为基础，并包含其他几个重要的技术或支撑架构：微服务，无服务器计算/云函数、容器、PaaS平台、支撑服务（托管的数据库、消息队列、缓存等服务）、流程自动化。这些技术的采用使得现代应用开发具备以下特点：应用由分布式的服务组成，业务敏捷迭代，快速部署和扩展，更强的容错能力，全面的监控，以及高度弹性的基础架构以适应任意类型的业务规模。以上所有的最终目标：让企业和应用开发人员专注于核心业务，加快业务开发上线周期和业务创新速度。

云原生应用的设计通常会采用微服务架构。其思路不是开发一个大的单体式应用，而是将应用分解为小的、互相连接的微服务，一个微服务完成某个特定功能。这个架构在大多数情况下都可以正常工作，但是分布式系统的特点决定了当它们出现故障时，它们会以各种不可预测的方式发生故障。在现实中，微服务的许多新采用者经常会选择性的忽略这种复杂性。

 

采用同步通信的微服务架构

尽管可以通过断路器和服务降级等微服务治理方式来减轻服务间通信的级联失败，但更好的解决方案是将同步调用转变为基于消息队列的异步方式。如果一个服务出故障，事件将在队列中累积。当服务恢复正常，它会开始处理积压的事件，系统会更具弹性。基于服务之间发送事件的应用架构称为事件驱动，当服务执行一个操作时，它会发布一个事件，记录其业务领域发生的事实的记录，另一个或多个服务侦听和处理已发布的事件。

 

事件驱动的应用架构

事件驱动能增强系统弹性，看起来也能让系统更好的解耦，更加健壮。但是更上层的业务逻辑在事件架构中已经很难被直观的表达出来。为了洞察业务流程，需要构造复杂的业务监控方案还原出流程的真实面目，。这个架构一般要求微服务同时依赖数据库、消息队列、日志系统来记录和管理业务状态，协调业务流程。而且，服务与具体事件的耦合实际上等于把流程硬编码到每个独立的微服务，业务编排顺序的小小变动就可能造成对多个微服务的修改，微服务的自治/独立特性被破坏，微服务之间的耦合性从本质上看并没有被降低。

即使采用事件驱动架构，单个微服务对出错情况的常见处理机制仍然会引入复杂的状态，例如：1. 重新消费事件，指数退避重试; 2.死信队列； 3. 补偿操作，取消整个过程或者降级处理。以上几个例子均要求微服务引入额外状态管理和复杂性，让开发者实现无状态服务和封装领域业务上下文的目标更难达成。而且在多个独立的无状态服务之间来实现错误管理并非易事，也不直观。

对开发者而言，缺失的也许是一个“协调者”的角色，即有状态的业务流程编排器(business process orchestrator)。本文前面重点讲述的工作流引擎就是这个编排器，在云原生时代，业务流程编排和传统工作流既有很多相通之处，在出发点上又有本质不同，传统工作流是想把业务流程化，而云原生业务流程编排目的是解决微服务或者云函数应用大量无状态服务组合成有状态业务所面临的挑战，还有一些主要是解决分布式应用系统之间的集成问题。典型的业务流程编排器架构如下图：

 

业务流程编排器架构

业务流程编排器的主要任务是将工作委派给无状态的服务，同时又要保持业务流程执行的上下文和历史记录。其工作原理并不复杂，通常是由一个编排客户端程序(orchestration client)启动编排器程序(orchestration worker)运行指定的业务流程，以按照一定步骤执行一系列活动。orchestration worker在执行到活动(通常对应activity worker对微服务或云函数的调用)、计时器、外部事件相关的代码时，自动发送命令到消息队列并记录下当前的执行记录到历史事件存储，当系统出现故障时，通过事件溯源(event sourcing)模式自动恢复业务流程函数的上下文并继续执行未完成的流程。现代公有云托管业务流程编排服务可以有效简化分布式应用开发中的出错处理、弹性扩缩容、流程全生命周期监控，并且通过业务状态自动持久化提供了高容错性和扩展性的关键业务开发模式。开发者可以用精简和直观的代码灵活的组合云函数、微服务、分布式组件，以最小开发代价实现复杂业务应用。较常见的业务流程编排模式如下图：

 

业务流程编排应用模式

目前有多个公有云厂商提供这种托管的编排器服务，作为云函数和其他云服务的配套设施，或者主打企业应用集成。接下面会介绍亚马逊的SWF和step functions、微软云Azure durable function与Logic Apps、华为云functionGraph。这些公有云厂商提供的编排服务是对云原生技术栈的重要补充，也是无服务器计算(serverless)的重要组成部分。

以下介绍内容主要参考相关产品官方文档：

Amazon Step Functions

AWS Step Functions 是一项完全托管服务，使您能够轻松地使用可视化工作流来协调分布式应用程序和微服务的组件。Step Functions 提供图形控制台，以按照一系列步骤安排应用程序的组件并实现其可视化。这可以简化多步骤应用程序的构建和运行。Step Functions 可以自动触发和跟踪各个步骤，并在出现错误时重试，因此您的应用程序能够按照预期顺序执行。Step Functions 可记录每个步骤的状态，因此在出现错误时，您能够迅速诊断并调试问题。您甚至无需编写代码就可以更改和添加步骤，因此可以轻松地完善您的应用程序，并加快创新步伐。

通过使用 AWS Step Functions，您可以将描述工作流的状态机定义为一系列步骤及其关系和输入输出。状态机包含许多状态，每个状态代表工作流图中的一个步骤。状态可以执行工作、做出选择、传递参数、发起并行执行、管理超时，或终止成功或失败的工作流。可视化控制台能够自动按执行任务的顺序用图表显示每种状态，从而使您能够轻松地设计多步骤应用程序。控制台会突出显示每个步骤的实时状态，并提供每次执行的详细历史记录。

 

Step Functions控制台示例

Amazon SWF（简单工作流服务）

Amazon Simple Workflow Service (SWF) 是能够轻松协调各分布式应用程序组件中任务的服务。Amazon SWF 能够以协调任务的方式来设计适用于各种使用案例的应用程序，包括媒体处理、Web 应用程序后端、业务处理工作流及分析管道。

任务协调包括根据应用程序的逻辑流管理执行任务的依赖性、调度及并发性。使用 Amazon SWF，开发人员可全面控制流程步骤 及协调各步骤的任务，而不用担心跟踪进度和保存状态等底层复杂的工作。任务由工作程序(worker)来处理，即与 Amazon SWF 交互以获取任务、处理任务并返回任务结果的程序。

 

SWF示例：视频编码应用

使用分布式组件构建应用程序时，可使用 Amazon SWF 解决出现的多项挑战：

• 使用简单的编程结构以异步程序形式编写应用程序。
• 自动保存应用程序的执行状态（例如，已完成哪些步骤、正在运行哪些步骤等）。不必非要使用数据库，定制系统或专用解决方案来保存执行状态。
• 各应用程序组件之间的通信。使用 Amazon SWF，无需设计消息发送协议，也不必担心任务丢失和重复。
• 集中协调应用程序中的步骤。协调逻辑不必分布于不同的组件，可以封装在单一程序中。
• 将各种程序和组件集成到应用中，包括旧式系统和第三方云服务。通过允许应用程序在任何位置、以任何组合形式灵活部署应用程序组件，Amazon SWF 方便逐步将应用程序组件从私有数据中心迁移到公共云基础设施，而不会中断应用程序可用性。
• 自动执行工作流，包括长时间运行的人工任务（例如，批准、审核等） Amazon SWF 能够可靠地跟踪运行长达数天或数月的处理步骤的状态。
• 详细审查跟踪应用程序运行的所有实例。

Azure Durable Functions（持久函数）

Durable Functions是微软云函数的一个扩展服务，可用于在无服务器计算环境中编写有状态函数（业务流程编排函数）。Durable Functions 的主要用例是简化无服务器应用程序中出现的复杂的有状态协调要求，使你可以专注于业务逻辑。业务流程编排函数（Ochestration Function）在代码中描述业务流程：执行什么操作以及执行操作的顺序。

• 活动函数（Activity Function）是持久函数业务流程中的基本工作单位。 活动函数是在过程中协调的函数和任务。 例如，可以创建一个业务流程编排函数来处理订单。 这些任务包括检查库存、向客户收费以及创建装运。 每个任务都是一个单独的活动函数。 这些活动函数可以并行执行，也可以同时执行这两种函数。
• 业务流程可以有许多不同类型的操作，包括：活动函数、子业务流程、等待外部事件、计时器等。
• 与业务流程编排函数不同，活动函数并不限制在其中执行的工作类型。 活动函数经常用于进行网络调用或运行 CPU 密集型操作，活动函数还可以将数据返回到业务流程编排函数。

 

Durable Function示例

Azure Logic Apps （逻辑应用）

利用 Azure Logic Apps 可视化流程设计器连接业务关键应用程序和服务，从而实现工作流自动化，而无需编写任何代码。通过大型SaaS生态系统（包括 Salesforce、Office 365、Twitter、Dropbox、Google 服务等）和基于云的连接器，可连接任意位置（本地或云端）的应用、数据和设备。逻辑应用可以：

• 直观地创建业务进程和工作流
• 与 SaaS 和企业应用程序集成
• 释放本地和云应用程序的价值
• 自动化 EAI、B2B/EDI 和业务流程
• 利用 Microsoft 云增强集成解决方案

 

Azure逻辑应用连接器

华为云函数工作流（FunctionGraph）

函数工作流（FunctionGraph）是华为云提供的一款无服务器（Serverless）计算服务。华为无服务器计算包含函数和工作流两个功能模块，分别实现函数计算和函数编排的功能。

工作流提供图形化控制台，能够借助可视化工作流编排分布式应用程序的组件。可以使用简单的命令来定义应用程序的每个步骤，会自动将步骤生成图形形式的工作流。启动应用程序后，将以图形展示程序每步的执行情况，可以快速确认每个步骤是否都按照预期的顺序执行。控制台也会显示错误信息，帮助用户快速查明原因、排除故障。

工作流支持跟踪每个步骤的状态，借助内置的重试和回退功能，无差别的自动处理错误。使用工作流可以自动重试失败或超时的任务、捕获特定错误并正常恢复，当所有操作都失败时，可以回退到指定的代码。

文章来源：https://cloud.tencent.com/developer/article/1588668