网易云音乐的前端工程化建设实践

作者|葛星

编辑|黎安

网易云音乐(以下简称“云音乐”)的前端团队大概在 4 年前初具规模,4 年多的快速发展过程当中做了很多 0 到 1 的平台,造成了平台深井,比如研发的体系,部署的体系,监控的体系等,这些体系在云音乐初期快速发展中起到了非常大的作用。但是随着人员的更迭及业务不断的发展,初期各自发展的垂直体系遇到了和产品后期同样的问题,新增一个功能越来越复杂,涉及的链路越来越长,花费的代价越来越高,用户需要在各自的平台跳入跳出,会有各种各样的卡点,导致效率降低。如何串联各平台场景,打破平台深井,这是云音乐前端工程化面临的第一个挑战。

除去研发之外,所有的应用在上线前还需要经历测试和部署以及上线后的运维,但是每种应用类型在每个阶段的关注点不一样,所依赖的服务也不一样,比如 Node 应用的部署会依赖云原生,但是 H5 的应用依赖 NOS 的静态资源服务。如何使用一套架构支持不同应用类型的全生命周期发布,这是云音乐前端工程化面临的第二个挑战。

云音乐的业务从单一的播放器发展到社区生态的过程中,为了体验和效率之间的平衡,涌现了多种多样的应用形态,比如 H5 的应用、RN 的应用、中后台的应用、Node 应用等;为了一些极致的体验,在 H5 下又细分离线和闪开,RN 又细分为拆包应用。这些不同的应用类型,工程规范不一致,脚手架也不一致,导致开发同学在上手时有一定的成本,也造成了维护上的困难。如何使用一套架构去收敛这些不同的研发体系,这是云音乐前端工程化面临的第三个挑战。

本篇文章着重针对前两个挑战分享解决思路,我们也发起了一个代号为 Febase 的项目,这个项目目标是针对前端开发者,通过一站式应用研发平台,提升开发部署的效率和体验,并且降低后续应用扩展的维护成本。

产品设计

在 Febase 之前,云音乐没有完整流程的研发体系,部署前的流程基本都在线下完成,也没有研发流程管控的概念,开发在即将上线之前,先将代码合并到 master 再进行部署。这里会存在几个问题,一个是没有统一的研发流程,无法做标准化;一个是有可能上线前的代码存在问题,即便是经过了 QA 的测试,但是代码已经合并到 master,有可能会让其他人再次将错误的代码带上线。所以在产品层面上,我们设计了以应用为中心的全生命周期的研发工作流,将各自分散的体系按照研发的维护来串联各平台的关键节点,每种应用类型都会经历从初始化、开发、构建、编译、部署、监控的流程,在各自垂直的链路上提供不同的差异化能力来完成,这样既收敛了用户的心智,也有了统一的工具产品来提升整体的基建水平。

整体架构

我们先来看下 Febase 的整体架构,我们将各类公共技术所属平台进行服务下沉,统一整个控制台入口,中间层通过自研的流程引擎来编排不同应用类型的部署流程,极大提升了后续新增业务类型的扩展性,前端通过微前端的方式进行自定义扩展,各业务组可以基于此扩展能力定制属于自己的页面,无须另起平台。

研发管控

流程引擎编排

工程化里最重要的就是研发过程管控,由于 Febase 本身需要支持多种不同的应用,而每种应用类型的研发流程是不同的,下面展示了 GraphQL 应用和 RN 应用的差异。

可以看到不仅流程不一样,UI 也不一样,传统的方式,硬编码当然也可以解决问题,但是随着应用类型不断扩充,代码可维护性会直线降低。

那么如何能够更好的使用技术手段进行解耦呢,我们想到了流程引擎,业界比较流行的流程引擎就是BPMN,也有对应的 Node 实现,但对于我们而言,一方面是场景没有这么复杂,另一方面还需要针对 UI 进行编排,所以我们选择自研一个简单的编排引擎,最终效果是针对上面的场景可以通过下面的代码来实现,比如 GraphQL 的研发流程:

服务端侧定义:

