云音乐服务端可视化编排平台 TangoFlow 设计与实现

本文作者：[帝青]

在实际业务需求背景下，TangoFlow 寻求构建组装式架构，整合云音乐服务端技术栈，提供基础逻辑编排功能，以某种方式（网关API、统一SDK等）暴露编排结果；从长远来看，作为研发全链路低代码化中的一环，构建符合云音乐现状及长远愿景的服务端低代码平台；今天我们一起来聊下TangoFlow 的产生背景以及平台化建设实践；

背景及诉求

1、BFF场景下灵活编排诉求

目前云音乐的前后端协作基于Restful API进行交互，服务端在Controller层通过来自RPC的原子接口数据，组装出前端视图需要的数据并返回给前端，所以会存在客户端相关接口的契约定义对服务端有深度依赖，导致在协作上存在大量的沟通成本以及排期依赖，同时由于客户端UI的多变性，导致服务端面向客户端接口复用性较差，大前端同学苦恼于难以得到自己想要的数据，而服务端同学基于自己并不熟悉的视图拼接模型数据时也感到异常痛苦。

BFF 研发模式一直是业界广泛青睐的前后端协作模式，它能有效解耦前后端在协作上的依赖关系，从而大幅度提升研发效率，目前云音乐内部已经完成基于GraphQL的BFF的研发模式提供，这种研发模式在云音乐内部有较为广泛的落地，在2022年完成了基于GraphQL的BFF应用建设解决上述问题， 目前已在较多团队中推广使用，但随着使用会存在以下问题：

受限于GraphQL引擎，编排能力不足：GraphQL是一种用于API的查询语言。可以将GraphQL看作一种新的API标准，它提供了一种高效、灵活的数据提供方式，但基于GraphQL引擎存在一些限制，在较为复杂的逻辑处理上无法进行灵活的编排，在组装RPC服务时，会存在很多个性化需求，目前是通过groovy脚本输入做输出做重新的组装，脚本内部存在大量业务逻辑，导致groovy脚本滥用；
降低资源开销：当前BFF应用采用的是一个febase应用对应一个BFF后端引擎服务集群，目前测试、预发、线上都会创建对应的引擎服务集群，但基本无流量，且线上流量也都比较低，所以会存在大量的资源浪费；
BFF引擎服务集群存在运维分工不清晰现象，缺乏机制保障，目前前端同学负责对BFF API接口搭建、自测、完成接口交付，但对于引擎服务集群稳定性、容量水位缺少评估经验，同时服务稳定性偏后置，在稳定性和容量水位服务端同学做的会更多一些，会更有经验；

2、业务上的编排诉求

寻求业务架构可编排能力，基于现有业务沉淀服务资产，灵活快速高效编排出符合业务需求的流程，并以触发器（网关API服务、RPC服务、本地资源... ...）的形式暴露流程服务；
活动场景编排提效：在活动场景下， 玩法中台之前产出了轻量级流程编排组件（在产品调研中有提及：《轻量级流程编排组件介绍》），由于接入比较较为复杂，平台使用体验一般，导致推广不是很广泛，对于玩法中台场景存在较多可沉淀的场景，能够通过复用已有资产组装完成新的业务场景；

3、标准化推进落地困难

规范落地难： 目前云音乐存在诸多规范，但在真正落地效果上并不是很好；
调试测试效率低： 目前在网易PostMan在公司是禁用的，所以现在大家都在GoTest上使用，使用起来会比较重，且会存在跨平台/工具的操作，使用体验、效率比较低，测试代码运行大多需要启动整个应用，而应用的启动通常都是分钟级的，这就导致我们研发效率进一步降低。
服务治理能力弱： 代码本质上是非结构化的文本数据，我们很难基于代码进行统计，此时接口和服务、工具间的依赖关系就显得尤为重要，但基于编码的方式我们是很难做到精准统计，虽然有一些调用链追踪工具可以提供帮助，但还是不够直接，还是需要人肉的去做进一步的识别；服务治理能力（限流、降级、静态化、Redis治理... ...)仍然较为分散，应用维度治理能力仍然需要跨平台操作，易用性、开发者体验仍需提升；
降低资源开销： 一方面是BFF自身的资源开销问题，另一方面，现在微服务比较多且占用资源不一，如何将微服务合并为一个微服务，进一步降低成本

4、全链路低代码建设

