开发者学堂课程【云原生最佳实践案例：实战案例—网易云音乐】学习笔记，与课程紧密连接，让用户快速学习知识。
课程地址：https://developer.aliyun.com/learning/course/1052/detail/15618
实战案例——网易云音乐
内容介绍：
一、现状
二、选型
三、网易云音乐音视频算法处理的 Serveless 探索之路
一、现状
今天分享的主题是网易云音视频算法处理的 Service 探索之路。接下来会从业务开发的视角来讲 Service 技术它是如何从开发效率上面以及最终业务的推进速度上面去提升业务开发效率。
首先来介绍音视频技术在网易云音乐的应用。网易云作为一家以音乐为主体的公司，网易云音乐的音视频技术是应用在各个场景里的，为了更直观的让大家感受到，这里举五个简单的例子：
第一个是用户在听歌的时候，用户可以根据自己的流量诉求或者音质偏好，去选择自己想要听的科学的音质，这背后用到了网易云的音频转码算法。
第二个是用户可以通过网易云平台的听歌识曲功能去识别环境中的音乐，这背后用到了网易云的音频指纹提取和识别技术。
第三个是在试听场景里面，为了能够给用户一个更好的试听理念，网易云会自动检测歌曲的副歌部分，即歌曲的高潮部分，这背后用到了网易云的歌曲副歌检测算法。
第四个是在 K 歌场景里面，网易云会给用户展示歌曲的音高线，来辅助用户演唱，同时辅助用户打分，这背后用到了网易云的歌曲音高生成技术。
第五个是为了更好地提升网易云平台小语种用户的体验，会给小语种歌词提供音译歌词，也即罗马音，这背后用到了网易云的罗马音自动生成技术。
可以看到，音视频技术广泛的应用在整个网易云音乐的各个基础领域，大家可以打开网易云音乐去体验一下这个场景。
总的来说，音视频技术在网易云音乐中可以分为三大类：一类是分析理解，一类是加工处理，还有一类是创作生产。网易云通过一种或多种算法的组合，去向网易云各个 app ，各个场景里面去提供服务。其中一部分服务能力是通过客户端 SDK 的方式来提供一个端上的算法处理能力。更多的则是通过后端服务部署的方式去提供一个统一的音视频算法处理能力。这篇的重点也会是从后端的集群部署的服务中去讲述这个问题。
结合网易云服务化经验，总结出音视频算法处理的几个特点，这些特点它会决定我们整个架构的设计：
第一个是我们发现大部分音视频算法的处理，它的处理时长会跟原始音频时长成正比，这个决定着我们在大部分架构上面的设计，会采用一种易固化的方式去做设计。随着算法处理复杂度的提升，我们从最初的音频、视频的基本处理，到现在会融会贯通地继续学习，分析推理等逻辑。我们的语言环境、开发环境会变得越来越复杂。为了能够减少在环境处理上的效率，我们与音视频算法团队去约定了一个进项交互部署的方式去解决这个问题，这个也是我们在后面做选情的时候会要求我们所选的对应服务要有支持进项部署的能力。
最后一个非常核心的诉求，就是弹性处理的场景非常多。一个新算法的落地，不仅要快速的去保障增量数据的快速揭露，还要确保平台上所有的常量数据进行快速处理。只有两者都处理干净，才能说这个算法是完全落地的。
除此之外，网易云作为一个音乐平台，还有一些更特殊的场景，其于摩登天空达成了版权合作。与此同时，网易云可能会达成几万首、几十万首、几百万首，甚至几千万首曲库的打通。并需要以最快速度去完成这批内容的上限以及处理，这对网易云的弹性提出了一个非常高的要求。
基于这些理解，网易云对其整个音视频算法处理平台进行设计。网易云首先提供了统一的接入平台，去接入业务方以及底层算力的相关性。然后把音频、视频的算法处理的共同部分进行抽象，做成统一的系统管理方式去支持算法的数据统计，处理监控和可视化算法的处理。
对于每一种算法，网易云都有资源管理的诉求，且都会涉及到存量和增量数据，甚至随着用户操作的波峰波谷，还需要做好动态的资源配置。网易云对这部分也进行了抽象，可以通过动态配置化的方式去进行资源的管理。最后把最核心，也即最小力度的执行单元放在了一起，它会由一个 Java 进程和一个算法的进程进行组合，然后运行在云主机或容器化环境中。底层依赖的是网易云的对象存储以及计算资源，同时依赖消息队列去完成易固化设计。更具体的执行单元可以用以下的流程进行展示：基于消息触发，然后在机制上去通过消息队列的控制去完成处理，最终转成消息的方式，去接入整个执行和业务处理的过程。基于这种模式，对很多的算法服务进行了统一的处理，最终达成了60多种音视频算法的落地，然后服务于网易云音乐的100多种场景，同时在日常管理的机器规模已经达到1000台以上的不同规格的云主机和物理机。虽然通过很多内部的约定以及之前一些约定的处理，网易云解决了内部的一些对接部署的效率问题。但随着近年来音视频算法落地的快速增加，网易云也遇到了一些新的问题，这些问题也是在选型里面会重点关注的。
二、选型
首先是算法落地速度的增加，网易云可能会同时落地多种算法，而多种算法可能都会涉及到存量跟增量数据的处理。不同算法对机器规格的要求会不一样，需要申请不同的规格去进行集群的部署。同样的，为了尽可能保证算法的落地速度能够提高，对弹性池的要求也会越来越高。比如说如果同时落地多种算法时，对弹性池的要求也会非常大。从这上面可以看出，在开发演变过程中，逐步从业务开发，慢慢聚焦到针对运维部署的关注上。这也是引发网易云对技术选型的想法，并去探索新的技术。
Service 就是这样一种概念，去让应用开发能够更多的去聚焦于业务本身，而不是去关注应用服务。在探索一些公有云上的 Service 服务过程中，这些点是网易云关注的：
第一个点是成本。成本包含两部分：第一个是改造成本，改造成本是需要花多大成本去完成现有的系统的改造。其次是能不能通过改造之后去支持未来对网易云平台或对其整个系统演变的支持。第二个是 IT 成本，也就是在选用了新的选型之后，会让整个 IT 产生大的上升。当然期待的肯定是至少能够维持当前，甚至最好的情况下能够大幅的优化 IT 成本。
另一个关注点是运行环境上的关注。网易云已经花了很长的时间去解决内部运行环境的问题，网易云希望选型的服务里面它能够让工作人员不会因为选型新的服务去引入一个新的问题，让他们能够尽可能多少关注像 CICD 、镜像部署这些问题。
最后是对于弹性上面的支持，对于弹性上的支持，工作人员希望它能达到的效果是弹性池能够足够大，并且可以不用去关注弹性这个事情。其次是它需要满足在一些特殊场景下，可以通过一些实例的预留，去解决特殊场景的要求。同时，对启动速度也有一定的要求，希望它能够在秒即去达到这样的实现。
最终，网易云选择了阿里云的函数计算，为什么是函数计算呢？从前面网易云的架构其实也能看到，其是通过消息驱动的方式去加塞无状态的服务去实现这个特点。
函数计算刚好非常契合这样的架构。它是一个由四件驱动，可以将弹性的事情交给它，然后去完成免运维的弹性执行能力，再加上它周边提供的像 CICD ，镜像部署等等相关的知识，可以让工作人员更多的时间关注业务开发本身。函数计算是按量付费的，可以让我们在使用之前就能算出使用成本。
在这里其实也有一个小插曲，作为一个个人开发者，我其实在20年的时候准备去购买一台 ECS 来完成我每天想给自己跑一个任务的诉求。经过调研以后，我发现其实函数计算这个按需使用的付费它能够极大地满足我的诉求。在使用它之后，它的免费额度可以让我几乎零成本去执行我的任务。这个可能也是大家在作为一个开发者，在规划自己的钱的时候会更精打细算一点。这个经验也是在后面的落地过程中，给了我们很大的帮助。
我们在落地时首先考虑的是针对我们系统的改造，在系统的改造首先我们是进行快速的试用，其实试用函数计算结合我们之前的经验是一个非常快的过程，我们在一周内就完成了几个算法的快速接入，然后我们更多的精力是花在针对整个系统在混合已经部署情况下面的高可用性的支持。我们对整个流量进行监控，同样的对阿里云的处理结果也进行了监控。处理结果它的监控会直接影响到我们的流量调度策略，因为我们单个函数计算的执行实例可能是会有上限的。为了防止这种情况，我们会做一些相关的流量切换的操作。
然后整体更多的工作就会在阿里云上建立我们的函数实例，然后达成整个系统的运行。在架构改造之外，我们其实把周边的服务进行快速的支持。
首先是部署上面的，由于它在周边的 CSD 相关的服务上都是非常完善的，我们很快的就完成了 CICD 的自动化。其次是作为一个混合云的部署架构，我们需要考虑的是基础设施上的迁移，对我们来讲包含两部分：第一个是存储。因为音频文件都不算小，而且如果是几千万数据的话，那整个数据量是非常大的。我们原先走的是内网，那需要走的是经营 CDN 的方式进行获取。
其次是监控。然阿里云提供了比较完善的监控，但是我们也有自己系统的监控。所以我们需要将他的监控转化为我们的监控，以一个一次性的方式，去监控解决我们整个系统平台运行的问题。然后是针对部署，由于我们需要支持能够同样降级到网易云，所以我们把代码进行了改造。相关的环境信息配置去通过下发的方式去进行传入，然后去支持我们的一套代码能够实现多云的能力。
最后我们先公网出流量比较小的业务进行快速的试用。首先在特征提取上，我们本来预期的时间是在两个月左右去完成千万级数据的处理，但实际上一周内就完成了整个数据处理。同样的对一些稀疏的业务，比如说像由人工触发去检测的工具，以及一些和弦分析的业务，我们通过算云能够快速的降低稀疏业务的执行成本。同样的，整个过程最重要的是我们可以不用再关心运维情况，在后面，我们准备推进更多的业务进行迁入函数计算。在这里解释一下什么叫“公网出流量小的业务”，因为函数计算的执行成本包含三部分，它主要与三部分有关：它的内存，它的执行时间，它的流量。举一个公网出流量比较小的业务的例子：对一首歌曲的曲风进行判定，判断它是流行还是古典。输入一首歌曲，返回一个标签，那么返回的流量是非常小的。如果输入一个文件，它转出一个文件，那么这种情况属于流量很大的。这也是我们后面在进一步深入使用函数计算需要改造的一个点。右边这幅图就是我们在使用函数计算整个过程中，某个函数弹性的执行情况。可以看到分子分母的差异非常大，极大证明了弹性的必要性。
最后，对于未来，我们还准备从以下三个方面去进行改造：第一个是前面提到的，由于存储的问题，我们可能要做公网流量的考虑。后面希望能够做相关的打通，以便让我们更原生的去使用函数计算的所有能力。其次是在 GPU 算力上的弹性。
采购过 GPU 机器的应该知道，我们采购起来是非常昂贵的。但如果使用不够充分的话，那作为采购方可能会非常的浪费。我们希望能够与阿里云函数计算一起解决 GPU 算力的问题，最后希望函数计算能够更多应用于我们实时音视频场景，能够解决我们更多场景上的弹性诉求。
三、网易云音乐音视频算法处理的 Serveless 探索之路
这里来分享 Serveless 的探索和实践。首先简单介绍 Serveless 的相关概念和相关的解决方案，之后具体讲解网易云音乐在 Serveless 和音视频算法处理的探索和最佳实践。在说到 Serveless 就不得不提在云计算领域有两篇著名论文：第一篇是在09年伯克利大学发表的关于云计算的预测及技术的研究，目前他提到的一些云计算的技术都已经在云上实现了，现在我们使用云可以像使用水电煤一样。他在19年发布了第二篇关于 Serveless 的技术研究，也指出了 Serveless 是接下来十几年云计算的发展方向，所以说 Serveless 是云计算的2.0。
这篇论文也指出了 Serveless 的相关概念，可以简单看一下其中它部署在云上的业务能够按需去使用、按需弹性、按需付费，这些是 Serveless 的特质。
可以简单理解为 Serveless = FaaS + BaaS，FaaS 其实就是大家所熟知的 Function as Service 。
另外，在 CNCF 他也发表了关于Serverless的一些概念和定义和伯克利的论文非常的相似，也提到了部署在云上的业务或者应用以函数计算的形式或以函数的方式来进行开发部署。在云上可以做到按需弹性，按需付费。这样的业务或者说服务也可以称之为 Serverless 。目前 Serverless 已经成为各个云厂商以及各个头部客户在做降本增效的一个最佳的一个选型。对于阿里云来讲我们在 Serverless计算这个领域，不仅仅有函数计算这个产品。
函数计算大家可以理解为是继云主机和容器服务之后的新一代通用计算平台。我们也是在业界最先创新性的推出了Serverless应用引擎SAE。我们看到函数计算在落地客户的过程当中，有一些例如微服务之类的业务，在部署这类业务的时候有一些不足之处，他没有注册中心。所以我们也推出了SAE,SAE目前在微服务和应用托管这一块有大量的落地case。
接下来的一场分享，南瓜电影也会去讲他们的最佳实践。目前函数计算加SAE我们可以做到全场景的覆盖，然后去推出all on Serverless 的这个概念。今天我们主要聚焦在函数计算,让我们看一下目前函数计算在音视频处理，在Serverless轻量化的 ETL，在实现驱动等这几个场景有大量的落地case。
这里主要给大家展开去讲一下函数计算在音视频处理这个场景下的一些方案。目前在各行各业里，短视频、长视频以及直播会逐渐成为很多客户的最核心的一个业务场景。客户面临有大量的不同类型的终端，以及快速多变的业务类型。
那怎样能让我们的音视频处理系统能够快速响应市场变化，能够去快速把原片转成想要的格式。这样这是对客户比较大的一个挑战，在资源的弹性交付，在运维的复杂性，在业务的快速上线等等几个维度都会面临一些挑战。
目前函数计算通过这种 Serverless 化的弹性交付能力，通过这种资源的免运维，能够非常好的去解决客户的这些问题。
我总结了大概两种客户最常用的两种落地方案，一种是音视频转码，另外一种是在直播的推流转推、内容审核、直播流的录制等。这两个是目前最长用的在音视频系统处理的方案。
借助于 Serverless 这个技术，目前函数计算可以做到在整个系统的可用性达到99.99%。同时函数计算这种弹性资源交付的能力，能够达到单租户1秒钟直接交付1000+以上的实力。我们有实际的客户在使用过程当中能够做到在直播录制这个场景下，直接在一秒钟交付两千多个实例，然后去开启他的直播录制。同样的因为它的弹性能力我们是可控的，所以我们可以做到在比如说720P的转码或者1080P的转码我们能做到5倍速甚至10倍速以上的性能。
另外的话函数计算也跟达摩院做了一个深度的合作。用户可以选择达摩院的一个视频增强的算法。包括我们现在也开放出来 GPU 用户也可以选择 GPU 挂载的方式来提升它的转化性能和质量。那么以函数计算这种方式去构建音视频处理系统，对比这种传统的云主机自建以及 pass 化的方案，它有哪些优劣势呢？
我们可以从投入的成本，运维的复杂度，以及上线的周期等等几个维度来做一个对比。函数计算构建音视频处理系统，可以做到在资源成本和弹性方面达到最优。它对比这种 pass 化的方案，它又有哪些优势呢？
Pass 化的方案，它虽然在对接起来是最简单的，但是它的弹性这一块和性能这一块是一个黑盒，函数计算更好的满足了这种自建算法再加上弹性可控的诉求。
目前行业计算的构建的音视频处理系统，可以在整个商业周期上缩短50%以上，以及在成本上节省20%以上，这还是相对比较保守的估计。在整个性能上可以提升50%以上。
