FaaS任务编排
在 Serverless 的领域中,通过某种方式来协调各个服务和函数的执行,使得我们在享受高弹性、低成本的同时,也降低业务处理上的复杂度呢?这种能力的确存在,业界普遍称之为“工作流(Serverless WorkFlow)”。
工作流,能够通过顺序、分支、并行的方式来协调一个或多个分布式任务,这些任务不仅包括函数、还可以是服务和应用的形式,并且通过平台提供的状态跟踪、日志记录和异常重试逻辑,使得你可以从繁琐的工作中解脱出来,享受全托管的服务能力。
基本构成
每个 State 状态是一个工作节点
它定义了一种特殊的逻辑,决定了工作流当前流程应该执行什么样的控制逻辑,通常包括:操作、传递、选择、并行、等待和循环等等。这些状态通过不同的组合形式,让业务模型的构建变得像平时编程一样简单,极大地丰富了工作流的实际应用场景。
工作节点可以关联服务
工作节点可以通过 API 完成对其他服务的调用。比如最常见的就是结合函数计算,每一个原子业务都会采用云函数实现,而业务之间的关联关系会通过工作流实现。一些厂商为了丰富 Serverless 工作流的应用场景,通常会和同一云生态下的其他云服务关联,比如阿里云的Serverless Workflow、腾讯云的ASW,就支持云服务 API 的集成。
每个节点有明确的输入和输出
每个节点都可以设定输入和输出来作为数据传递的手段,但在工作流中有两个比较特殊的规则:第一,当前节点为初始节点时,该节点的输入为工作流的初始输入;第二,当前节点不为初始节点时,该节点的输入为前一父节点的输出。
将工作流视为一组状态节点的集合以及这些状态节点的转换,每个状态节点都可以关联事件或功能,并且有明确的输入和输出。从解决方案的完整性来看,我们也需要额外地增加日志记录和审计来监视工作流的执行,也需要有安全的校验机制和错误异常处理能力。
架构设计
Serverless 工作流通常需要具备元信息管理、调度和执行三个核心服务的模块。
APIServer:负责元信息生命周期的管理,包括状态管理、模板、执行记录等信息;
调度服务:根据数据流请求,转发调度到对应的执行引擎,一般来说,它还需要具备负载均衡、限流、故障迁移等能力;
执行引擎:负责解析流程语言、执行流程,上报执行历史和调用其他云服务等。
在使用上,用户通过 APIServer 控制工作流的基本信息,然后通过请求调度模块执行工作流。
数据面的请求流向
请求到达调度模块后,调度模块首先会从 APIServer 获取当前工作流的定义内容和执行任务的元信息;
调度模块根据请求内容将元信息和请求内容分发到指定的执行引擎;
执行引擎会为本次执行生成一些元信息并记录到数据库,因为除了工作流本身的定义外,每一次执行都是无状态的,所以需要设置单独的任务 ID ,方便后续做一些请求重入的操作;
执行引擎根据流程定义语言语法,解析传入的工作流定义;
执行引擎根据解析出的状态有序执行,并根据状态语义调用其他服务进行处理。
最后,当所有 State 执行结束后,工作流执行引擎会根据最后的输出定义,返回结果。