对于一个完整的 web 应用来讲，会经过用户界面-接口服务-数据服务等多个模块，目前云音乐已完成了前端低代码的建设，已经大大提升了UI层的交付效率，接下来会在整个链路上进行尝试，对于服务端的逻辑编排、服务编排以及更长远的基于模型编排驱动方式，是我们重点关注的对象，期望能够从全链路上降低开发成本、提升交付效率和质量；

所以基于上述背景，我们规划、设计流程编排平台，对于BFF应用，主要是解决编排的问题，同时支持更复杂的编排场景，服务编排出来的产物可以是RPC、API服务，编排出来的RPC、API服务直接集成在BFF中，灵活解决BFF应用的服务编排问题，同时从机制上解决引擎服务集群稳定性的问题，支持paas服务的管理方式，降低服务成本，同时在平台建设过程中，注重对资产的沉淀、平台研发易用性和使用效率；从长远来看，在整个研发全链路上进行低代码尝试，对于服务端的逻辑编排、服务编排以及更长远的基于模型编排驱动方式提供基础演进路线，能够更进一步实现技术中心全栈化，提升交付效率，降低交付成本；

流程编排思路

构建编排一个完整流程，主要是能够将可被编排资源以顺序、分支、循环、并行等的流程串联，可以被编排的资源主要可以分为两类，一类是业务域服务，一类是工具域服务，通过对对业务域服务、工具域服务的组装、编排，可以灵活构建一套符合业务需求的服务工作流；

下面针对业务域和工具域简单介绍下：

1、业务域：主要是指当前云音乐的不同业务领域的服务能力聚合，通过对RPC、HTTP、FaaS等的服务沉淀，在业务领域模型比较稳定的情况下，沉淀出不同的业务域模型，比如评论域、活动域、用户域等，平时的业务需求主要来自上层聚合层，则是对领域模型中沉淀出来的服务能力的服务编排，此时便可以通过服务编排的方式提供更为灵活的聚合类服务；当前的业务领域沉淀比较弱，期望能以Tango Flow项目为契机沉淀业务领域资产；

2、工具域：主要是针对工具的分类聚合，这里主要抽象为了一下三种类型：

中间件域：可以提供发送或消费消息队列，数据可以增删改查Redis服务，比如更多的分布式锁，分布式计数、指标监控等都会在中间件域中沉淀出来，便于搭建上层业务场景；
AI工具域：当前云音乐正在沉淀相关能力，后续提供出来的一些能力，比如文本分类、知识问答等，则可以工具的形式在Tango Flow平台提供，从而可以灵活搭建更上层的业务场景；
平台服务域：目前云音乐的一些能力都是相对比较单点的，比如当前有告警能力、数据监控、简单数据分析、以及流量治理能力，那按照发现问题、分析问题、解决问题的思路，是不是可以将这些能力串起来，比如将发出来的告警经过简单分析，去获取数据监控，在交给数据分析模块进行分析，分析发现是某种问题，可以通过限流来临时止血，进而整个流程可以自动化掉；

当前的工具领域沉淀比较弱且很分散，期望能以Tango Flow项目为契机沉淀工具域资产；整个逻辑编排是对业务域和工具域资产的编排，具体表现如下图：

产品架构

1、逻辑编排态： Tango Flow平台整合现有OX资产（业务侧的RPC接口、HTTP接口）及规范信息，用户可以在该平台完成流程的搭建、测试、发布动作；

2、逻辑运行态： 流量从APP端达到网关、BFF、业务服务，那Flow Engine可以完全嵌入到这三层，比如现阶段直接取代BFF能力，通过逻辑编排出来网关API；

产品介绍

产品优势

下面针对个别特点进行简单介绍，部分会在产品使用及应用场景章节介绍：

1、自研编排引擎

TangoFlow自研逻辑编排引擎，编排引擎是静态流程的Runtime载体；同时也是一个逻辑概念，和使用姿势有关系，可以服务的形式承接网关流量，也可以以SDK的方式集成在业务应用中，自研编排引擎具有以下特点：

2、自研DSL协议

DSL分为元信息定义和逻辑流程定义，元信息定义会受流程内容影响而有很大不同，在下面这个例子中，元信息定义包括Trigger定义、RPC节点定义、Groovy脚本定义，更接近编程语言，后期借助AI Native prompt提升效率；

3、集群托管机制

托管集群是真正的运行TangoFlow 流程的服务，在运行TangoFlow的流程时，需要首先指定运行在哪个托管集群上，从开发 -> 回归 -> 预发 -> 线上，每个都需要制定运行的托管集群；

