云音乐 CMS UI 框架建设思考与实践
背景
随着互联网人口红利的逐步消失，国内一二线互联网公司业务增长放缓，包括云音乐在内也都开始提倡降本增效。为了使得业务持续增长，需要技术层面可以提供更多的保障和支持。由于市面上合适的技术人员相对较少，团队人员增加相对缓慢，这就导致了业务增长要求和技术资源紧缺的矛盾。
现状
为了保障和支撑业务的发展，云音乐内部孕育出大量的平台化产品，其中公共技术、数据智能、质量保证相关的平台产品就有 40 多个，另外云音乐营收、会员、Look 直播等业务内也存在大量的 CMS 平台应用，并且 CMS 平台的数量还在不断增加。
通过对比和分析这些平台产品发现，它们都具备一定的模式化特征和诉求，同时每个平台或多或少也都有一些个性化的实现，比如环境/租户切换、菜单搜索、快捷入口（用户反馈、快速置顶）、应用配置等。这就要求研发人员在开发这些 CMS 平台时，既要快速初始化前端应用，又要单独开发这些个性化需求，并且后期应用的升级也是需要提前关注的。
问题
而在这样的背景和现状下，云音乐针对不同的登录鉴权场景、研发方式、以及微前端能力提供了 5 套应用模版。虽然初步解决了快速初始化前端应用，但与此同时也带来了以下的诸多问题：
前端应用的技术架构落后，脚手架 & 应用模版众多，模版应用产生了大量的代码 应用只能以源码为中心，逻辑晦涩难懂，开发人员的维护成本高，应用后期的升级十分困难 应用内部的依赖未做治理，三方包也未做 external 处理，导致 bundle 的资源体积大，加载性能差。 应用生成后，其已有的能力无法得到复用，也无法形成生态，导致不断的重复开发
可以来看下其中一个模版初始化的代码结构如下：
其中仅 base 和 config 目录一共包含 37 个文件，不仅提供了 CMS 应用的本地开发和构建、基础组件、菜单配置等能力，也包含了登录、权限码转化和校验等逻辑，而实际与业务相关的页面仅 release 目录。
因此，当前端研发人员开发此类应用时，不仅要去实现业务相关的逻辑，还要去了解和熟悉这些初始化的逻辑，随着应用需求不断迭代，维护成本逐渐升高、应用升级也出现更多的不确定性。
思考
那么，针对以上的研发现状和问题，从而引发出如下问题：
能力抽象和分析
通过对众多平台的能力抽象和分析发现，这些平台都具备菜单加载、路由跳转、登陆鉴权、内容渲染、数据通信等基本能力；同时又有平台的基本信息、主题和布局风格、权限类型、登陆方式等差异化的实现。基本能力再进一步抽象就等同于平台框架本身，而差异实现可转变为配置数据。
因此，不难看出各种业务平台实际就是平台框架和配置数据的组合。
解法
为了解决以上问题，我们基于 CHITU（云音乐应用研发元框架，本篇文章不做详细介绍）提供的应用本地开发和构建基础能力，研发了 Tempo 应用框架。
众所周知一首优美的音乐由曲调、速度、节奏等基本要素构成，Tempo 的意思是节拍、音速，寓意通过这种分层分包、配置化、插件化设计方式，明确各层级的能力，为应用框架提供更多的灵活性、可扩展性。
基于这样的设计理念，Tempo 提供了一套开箱即用的 CMS 应用研发解决方案，方便前端研发人员快速生产 CMS 应用，提高整体的平台研发和交付效率。
架构设计
根据 CMS 应用是否开启微前端能力，将前端应用分为主子应用两种。其中主应用定义了平台的 UI 框架展示、运行时环境、以及主子应用间通信的 SDK；而子应用通过应用注册机制将基本数据存储于 PaaS 平台（微前端应用管理平台），其仅需提供路由以及页面主内容。当主应用运行时，会从配置平台拉取相关数据进行解析并做展示。与此同时，主应用也可不开启微前端能力，以独立应用的方式进行开发，那么此时默认读取应用内的基础配置文件数据。整体的架构设计如下图所示：
其中 UI Components 聚焦视图部分提供 CMS 应用的诸多基础组件，包括应用容器、主题 Provider、顶部导航、侧边菜单、用户信息显示、快捷入口等，Runtime 提供基础逻辑能力，包括配置读取、菜单过滤、权限码转化、登录鉴权、应用启动、路由转化等，而 SDK 提供主子应用通信、主应用能力调用。
基于这套架构方式，为后续统一 CMS 应用架构，降低研发成本，奠定坚实的基础；而应用依赖的核心包都会有专人维护，无需担心后续的升级成本，从而保证了应用后期升级的可靠性和安全性。
工程结构
通过 Tempo 初始化的应用，相比较使用原来的应用模版具有以下优势：
具备更清晰的结构，仅仅只有 9 个文件，而旧的模版生成的文件数在 152 个 具备更少的代码，应用整体大小仅在 5.1M，而旧的模版生成的应用在 8.9M 具备更快的启动速度，应用启动完成仅仅需 6.8s；旧模版使用 umi 完全启动需要 48s 的时间；这在一定程度上极大的降低开发人员的焦虑感，减少不必要的等待时间。
其次，使用了 Tempo 框架后也保留了在应用内开发多路由页面能力，支持约定式和自定义路由，而约定式路由的能力目前是基于 CHITU 而实现的。
由于框架本身不直接依赖任何脚手架，因此在使用自定义路由时也可采用任何脚手架来进行本地开发和打包构建。初始化的入口文件内容如下图所示：
应用配置
Tempo 将平台应用的菜单布局、Logo、平台名称、菜单搜索能力、多语言、页脚信息、权限申请、用户反馈、快速置顶、登录体系、权限验证等基本能力内置进框架内，可直接通过配置的方式进行设置。当不需要这部分能力的时候，可以移除或修改相关配置参数，从而快速实现平台能力的定制需求。
这里举一个内部平台落地的 🌰：
视图集成
借助于微前端的能力，Tempo 默认支持页面级集成，即可将子应用内的某一路由页面集成至主应用内。而在此之上也提供了模块集成能力，模块是指页面内的某一视图区域。页面的集成是通过应用注册以及菜单编排来实现的，而模块的集成额外提供了 SDK 的渲染方法，可在一定程度上最大化复用平台的通用能力。
目前 CIO 和曲库也有落地相关能力，CIO 将应用内的规则能力抽象，不仅在自身平台使用，同时借助模块集成提供能力给曲库平台，从而使得歌单创建页具备 CIO 的规则能力。整体落地效果如图所示：
CIO 规则编辑模块
曲库歌单创建模块
用户反馈
Tempo 已和 Overmind（内部一站式研发效能平台，本篇文章不做详细介绍）工单体系打通，通过用户反馈可以随时记录遇到的问题、查看问题解决的进度以及最终的解决方案，支持一键查看自己所创建的工单列表信息。
登陆鉴权
Tempo 内置三种登陆模式，分别是 PMS、公技、无登陆态，根据所需的业务场景，可通过设置 runtime 启动参数或在线配置信息，开启相应的登录鉴权能力。
PMS - 需要 PMS 强管控菜单权限，通过配置数据即可轻松开启，同时也支持 PMS 2.0 配置。 ARCH - 公技平台产品场景 NONE - 文档类 CMS 应用场景
国际化
Tempo 已和内部千语平台（内部多语言配置平台，本篇文章不做详细介绍）打通，在配置了 localeAppId 参数后，可自动加载多语言列表，支持多语言切换；子应用通过识别 Cookie 信息中的 language 参数，即可轻松显示对应的多语言内容。
插件化
Tempo 支持动态加载插件，目前无权限页面以及对应的去申请 PMS 权限功能已通过插件的方式集成至框架内。后续将继续完善插件机制，提供插件市场和相关服务，方便 CMS 应用快速复用各类插件。
落地结果
目前 Tempo 应用框架已在内部覆盖 70+ CMS 应用，在助力业务快速迭代的同时，也顺带使得平台的能力进一步增强和升级，落地的结果主要体现在以下两个层面：
业务层面，覆盖了诸多新增的 CMS 应用，也帮助一些老的 CMS 应用升级到新的技术栈，提供了在线配置能力、页面和模块复用能力的同时，也顺带解决了后期升级困难问题。落地的代表应用有：CIO、Pylon2、磐石、魔镜、PMS、营收平台等。 技术层面：统一 CMS 应用研发流程和技术栈，默认支持集成 Tango （云音乐低代码研发方案）产出的子应用页面，产出 6 个核心依赖包，统一原先 5 种 CMS 应用模版，解决了之前研发 CMS 应用所面临的诸多问题。
未来展望
未来 Tempo 在不断完善自身能力建设的同时，将融入 AIGC 的能力，主要体现以下四个方面：
框架配置化能力完善，持续沉淀基础能力，提供在线配置 插件化能力增强，提供插件市场和相关服务 CMS 应用智能化 ，提供智能答疑入口 减少 Tempo 核心依赖包因为升级而需要发布的频率，提供在线修改版本发布能力
本文发布自网易云音乐技术团队，文章未经授权禁止任何形式的转载。我们常年招收各类技术岗位，如果你准备换工作，又恰好喜欢云音乐，那就加入我们 grp.music-fe(at)corp.netease.com！