作者 | 廖祥俐 2015 年退出网易云音乐，云音乐曲库研发负责人。
策动 | 望宸

网易云音乐最后的音视频技术大多都利用在曲库的数据处理上，基于音视频算法服务化的教训，云音乐曲库团队与音视频算法团队一起合作，一起共建了网易云音乐音视频算法解决平台，为整个云音乐提供对立的音视频算法解决平台。本文将分享咱们如何通过 Serverless 技术去优化咱们整个音视频解决平台。

本文将从三个局部向大家介绍：

• 现状：音视频技术在网易云音乐的利用状况，引入 Serverless 技术之前遇到的问题；
• 选型：调研 Serverless 计划时的思考点；

• 落地和瞻望：咱们进行了哪些革新，最终的落地成果和将来布局。

  现状

  ​

作为一家以音乐为主体的公司，音视频技术被广泛应用于网易云音乐的泛滥业务场景里，为了更形象的让大家感触到，这里列举了 5 个常见的场景：

1. 默认状况下，用户听到的是咱们采纳音频转码算法事后转好的标准化码率的音质，但因为流量无限或本身对于音质更高的要求，想要切换到差一些或更好的音质。
2. 用户能够应用云音乐 APP 外面的听歌识曲性能去辨认环境中的音乐，这背地应用到了音频指纹提取及辨认技术。
3. 在平台上的一些 VIP 歌曲，为了能给用户更好的试听体验，咱们会做副歌检测，让试听间接定位到低潮片段，这里用到了副歌检测算法。
4. 在云音乐的 K 歌场景里，咱们须要对音频的音高进行展现并辅助打分，这里咱们用到了音高生成算法去欠缺 K 歌的根底数据。
5. 为了更好的满足云音乐平台上，小语种用户的听歌体验，咱们为日语、粤语等提供了音译歌词，这里用到了主动罗马音的算法。

从下面的场景能够看到，音视频技术被广泛应用于云音乐的不同场景外面，施展了重要的作用。

从咱们的音视频技术做一个简略划分，能够分为三大类：剖析了解、加工解决、创作生产，这些一部分是以端上 SDK 的形式，在端上进行解决；而更多的局部，是通过算法工程化的形式，采纳后端集群部署治理，以服务的模式提供通用的音视频能力，而这部分是咱们明天分享的重点。

音视频算法的服务化部署工作中，须要理解很多相干音视频算法的特点，如部署环境、执行工夫、是否反对并发解决等，随着咱们落地算法的减少，咱们总结了以下法则：
​

​

1. 算法的执行工夫长：执行工夫往往与原始音频的时长成正比，云音乐很多场景下音频、视频的时长 Range 范畴是很大的，基于这个特点，咱们在执行单元的设计上，往往都采纳异步化的模式。
2. 音视频算法具备多语言个性：云音乐的算法包含了 C++、Python 等语言，对接环境上下文会带来极大的困扰，为了解决这个问题，咱们采纳标准化约定及镜像交付的形式，解耦各类环境筹备的工作，所以后续对于是否反对镜像部署，会成为咱们技术选型的一个重点考查。
3. 弹性的诉求正在变大：云音乐平台的歌曲，从我入职时候的 500w，到当初在线超过 6000w，增量 vs 存量的 gap 越来越大，当咱们疾速施行一个算法时，不仅要思考增量的接入，更要思考存量的疾速解决，所以在零碎设计中，会独自把执行单元的最小粒度剥离进去，便于疾速的扩容。

基于咱们对工程化的了解，及音视频算法解决的特点，云音乐的音视频解决平台的整体架构如下：
​

​
对于不同音视频算法解决的独特局部，咱们做了对立的设计，包含算法解决的可视化、监控、疾速试用和解决数据统计等，对于资源的调配也设计了对立可配置的管理模式，让整个零碎的公共局部能够尽可能形象并复用。

整个音视频算法解决平台最要害的，也是明天的分享重点，是执行单元的交互与设计。云音乐通过对立的对接规范、采纳镜像交付的形式，解决了很多对接和部署上的效率问题。针对资源的应用，因为咱们一直有新算法、存量 / 增量服务的存在，在上云之前，用的是外部公有云云主机申请 / 回收、内容容器化的形式。
​
为了更好的形容云音乐执行单元的运行流程，咱们将它更细化下，如下图所示：

通过音讯队列去解耦了执行单元与其余零碎的交互，在执行单元外部，咱们通过管制音讯队列的并发度去适配不同并发性能的算法，尽量管制执行单元的次要工作仅用于算法的计算，这样最终在零碎扩容的时候，咱们可能做到最小粒度的扩容。
​

在这个模式下，咱们落地了 60 多种音视频算法，尤其是在近一年来，服务化的算法占到了一半，这些算法向云音乐 100+ 的业务场景提供了服务能力。但更简单的算法、更多的业务场景，对咱们的服务化效率、运维部署和弹性能力都提出了更高的要求，在咱们上云之前，在外部曾经用到了 1000 台以上不同规格的云主机及物理机。

选型