1、引擎多租户，降低资源开销

托管集群服务时支持多租户的，可以将不同应用指定到同一个托管集群上，一方面降低运维成本，另一方面也能够减低机器成本，在服务达到容量瓶颈时可以对托管集群进行扩容，或重新新建托管集群承载新的服务；

2、每个业务线或领域，都有一个“积木”系统

托管集群的维护尽量按照业务线或业务领域规划，对于BFF场景，线下和预发可以用公共的环境，对于线上服务由于流量较大，需要单独申请托管集群承载运行时流程；

3、建立统一运维协作机制

由于角色的不同，可角色分为两大类：托管集群负责人，开发角色，同时为了集群的稳定性，会涉及到审批和通知，便于集群负责人对容量和稳定性进行把控，所以需要应用关联到托管集群和流程发布时通知到托管集群负责人、或需要托管集群做审核，简单示意图如下：

托管集群负责人角色：一般为服务端开发
负责感知、审核应用关联集群、流程发布
特点：对稳定性、容量敏感，对引擎服务集群容量、稳定性负责
开发角色: 前端、客户端、服务端
负责流程搭建、测试、交付
特点：可能对服务容量、稳定性不敏感

4、环境隔离

由于线下环境的特殊性（环境隔离），云音乐有一套自己的环境隔离策略，TangoFlow能够通过API网关负责API路由托管集群负责环境路的方案解决环境隔离问题；

1、环境路由规则： 优先同标识环境服务路由；未找到同环境，则回归环境服务兜底

2、传统环境隔离： 网关负责API路由、环境路由；需部署相应环境业务集群服务

3、Tango Flow环境隔离： 网关负责API路由；Tango Flow引擎负责环境路由

产品使用

整体流程主要包括四个部分：编排搭建 -> 自测、调试 -> 发布流程 -> 运维，如下图所示

下面针对针流程编排中关键步骤进行简单介绍：

1、流程中概念

一个完整的流程包括Trigger +逻辑控制 + 数据来源 + 数据整合，下面对这几个概念进行简单介绍：

1、Trigger：流程编排后以何种方式暴露，流量以不同的方式调用到流程，比如可以以网关API、服务端SDK、事件消息、定时任务等方式，目前一期已支持网关API和业务服务接入SDK的方式完成流程的触发；

2、逻辑控制：用于控制流程逻辑流向，目前支持串行调用，并行调用、IF-Else、Switch、For迭代器（List、Map）的方式，能够支持绝大部分业务场景，对于一些逻辑比较复杂的场景可以通过Groovy脚本来完成；

3、数据来源：产生数据的源头，目前已支持云音乐RPC、网关HTTP接口、Groovy脚本、本地接口调用、固定值，这些都可以产生数据，被流程拿来进行编排，产生的数据可以在流程上进行流转；

4、数据整合：作为整个流程返回的结果，可以自由组装数据来源产生的数据，同时支持JsonPath的取数方式；

2、逻辑编排可视化

流程编排页面是TangoFlow最核心的页面，从区域上划分为组件区域、逻辑编排区域、属性面板，在调试情况下会弹出调试区域，同时支持分支切换、历史版本、视图切换（支持设计和DSL的切换）、流程快速发布等能力。

3、参数选择

在需要上游某个节点的返回结果作为当前流程节点的输入，在TangoFlow平台中所有的参数选择都是基于组件标识来识别的，可以选择将整个结果作为当前的输入，也可以通过 jsonPath来选择具体的某个值作为输入；

举个具体的例子：定义在触发器中gw\_http0中的一个参数userId，可以在下游RPC调用中被选择作为RPC的入参，另外也可以在结果集整合的时候作为结果被使用，在下面这个case中，是通过节点标识取到的该节点返回之中的data.rowkey信息作为返回结果的一部分；

4、流程调试

支持整个流程的调试、节点维度调试（RPC、HTTP、Groovy脚本）的调试能力，并且无需发布，可指定环境、直接测试、调试记录；

1、流程调试： 针对整个流程的测试，Trigger开始触发

2、节点调试： 单个RPC、HTTP-IN、Groovy脚本调试

3、可视化调试记录： 入参、结果、调试记录栈、运行DSL

5、Mock机制

测试过程中，对于不容易构造或者不容易获取的对象，用一个虚拟的对象来代替以便测试的测试方法，只用于线下环境快速联调，在团队并行开发能极大提高效率；