代码语言:javascript
复制
export default workflow({  extra: {    appType: 'GraphQL',  },})  .next({    name: '开发',    proc: {      endpoint: 'fn:dev',      parameters: {        sprintId: 'extra.sprintId',      },    },  })  .next(    sequential({ name: '卡点' })      .add(        parallel({ name: '质量验证' }).add({          name: 'Review',          proc: {            endpoint: 'fn:review',            parameters: {              sprintId: 'extra.sprintId',              sprintService: 'instantExtra.sprintService',            },          },        })      )

前端侧定义:

代码语言:javascript
复制
bindViewOfWorkflow('graphql', '0.0.1')  .withOverview(Overview)  .withNodeView('开发', StageDev)  .withNodeView('卡点', StageCheck)  .withNodeView('回归', StageReg)  .withNodeView('质量验证', NodeInTabs)  .withNodeView('Review', CodeReviewCheck)  .withNodeView('卡点手动确认', ManuallyCheck)  .withNodeView('预发', StagePre)  .withNodeView('上线', StageOnline)  .withNodeView('完成', StageComplete);

只需要分别定义 Node 侧和前端侧就可以完成一种应用类型的扩展。在 Node 侧的定义中endpoint指定了推进到该节点时需要执行的服务,比如 Review 节点,下面就创建了一个 CR 的流程:

Review 节点 Node 侧:

代码语言:javascript
复制
export default async function review({  sprintId,  sprintService,}: {  sprintId: number;  sprintService: SprintService;}) {  try {    await sprintService.requestCodeReview(sprintId);    return {      code: NodeStatus.Suspended,    };  } catch (error) {    return {      code: NodeStatus.Error,      msg: (error as Error).message,    };  }}

前端侧只需要通过 useWorkflow 的 hooks 传入当前发布的 ID 即可获取到流程进行到哪里的状态:

流程视图侧代码:

代码语言:javascript
复制
import { useWorkflow } from '@ripplet/engine-react';
function Detail(props: DetailProps) {  const { sprintId } = props;  const { Overview } = useWorkflow(sprintId);
  return (    <Card>      <Overview />    </Card>  )}

通过自研的流程引擎,我们将流程状态管理与具体的业务逻辑解耦,并通过流程引擎驱动前端视图的变更,以此降低了业务逻辑开发的复杂度。

流程引擎实现

实际上在 Febase 的流程相对较为简单,只需要支持并行、串行、跳过、回退能力即可,业界大部分流程编排都是通过 XML 文件来定义的,我们这里采用了 JS 的方式,主要是省去了解析 XML 的成本,JS 的定义可以直接存储为 JSON 格式;其次我们提供了前端的视图配合套件,可以方便地进行前后端状态的绑定。当用户创建一次开发需求的时候就创建了一个流程,这个流程状态关联了流程的 ID,每当流程触发了下一步,流程引擎就会执行对应的逻辑并更新流程的状态进行存储,回退同样是对流程的状态进行变更然后存储。调试阶段可以将状态放置在内存中,如果是生产环境我们就将流程的状态存储在 MongoDB 中,因为流程的状态非常适合文档型数据库的存储。

那么,流程引擎核心的一个点是如何处理需要挂起的逻辑的?很多节点的逻辑是需要三方服务来完成的,在 Febase 里是通过下面的方式:

  • 引擎通知外部系统进行处理,通知时会传递 fid 和 pid,fid 是当前流程 ID,其中 pid 表示发出此 RPC 请求的 Stage 对应的是 process ID
  • 外部系统通过返回 pending 状态码,表示该请求需要异步处理
  • 引擎接收到 pending 状态码后,会设置自身状态为 Suspended,并对当前的快照进行保存
  • 外部系统处理完毕后,通过之前的 fid 和 pid 让引擎继续之前的流程

举个例子,下面的代码首先注册了两个 RPC 服务,然后定义了'quality'的并行的流程,分别是 Lint 和 Review,Review 这里返回的状态‘suspended’,是因为 Review 是需要手动执行的,这里就是一个挂起的异步操作:

代码语言:javascript
复制
Engine.externalFnsProvider.registerFn("Basic", "0.0.1", "pass", async () => ({  code: NodeStatus.Succeeded,}));
Engine.externalFnsProvider.registerFn("Basic", "0.0.1", "async", async () => ({  code: NodeStatus.Suspended,}));
(async function() {const w = workflow({      name: "Basic",      version: "0.0.1",    })      .next(        parallel({ name: "quality" })          .add({            name: "Lint",            proc: {              endpoint: "fn:pass",            },          })          .add({            name: "Review",            proc: {              endpoint: "fn:async",            },          })      )      .settle();
await engine.exec(w);})();

上面的代码执行将会产生下面的数据结构:

代码语言:javascript
复制
{  "fid":"d5b27302-442e-4a12-a0ce-93eb6036a798",  "workflow":{    "name":"Basic",    "version":"0.0.1",    "desc":"",    "status":"running",    "isLocked":true,    "nodes":{      "Lint":{        "type":"single",        "name":"Lint",        "status":"succeeded",        "isTerminal":false,        "proc":{          "endpoint":"fn:pass",          "parameters":{
          },          "parent":"Lint",          "pid":"0aa64a29-c69a-4bc3-8bbc-073ea6432d2b",          "result":{            "code":"succeeded"          }        },        "parent":"quality"      },      "Review":{        "type":"single",        "name":"Review",        "status":"suspended",        "isTerminal":false,        "proc":{          "endpoint":"fn:async",          "parameters":{
          },          "parent":"Review",          "pid":"3671a0c0-98c6-4ef0-8921-c62a16cacfb7",          "result":{            "code":"suspended"          }        },        "parent":"quality"      },      "quality":{        "type":"parallel",        "name":"quality",        "status":"suspended",        "isTerminal":true,        "sub":[          "Lint",          "Review"        ],        "strategy":"all_of",        "prev":"Basic"      }    },    "next":"quality",    "reach":"quality"  },  "runnings":[    "0aa64a29-c69a-4bc3-8bbc-073ea6432d2b"  ],  "extra":{
  }}

在执行后的数据结构里,因为 Lint 是直接通过的,所以 Lint 节点的状态是'succeeded',Review 是一个挂起操作,所以 Review 的状态是'suspended',当其他用户进行 Review 通过的动作后, 就会通知流程引擎继续根据这个数据结构进行后续的执行。流程引擎的执行其实就是遍历这个数据结构调用服务的过程。

部署能力的抽象

针对不同应用类型的发布,我们定义了如下接口,这样我们就可以通过不同的实现来解耦掉部署服务的调用,这样是面向对象中常见的操作方式。

DeployProvider 定义:

代码语言:javascript
复制
interface IDeployProvider {  // 发布  publish(params: ProviderEnv): Promise<void>;
  // 获取发布状态  getStatus(params: ProviderEnv): Promise<ProviderStatus[]>;
  // 获取部署日志  getLog(params: ProviderEnv): Promise<ProviderLog[]>;
  // 回滚  rollback(params: ProviderEnv): Promise<void>;
  // 其他公共抽象方法 ...}

针对静态部署我们实现上述定义的接口:

H5 部署:

代码语言:javascript
复制
class SdpStDeployProvider implements IDeployProvider {
  sdpRpc: SdpRpc;
  // 发布  async publish(params): Promise<any> {    // 简化逻辑    this.sdpRpc.projectPublish({      ...    })  }
  // 实现其他抽象接口...}

这样我们就可以通过统一的部署服务来屏蔽不同应用的差异:

部署服务:

代码语言:javascript
复制
class DeployService {
  async publish(params) {    const { appId } = params;    const provider = this.getProvider(appId);    return provider.publish({      ... // 省略参数    });  }
  // 获取 Provider  async getProvider(appId) {    const appType = this.getAppType(appId);    switch(appType){      case 'Web':         return this.sdpStDeployProvider;      case 'NodeJS':        return this.alpacaDeployProvider;      case ...    }  }}

开放能力

Febase 除去为自身提供服务外,业务还有一些基于 Febase 本身的扩展,比如云音乐桌面端的日志平台,Febase 充当了元数据信息管理的角色;第二个是每个业务组或多或少有一些特定的业务诉求,这些诉求不适合通过公共的产品方式来承载,比如对于活动的监控,只是其中某个业务组的诉求,所以 Febase 通过开放能力来支持业务的二次开发,既降低了成本,又避免了多烟囱的产生。

开放网关

对第三方平台,使用特殊请求头。通过白名单的方式来指定开放接口,然后在每个业务逻辑实现中,根据请求来源,单独地做权限校验。过去这种职责不单一、面向过程式的鉴权方式,将会导致开放接口难以维护和扩展,无法承载多变的业务对 Febase 底层能力开放的诉求,我们的解法是提供声明式的鉴权配置及多消费场景的统一认证机制,抽取单独的接口网关。

在后端的接口中,用声明式的方式描述接口所需的最低权限。在应用启动时,会收集全部的路由 + 权限声明,并存入数据库中。并将路由与权限信息注册至网关。由于路由与权限信息都做了入库,所以也可以在管理后台中,对接口的权限做配置管理。对于多消费场景,统一使用 Febase 派发的用户 Token 进行认证和鉴权。只有满足权限要求的请求,才会打到 Febase 后端。

单独的网关设计还有另外一个好处,就是第三方应用同样可以将接口注册到网关上,使用统一的鉴权服务,比如下方的云鹿素材就属于业务组维护的第三方应用:

微前端接入

除去接口外,Febase 在产品侧提供了多个维度的自定义能力,分别是业务组 - 应用 - 概览三级维度,下图描述了 Febase 提供的三个扩展点:

业务组维度用户可以在业务组维度插入多个自定义的页面,用来管理团队各项技术建设。

应用维度

同样在应用维度,针对应用的特殊场景也可以定义,比如下方的活动策略就是专门为云音乐的年度报告所创建的,也是业务组基于 Febase 的开放能力自行开发的。

概览维度

用户只需要在设置页面填写如下信息就可以导入一个页面,平台支持微前端和 iframe 两种方式:

其核心是借助了 qiankun 的能力,只需要根据设定的 URL 来动态加载对应的资源然后渲染即可,关键代码如下:

代码语言:javascript
复制
import { loadMicroApp, MicroApp } from 'qiankun';
function MicroAppComponent({  name,  title,  entry,  container,  customProps = {},  match,}: MicroAppProps & RouteComponentProps) {  const app = useRef<MicroApp>();  const [err, setErr] = useState<Error | null>(null);
  useEffect(() => {    app.current = loadMicroApp(      {        name,        entry,        container: `#${container}`,      } as any,      {        sandbox: { experimentalStyleIsolation: true },      }    );
    return () => {      if (app?.current) {        app.current!.unmount();        app.current = undefined;      }    };  }, [container, name, match.url, customProps, entry, title]);
  return (        <div id={container} />  );}

总    结

最终我们通过 Febase 使用联合与开放的策略成功统一了云音乐的前端基础设施,覆盖音乐事业部所有前端研发人员,日均构建次数 350+,活跃应用 220+;也提供了自定义的扩展能力,帮助业务最小成本地接入到 Febase 平台。后续针对应用类型的扩展也变得非常简单,比如我们针对 GraphQL 提供的支持,基本复用了当前的平台能力。

如果你也面临同样的问题与挑战,期望通过一种非常优雅的方式来解决,希望这篇文章的过程和实现能够带给你一些启发。最后也感谢蚂蚁提供的 Kitchen 插件,在产品交互设计上给我们提供了很多灵感。

作者简介

葛星,网易云音乐前端开发专家,前端公共技术团队负责人,网易集团大前端委员会委员。十余年从业经历,曾是阿里集团最大的中后台设计系统工厂 Fusion Design 核心架构师,从前端工程化到全栈技术体系,以及前端智能化均有所涉猎。

在前端规模化 UI 生产领域及架构领域有深入的研究,包括但不限于设计系统、应用框架、低代码搭建、微前端等。

今日好文推荐

Node.js 之父着急宣布:Deno 将迎来重大变革,更好地兼容 Node 和 npm 包

操作系统的“冷板凳”要坐多久?万字长文解读 16 年开源老兵的坚持

我认为前端的职责可能需要重新划分

传美的被勒索千万美元,连夜天价聘请安全专家;软银抵押一半阿里股票,孙正义:“为过去贪图暴利感到羞愧”;谷歌数据中心爆炸 |Q 资讯

活动推荐

将于 9 月 15-16 日举办的 GMTC 全球大前端技术大会(北京站)上,葛星担任了「大前端设计协同」专题的出品人,探索大前端如何与设计进行更好的协同,减少设计与大前端的沟通成本,提升双方的协作效率,目前已上线 2 个议题,分别是《消除动效研发成本:腾讯 PAG 动效解决方案》、《网易云音乐基于 C2D2C 的无损设计协同》。

此外,会议还设置了 TypeScript、跨端技术选型、前端 DevOps 实践、IoT 动态应用开发、低代码等共 12 个专题,50+ 大厂技术专家现场分享,点击底部【阅读原文】查看更多精彩内容,感兴趣的同学联系票务经理:+86 13269078023