技术架构解密 - 应用与服务编排工作流 ASW

Posted 2021-09-03 Serverless

<img src="https://main.qcloudimg.com/raw/f16dd23519567f4d48aa7c284cf37f62.jpg" />

腾讯云应用与服务编排工作流 ASW（Application Service Workflow）是新一代计算架构体系下的服务编排解决方案，用来协调分布式任务执行的编排产品。在应用与服务编排工作流中设定好任务执行步骤，可以将多个腾讯云服务按步骤进行调度，完成各种业务应用场景。能简化开发和运行业务流程所需要的任务协调、状态管理以及错误处理等繁琐工作，更简单、更高效的构建应用。 像胶水一样粘合云上各种产品和服务，提供面向用户场景的端到端解决方案。

01. 应用与服务编排工作流 ASW 背景介绍

<img src="https://main.qcloudimg.com/raw/19fee1dce4817561398ed6ef109bdf4b.jpg" />

随着云计算技术的发展和进步，函数即服务（FaaS）、无服务（Serverless）等新一代技术方案越来越多的成为用户上云的首选解决方案。无服务并不是指开发者没有服务，而是指开发者使用的来说，不用更多的去考虑服务器的相关内容，无需再去考虑服务器的规格大小、存储类型、网络带宽、自动扩缩容问题；同时，也无需再对服务器进行运维了，无需不断的打系统补丁、应用补丁、无需进行数据备份、软件配置等工作了。

Serverless 在开发便捷性、高性能、弹性扩缩容、部署便捷性、成本等方面具有天然的优势。用户从以前需要购买计算实例，部署应用程序代码的使用模式，逐渐转变为基于函数做面向最终业务的开发。腾讯云 Serverless 函数计算产品 - 云函数（Serverless Cloud Function，SCF），非常方便的提供面向单次请求或事物的处理能力；而云函数自身的运行、扩缩绒、部署等，均有 Serverless 服务提供商解决，对用于层面透明。随着 Serverless 架构应用的越来越多，越来越广，很多用户也逐渐将越来越多的业务以 Serverless 的方式进行部署。

此时，多个云函数和其他云服务之间的编排组合便成为了新的技术挑战。为了解决众多原子服务的串联和编排需求，ASW 应运而生。

ASW（Application Service Workflow）以工作流的形式，对包括云函数在内的云服务进行统一编排，支持顺序、并行、循环、失败重试、异常捕获、输入输出处理等功能，真正做到面向开发者的最终场景，从输入到输出，端到端提供解决方案。

举例来说，开发者想要实现一个视频字幕 OCR 的功能，在没有 ASW 的情况下，需要手工将视频帧采集、视频图像截取、图像保存、OCR 接口调用、结果保存等处理节点进行组合串联。这可能涉及到一系列的运维、扩容、监控、失败处理等逻辑的开发和组件对接，而使用 ASW 工作流，用户不需要考虑，只需要按照最终场景，使用 TCSL 语言编写工作流即可快速完成业务上线。

工作流提供 TCSL 语言（Tencent Cloud States Language），一种基于 Json 的结构化语言，用来描述和定义工作流中的业务逻辑。 该语言灵活方便，可写出可读性强、易于维护的状态机定义代码。语言兼容亚马逊 Step Functions 的 ASL 语法。提供任务节点（Task）、传递节点（Pass）、选择节点（Choice）、并行节点（Parallel）、循环节点（Map）。

02. 技术挑战解析

在设计并实现这样一个极为灵活的工作流系统时，需要考虑的问题很多；本部分将从数据量、可观测性、架构弹性等角度分析。

1. 工作流 ASW 产品是一个数据密集型产品。

用户串联的所有微服务，数据均需要经过 ASW 进行转发或传递。同时有大批量数据在 ASW 内部进行流转。此时，CPU 的负载并不是最高的，内存、网络等涉及大量数据 IO 的硬件，会首先是性能瓶颈。这也要求 ASW 产品在设计时，需要慎重的选择数据库中间件、存储中间件等。

按照设计要求，每天 100 亿次执行，对应着会产生 100 亿次执行记录数据；会产生远超 100 亿的执行历史记录数据。这些数据特点为写入数量远大于查询数量、顺序写入、需要做过期逻辑。