Tango Flow支持Request Mock和Response Mock，Mock数据来自于统一资产平台（OX），数据可以在Tango Flow平台按需进行调整；同时在编排时若某个节点打开了Mock可在编排视图中会有特殊标记提示流程节点开启了Mock；

1、Request Mock

支持 RPC、HTTP、Groovy ，用于服务已就绪，Request Mock 数据作为请求数据，忽略上游传入数据的场景；

2、Response Mock

支持Trigger、 RPC、HTTP、Groovy ，用于下游服务接口未就绪、服务不存在等导致无法构建或获取对象场景

6、流程持续发布

发布流水线全生命周期管理，秒级完成发布，卡点环节使发布可靠、低风险、随时按需执行，流程发布具有以下特点：

1、多分支并行开发： 可多分支并行开发，一个发布单对应一个分支，新建发布单从master分之拉取数据，发布完成后覆盖master；

2、发布策略： 线下环境发布策略：开发、回归随意发布，回归环境只有一个，互相覆盖；线上环境发布策略：预发、线上通道独占，互斥发布；

3、回滚策略：回滚发布以新发布单形式存在，与其他共用发布单共享发布通道，回滚但不能合并到Master；

4、发布卡点：托管集群具有可配置的流程发布卡点机制，在开启发布审核时，在卡点环节会提示需要托管集群负责人审核才能进行预发和线上环境发布，保证发布的安全性，后续也会持续优化发布卡点逻辑。

以下为一个具体case，由于公共预发集群和线上集群都设置了开启审核，所以需要集群负责人审核通过后才能继续发布

7、监控告警

不同维度数据，不同负责人关注信息不一样，根据访问分布、RT访问分布，并在流程维度有RT和调用错误率的告警；

应用场景

一期流程编排暴露出来的能力是网关API和API-SDK，同时支持的数据节点主要是RPC接口、HTTP接口、本地接口调用、Groovy脚本，所以一期主要适用场景在：协议转换、数据聚合和简单逻辑编排的场景；

对于以上适用场景，可以具体应用到以下场景：

1、BFF场景

主要是解当前BFF决编排的问题，从机制上解决引擎服务集群稳定性的问题，支持paas服务的管理方式，降低服务机器成本；更多的从协议转换、数据聚合、逻辑编排维度提供能力；

2、服务端业务场景（统一服务端SDK）

灵活轻量的利用编排平台沉淀的服务端技术栈资产能力完成业务需求（只需接入引擎SDK，相当于接入了已沉淀的SDK的使用姿势），降低服务端资产使用成本，提高交付效率，在一定意义上实现技术架构转型；

总结

本文介绍了Tango Flow平台建设的问题、诉求及构建思路，首要是解决编排的问题，支持更复杂的编排场景，服务编排出来的产物可以是RPC、API服务，编排出来的RPC、API服务直接集成在BFF中，灵活解决BFF应用的服务编排问题，同时从机制上解决引擎服务集群稳定性的问题，支持paas服务的管理方式，降低服务成本，同时在平台建设过程中，注重对资产的沉淀、平台研发易用性和使用效率；从长远来看，在整个研发全链路上进行低代码尝试，对于服务端的逻辑编排、服务编排以及更长远的基于模型编排驱动方式提供基础演进路线，能够更进一步实现技术中心全栈化，提升交付效率，降低交付成本；

Tango Flow是云音乐自研的流程编排平台，具有丰富的应用场景，可以用在BFF场景、服务端业务场景（统一服务端SDK），并具有场景易扩展能力；Tango Flow可通过可视化拖拉拽的方式快速搭建、测试和发布流程，平台提供简单易用流程搭建能力，通过组件标识+JsonPath可完成参数在流程节点之间传递；支持整个流程的调试、节点维度调试（RPC、HTTP、Groovy脚本）的调试能力，并且无需发布，可指定环境、直接测试、调试记录；建立统一的运维协作机制，发布流水线全生命周期管理，秒级完成发布，卡点环节使发布可靠、低风险、随时按需执行；具有监控告警能力，不同维度数据，不同负责人关注信息不一样，根据访问分布、RT访问分布，并在流程维度有RT和调用错误率的告警；

未来规划

1、服务端低代码演进：提供更多触发场景，整合现有服务端技术栈组件；

2、前后端低代码一体化：完成模型驱动，实现前后端低代码一体化；

3、平台体验 & 效率优化：基于业务痛点及反馈，完善和优化现有平台能力；

最后

更多岗位，可进入网易招聘官网查看 https://hr.163.com/