共计 3478 个字符，预计需要花费 9 分钟才能阅读完成。
作者：辰木
背景
随着互联网人口红利的逐渐隐没，国内一二线互联网公司业务增长放缓，包含云音乐在内也都开始提倡降本增效。为了使得业务持续增长，须要技术层面能够提供更多的保障和反对。因为市面上适合的技术人员绝对较少，团队人员减少绝对迟缓，这就导致了业务增长要求和技术资源紧缺的矛盾。
现状
为了保障和撑持业务的倒退，云音乐外部孕育出大量的平台化产品，其中公共技术、数据智能、质量保证相干的平台产品就有 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！