对于执行数据我们采取的解决方案是使用 Redis 来顺序写入执行数据，开发专门的清洁工程序，负责过期数据清理。后续可进一步改造，使用原生支持过期逻辑的数据中间件上。对于执行历史记录，ASW 使用 腾讯云日志服务 CLS 来存储海量执行记录。

2. 工作流产品需要提供足够的可观测性

工作流 ASW 是面向用户最终场景的解决方案，每一个工作流，都是用户的一个业务，工作流的抖动或不可用，会导致用户业务直接受损。因此，提供必要的可观测性是十分必须的。需要提供每秒启动执行次数、执行成功次数、执行失败次数、执行耗时等指标。这些数据，需要从 ASW 的执行代码中进行上报。虽然埋点并不困难，但是应对如此巨大的数据量，也同样是个不小的挑战。

对于可观测性要求，ASW 使用 腾讯云监控 CM。对执行过程中产生的指标数据进行收集整理。分别提供启动执行次数、执行成功次数、执行失败次数、执行耗时 4 个指标的监控、告警、Dashboard 可视化能力。

最后，考虑到随时可能到来的流量洪峰，需要系统整体有足够的弹性来应对。工作流产品，部署在公有云上，会有不可预期的流量洪峰到来，因此要求整体技术架构有足够好的横向拓展能力，以应对流量挑战。

弹性方面，ASW 使用 腾讯云容器服务 TKE，针对流量洪峰，配置 HPA 策略，使用 TKE 提供的监控来观测容器自身运行状态，同时，所有服务也都是基于容器进行部署的。

03. 应用与服务编排工作流 ASW 系统架构

<img src="https://main.qcloudimg.com/raw/ee03124490c7eaa24bf694ada0667196.jpg" />

ASW 整体架构包含如下部分：前端+SDK、权限服务、调度服务、模板服务、执行器以及为了支撑整体运行的外部底座设施和中间件。

各个模块各司其职，相互配合，在性能、可拓展性、成本间取得了很好的平衡。下面来分别简要介绍每一个模块的核心作用。

• 权限服务

主要功能包含两部分：

1. 对控制台来的用户进行鉴权，校验用户账户中，是否有ASW需要的角色等；
2. 状态机运行时，涉及到调用云上资源，则需要获取临时秘钥。

权限服务的第二个核心功能就是换票和票据缓存、过期、更新等逻辑。其中执行器调用权限服务的请求量，可达每天数十亿次。

• 模板服务

用于和控制台、SDK 进行交互，对模板数据进行增删改查管理。用户的创建、编辑状态机的请求，均由模板服务提供支持。该模块因为主要和用户侧交互，并发量并不会特别大。

• 调度服务

用户通过控制台或 SDK，发起执行（调用 StartExecution）接口时，经过腾讯云 API 转发后，流量会到达调度器，由调度器进行入参校验、TCSL 代码获取、负载均衡、生成 ExecutionQRN、写入执行数据等操作后，将请求发送给负载均衡模块选择出的某个执行器来实际运行一个状态机。因用户的核心逻辑均依赖启动执行功能，因此要求有足够的性能和弹性。其他功能还涉及到停止执行、获取执行状态、获取执行列表、执行器心跳检查等。

• 执行器

ASW 核心运行模块，只和调度器进行交互，提供启动执行、停止执行等 API。启动执行的过程包括 TCSL 语法校验、input 参数校验、TCSL 语法解析并创建有向无环图、状态机节点间输入输出处理、RPC 调用云服务等。并需要根据启动执行时的参数，将执行历史记录数据（每个 Node 的输入和输出）上报到外部数据中间件。因 ASW 项目和 腾讯云智天枢人工智能服务平台 TI Matrix 项目共用执行器，因此除云 SDK 外，还支持 K8s 相关的服务调用。

04. 架构演进方向

目前的架构可在大流量背景下，提供稳定、可观测、弹性的服务，但在如下几个方面依旧可以进一步优化。包括但不限于：资源隔离、私有化、成本降低等。

一张图快速读懂「腾讯云 ASW 工作流」

<img src="https://main.qcloudimg.com/raw/afd5ace5211ca216709aa14ba1d8e75f.png" />

识别下方