FaaS任务编排

在 Serverless 的领域中，通过某种方式来协调各个服务和函数的执行，使得我们在享受高弹性、低成本的同时，也降低业务处理上的复杂度呢？这种能力的确存在，业界普遍称之为“工作流（Serverless WorkFlow）”。

工作流，能够通过顺序、分支、并行的方式来协调一个或多个分布式任务，这些任务不仅包括函数、还可以是服务和应用的形式，并且通过平台提供的状态跟踪、日志记录和异常重试逻辑，使得你可以从繁琐的工作中解脱出来，享受全托管的服务能力。

基本构成

 

每个 State 状态是一个工作节点

它定义了一种特殊的逻辑，决定了工作流当前流程应该执行什么样的控制逻辑，通常包括：操作、传递、选择、并行、等待和循环等等。这些状态通过不同的组合形式，让业务模型的构建变得像平时编程一样简单，极大地丰富了工作流的实际应用场景。

工作节点可以关联服务

工作节点可以通过 API 完成对其他服务的调用。比如最常见的就是结合函数计算，每一个原子业务都会采用云函数实现，而业务之间的关联关系会通过工作流实现。一些厂商为了丰富 Serverless 工作流的应用场景，通常会和同一云生态下的其他云服务关联，比如阿里云的Serverless Workflow、腾讯云的ASW，就支持云服务 API 的集成。

每个节点有明确的输入和输出

每个节点都可以设定输入和输出来作为数据传递的手段，但在工作流中有两个比较特殊的规则：第一，当前节点为初始节点时，该节点的输入为工作流的初始输入；第二，当前节点不为初始节点时，该节点的输入为前一父节点的输出。

 

将工作流视为一组状态节点的集合以及这些状态节点的转换，每个状态节点都可以关联事件或功能，并且有明确的输入和输出。从解决方案的完整性来看，我们也需要额外地增加日志记录和审计来监视工作流的执行，也需要有安全的校验机制和错误异常处理能力。

架构设计

 

 

Serverless 工作流通常需要具备元信息管理、调度和执行三个核心服务的模块。

APIServer：负责元信息生命周期的管理，包括状态管理、模板、执行记录等信息；

调度服务：根据数据流请求，转发调度到对应的执行引擎，一般来说，它还需要具备负载均衡、限流、故障迁移等能力；

执行引擎：负责解析流程语言、执行流程，上报执行历史和调用其他云服务等。

在使用上，用户通过 APIServer 控制工作流的基本信息，然后通过请求调度模块执行工作流。

数据面的请求流向

请求到达调度模块后，调度模块首先会从 APIServer 获取当前工作流的定义内容和执行任务的元信息；

调度模块根据请求内容将元信息和请求内容分发到指定的执行引擎；

执行引擎会为本次执行生成一些元信息并记录到数据库，因为除了工作流本身的定义外，每一次执行都是无状态的，所以需要设置单独的任务 ID ，方便后续做一些请求重入的操作；

执行引擎根据流程定义语言语法，解析传入的工作流定义；

执行引擎根据解析出的状态有序执行，并根据状态语义调用其他服务进行处理。

最后，当所有 State 执行结束后，工作流执行引擎会根据最后的输出定义，返回结果。