​
随着业务场景和算法复杂度的减少，尽管通过了很多形式去简化了外部业务场景、算法等的对接，但越来越多夹杂存量、增量解决的算法，不同流量的业务场景规模，以及不同业务场景可能会复用同一类算法的，让咱们在解决机器资源的工夫，远比咱们在开发的工夫更多。
​
这个也促使咱们开始去思考更多的形式办法，去解决咱们遇到的问题，最间接的有三个痛点。
​

第一个是存量和增量的差别变大，和新算法落地的增多，咱们花在解决存量和增量的资源协调工夫越来越多；其次是随着算法复杂度的增高，咱们在申请 / 洽购机器的时候，须要关注机器的整体规格、利用率等；最初是，咱们心愿存量的解决可能放慢，在解决存量的时候有足够大的资源，在海量音视频数据处理时候，可能压缩存量与增量不统一的工夫。总的来讲，咱们心愿可能有足够大规模的弹性资源，让音视频算法服务不必再多去关注机器治理。
​
然而，理论革新不仅仅是关注最终服务能力，还须要综合思考投入的 ROI。具体来看：
​

• 老本：蕴含两方面，革新的施行老本和计算资源的老本。前者能够联合具体计划进行评估，失去所需投入的人日，此外，革新后在将来的灵便拓展性，也是咱们须要思考的点。后者能够通过云厂商官网给出的费用计算模型，联合咱们的执行数据，估算进去。咱们在老本方面的选型要害是，在革新老本可能承受的状况下，将来的 IT 老本不会大额的减少。
• 运行环境的反对：后面提到过，云音乐的运行环境比拟多样化，是以镜像交付的形式进行部署的；团队外部都有绝对欠缺的 CICD 反对，这个要求将来的降级、部署事务，例如规格配置上，是否可能简化开发人员对于机器等的关注。咱们心愿在革新后，不须要在此类事项上破费过多的工夫和精力，更多的关注算法执行自身。
• 弹性能力：除了云厂商提供的计算资源池的规模，咱们还会关注弹性算力的启动速度，是否可能对固定场景进行实例预留，以及是否提供更合乎业务诉求的灵便弹性能力，以更好的反对业务的倒退。

这些其实都合乎 Serverless 的定义，构建和运行应用程序都不须要对服务器进行治理、弹性能力出众等。综合以上的考量，咱们抉择了私有云函数计算的形式， 它能直观的映射咱们目前的计算执行过程，同时也能满足后续想尝试通过 Schema 进行算法的编排。 上面我会重点分享下引入函数计算 FC 的过程。

落地

​
咱们在一周内疾速试用了函数计算 FC，然而一个残缺的、高牢靠的架构，须要思考更多的因素。因而咱们的革新重点是只把算力工作通过函数计算 FC 弹出去，零碎在整体的对外输入输出上仍放弃不变，并且零碎领有流量控制能力，可能在遇到非凡状况时，降级到公有云进行解决，保障系统的高可靠性，具体的架构革新如下图所示：

云音乐的开发环境与函数计算的适配是革新的重点， 咱们重点针对部署、监控和混合云反对进行了革新。 部署上，咱们充沛利用了函数计算在 CICD 上的反对及镜像部署的反对，实现了镜像的自动化拉取；在监控设计上，一方面利用云上的监控报警性能，另一方面把它转化为咱们外部已有监控零碎的参数，让整体的开发运维解决可能维持一致性，最初是从代码设计上，思考可能兼容混合云部署的实现，最终实现了咱们音视频解决平台的 Serverless 革新。
​
从函数计算的计费策略上，咱们能够看到，有三大因素在影响最终费用，内存的规格、触发计算的次数，以及公网出流量的费用。间接从技术架构上看，大家可能更关注前两者，实际上流量费用也是一笔不小的费用，这个对于咱们来讲，也是关注的一个重点。
​
咱们依据函数计算的费用个性，在存储体系依然应用网易公有云的状况下，在第一阶段，首先选取的是公网出流量比拟少的音视频算法。对于公网出流量比拟少，我举个例子，对音频进行特征提取，如一个音频进去，提取一个 256 维的数组，获取的后果就只是一个 256 维数组，它是远远小于音频本身的流量，因而出公网的流量费用会比拟少。
​
在引入函数计算的第一阶段，特征提取类的算法失去了 10 倍速的晋升；稠密类的算法，能够了解为日常使用率很低的算法，在老本上失去了极大的节约。除此之外，通过函数计算的镜像缓存减速能力，优化了咱们节点的启动速度，让所有的服务拉起能够在秒级实现。这些工作，升高了算法运维解决中大量的运维老本，让咱们可能更聚焦关注在算法及业务本身。
​

上方左边这幅图是云音乐其中一个算法的运行示例，能够看到，咱们在弹性上的变动范畴是十分大的，而函数计算很好的满足了这个诉求。

将来，咱们心愿可能更进一步通过 Serverless 技术去解放咱们在运维上的人力投入，并将从存储上进行尝试，进而解决公网出流量的问题，让更多场景的音视频算法能够天然的实现；其次，随着算法复杂度的进一步晋升，使得计算资源上应用的更加简单，心愿通过 GPU 实例来优化计算过程；最初，在云音乐的业务场景中，实时音视频解决的场景也越来越多，同样的，它也有显著的顶峰、低谷的稳定特点，咱们心愿积淀更多的 Serverless 服务应用教训，最终助力云音乐实时音视频技术的倒退。