本文作者：ydx

背景

云主机年代，资源焦虑简直普遍存在。突增的巨大使命量、短时间忽然集结运用许多的核算资源等类型的事务需求越来越多，企业不愿为了应对时间短的流量高峰买本地资源，对服务和扩缩容进行解耦，并接管过主动扩缩容使命的 Serverless 进入群众视野。

Serverless 自带“降本增效”基因，特色之一便是能够缩容到零之后再按资源运用状况收费，这天然吸引了许多企业运用，网易云音乐便是其间之一。

最早，网易云音乐首要运用云厂商的 FaaS 产品。跟着 Serverless 社区的发展，2020 年，网易云音乐开始重视到 Google 开源的 Knative 项目，到了 2021 年 5 月，团队决议优先运用内部的私有云资源，在满意事务的异步处理事情以及弹性扩缩容需求的条件下，经过在线和离线服务的混合布置，提高体系资源运用率，一起完结降本增效目的。

所以，在做了简单的 POC 测验并与事务沟通后，网易云音乐便协同网易数帆云原生团队面向音视频处理，打造了依据 Knative 的 Serverless 处理方案。

怎么做技能选型

网易云音乐每天都有数十万的歌曲入库，曲库团队则需求对这部分歌曲做准实时的加工处理、理解剖析（包含歌曲转码、副歌辨认、特征剖析等），相关处理结果用于歌曲播映、VIP 歌曲试听等事务场景。这类事务的特色便是弹性特别大，使命时多时少，多的时候甚至要对许多存量歌曲数据进行从头核算。这就对资源交给方法提出了新的要求。

按照网易云音乐在云主机年代的运用经历，传统的资源交给方法首要存在以下几个问题：

• 弹性功率低下：大型活动事务扩容时，各个角色如运用运维、机房等深度耦合，进行一次大型活动需求十分长的预备时间。

• 核算焦虑：由于规划问题，机房核算资源没办法完结在活动期间的快速资源弹性需求，因而常常需求预备许多搁置资源。

• 运维繁琐：扩容变更时，许多是以工单、人工化为主的低效过程，无论功率仍是质量都不尽如人意。

• 本钱问题：总体 CPU 等资源运用率不高，小于 20%，缺乏主动化的管理和调度才能，资源无法得到充分运用。

• 安稳性：运用产生故障后，无法主动从头拉起或从头调度，中心事务的服务质量很难得到保障。

尽管依据 Kubernetes 以及生态里的许多创新云原生处理方案，上述扎手问题得到了必定程度的处理，但 Serverless 的处理方案相对来说更加高效易用。Serverless 向事务供给了语言无关、结构无关的研制方式，经过主动化 Metric、主动扩缩容等手段让事务聚集事务逻辑，无需重视周边与资源扩缩、没有服务器管理，降低了程序生命周期中的许多运维本钱。

当前，Serverless 大概有三个技能方向：Serverless 容器服务、Serverless 运用保管和函数核算（FaaS）。

运用 Serverless 容器服务的用户不需求保护 Kubernetes 集群的核算节点，体系依据服务运用的 pod 数量进行计费，但 Serverless 容器服务并不能供给完备的周边配套设备；Serverless 运用保管则会包含运用生命周期的管理、CI/CD、发布战略，蓝绿或许灰度发布功用等，用户只需将服务布置后就能坐享运用保管所供给的根底才能；函数核算的笼统程度更高。关于 Python 等解说类语言，开发者运用 FasS 将代码片段上传后，函数核算的底层便可快速将服务对外布置，然后完结对外服务。

在云原生团队看来，Serverless 运用保管或 FaaS 渠道相对来说是更好的挑选，由于事务不只需求弹性弹性功用，还要处理 CI/CD、发布战略、音讯引擎等问题，做更好的开发封装。只要涵盖了这些周边配套服务，才能将开发的心智担负降至最低。方向确认后，详细怎样做呢？

容器镜像需求依据编程语言的定制化编译和构建，然后生成二进制的文件，最终再经过 Dockerfile 将其构建成容器。可是，曲库团队内部有多种语言所开发的算法，很难用通用的流水线进行容器镜像构建。因而，曲库团队内部只要求底层 Serverless 渠道或 FaaS 渠道能够承受 Dockerfile 即可，详细 Dockerfile 怎样写则由其内部自行消化。

因而，云原生团队的使命便是将曲库团队上传的 Dockerfile 进行镜像构造。云原生团队为此进行了一次全面调研，内容包含音讯引擎对上下游解耦及弹性扩容的需求、相关开源软件（Knative、OpenFaas、Fission、Nuclio 等）与需求的匹配度比照，最终确定依据 Knative Serving 做动态扩缩容、依据 Knative Eventing 构建事情处理结构。

在怎么进行技能选型上，网易数帆云原生架构师闫东晓表示首要有三点需求考虑。第一，产品必定要能够满意事务场景和运用场景需求；第二，重视产品背面的支撑状况，比方 Knative 有谷歌、IBM 等大企业加持，OpenShift 背面有 RedHat 支撑；第三，产品具有易用性，通常易用性是落地时团队要协助事务处理的问题，但假如项目足够安稳，就不需求改动底层结构。

在很多开源软件中，Knative 的扩展性较好、能够挑选音讯引擎，而且生产和消费的客户端能够以插件的方式嵌入到 Serverless 体系中。因而，云原生团队最终挑选依据 Knative 对每个实例或创建的 Knative Service（类似 Kubernetes 的 Deployment）进行动态扩缩容。

其时的 Knative 本身还处于快速迭代阶段，没有安稳的版别，网易云音乐运用的仍是 0.20、0.21 版别。

2021 年上云之后，网易云音乐开始运用事情驱动架构。这次搬迁期间，云原生团队还在 Knative Eventing 事情结构中内嵌了一个插件（Knative 之中包含 Knative Serving 和 Knative Eventing 两个项目），将音讯引擎 Kafka 也集成到了 Serverless 渠道之中。事务只需求在 8080 端口接收经过 Knative Eventing 事情结构转发的恳求，并经过 Kafka 触发音讯即可完结事情驱动。

详细来讲，事务将支撑 Knative Eventing 格局的事情恳求经过露出的 URL 发送到接口，再由接口将音讯转发到音讯引擎，体系层面在监听到事情触发后会消费 Kafka 的音讯，最终再将其转发给后端算法进行处理。

自此，网易云音乐拥有了一个异步事情处理结构，在偏向离线的场景中能够慢慢地消费音讯，然后确保私有云底层的有限资源能得到合理、充分地运用。

这是一种通用技能，要求发动的服务不依靠私有云节点，不能在宿主机上的某些路径下存在文件等依靠方式，不然会无法弹出导致发动失利。但假如一切依靠均在容器镜像内部，或许能够经过运转时动态地恳求依靠方获取信息，那么就能够运用这种弹性才能。

搬迁后，需求处理哪些问题？

冷发动是 Serverless 运用时被重点考量的点。影响发动速度的因素有许多，比方，容器镜像大小不同，pod 的发动速度也不同。部分厂商经过预先发动部分 pod 的方法来处理冷发动问题，但网易云音乐没有这么做。云原生团队运用了更通用的处理方案，比方 Dockerfile 选用多阶段构建、P2P 加快容器镜像拉取速度等。

网易云音乐的运用场景偏离线、非实时，因而对负载均衡和并发操控的需求比较高。音视频算法每个 pod 可处理的并发度很低，理想状况是上游在下发恳求时操控并发数量，确保每个 pod 都在处理自己能处理的并发恳求。可是，数据链路上会有数据不均衡的状况，经过行列的恳求会超越 pod 可处理的并发数量上限，然后导致行列堵塞和其他 pod 空闲。

为此，云原生团队调整了 Knative 内部的负载均衡算法战略，从默许的 Round Robin 改为 Least Request，将恳求发给并发处理数最少的 pod，让每个 pod 都有使命。

别的事务对安稳性要求也很高，而事务安稳性首要体现在对上游并发的操控上。事务将服务恳求悉数发送到音讯行列后，假如将音讯悉数分发给底层服务处理，那么将扩容出十分多 pod；假如 pod 与在线运用在同一个 node 上，则势必会影响在线运用的安稳性。因而，除了 Knative 本身所供给的服务外，云原生团队还搜集事务目标并供给监控告警功用，来给事务信心。

经过与事务的需求沟通，云原生团队运用 Serverless 露出出的数据链路目标信息形成定制的可视化看板，其间包含监控告警、扩缩容频率、每个 pod 的负载状况、推送音讯的消费状况等事务根底信息，此外也有 Serverless 内部运维的巡检监控，如 CPU、内存的运用率，消费行列消费延时状况、事务化扩缩容完结等。

当监控作用不达预期时，云原生团队则需求调整或学习其他优化手段做提高。值得注意的是，这些监控目标搜集都是运用的根底 Kubernetes 系列开源产品，并不是 Serverless 独有的。Serverless 是作为整个架构部分的存在，需求与其它产品配合运用。

在调优方面，事务研制能够自行登录容器检查进程信息，也能够经过日志搜集的方法检查。调试方面则运用了云主机年代的长途调试方法，这种方法在容器化年代仍旧可用。

为了完结“最终一公里”的交给，云原生团队在网易开源的云原生运用交给渠道 Horizon 上交给了一个布置模板，曲库团队依据 Horizon 渠道填写数据表单，云原生团队担任模板化实例生成。Horizon 渠道（开源地址：github.com/horizoncd）通… Deployment、Argo Rollout、Knative 等负载，Serverless 渠道则复用了 Horizon 的部分根底才能，进而为事务供给动态扩缩容和事情处理结构才能。

经过结合事务进行探索和迭代，网易云音乐用了一年多的时间依据 Knaitve 构建了相对完善的 Serverless 渠道：

• 多语言的构建方法：包含 Dockerfile 、JAVA、Golang、Node、Python 等。

• 多场景：支撑弹性在线运用和弹性数据处理，支撑同步调用方式和异步调用方式。

• 丰厚的发布战略：支撑蓝绿发布和依据流量的灰度发布，确保事务的无损发布。

• 主动扩缩容：依据事务并发以及 QPS、使命量等完结秒级主动扩缩容。

• 全链路监控：全链路的收集目标、收集日志，主动将数据整合到运用监控。

• 丰厚的触发器：除了支撑 HTTP、还支撑网易内部的 Kafka、Nydus 行列作为 Serverless 触发器进行数据处理。

• 无限容量：经过混合云、混合布置等方法，快速、主动地经过 ECI 等方法弹到阿里云、AWS 等公有云厂商。

落地效益怎么？

“关于企业来说，假如一开始运用的是私有云，那么在既有 IT 本钱的条件下，Serverless 仅仅提高内部资源的运用率。但假如条件是公有云，那么只要能保证容器不依靠于主机环境，那么在处理信息安全、日志、目标监控等问题的条件下，Serverless 是必定可行的。”闫东晓表示。

现在，网易云音乐内部许多运用 Serverless 渠道的场景包含音视频剖析、AI 推理剖析、前端 SSR、弹性日志 ETL 等。Serverlesss 经过与在线事务混合布置的方法，大大提高了机房资源的运用率，峰值时超越了 50%，资源全体占比达到 20% 左右。

网易云音乐的 Node 负载有波峰、波谷之分，云原生团队期望在波峰时段削减 Serverless 的运用，并在清晨 2-8 点左右提高资源运用率，运转 Serverless 的非实时使命。其间，波峰时段首要是内部私有云在线服务，这也是整个 Kubernetes 资源运用率的波峰。

如今，网易云音乐的私有云上现已布置了超越 500 个 Serverless 运用，高峰期会运用 1 万多虚拟中心。从内部 Node 等级的资源运用率来看，有 20% 的 CPU 中心供给了 Serverless 运用运用，经过在线离线混合布置，在不扩容机器增加本钱的状况下，基本满意了事务对底层核算资源的诉求。

网易云音乐还能够做到优先运用自有机房核算资源，直到饱满时再运用公有云上的核算资源，比方将服务弹出到阿里云的 ECI（弹性容器实例）上进行暂时的核算辅佐，并在执行完结后将其缩容，然后彻底处理资源焦虑，大大提高资源交给功率。需求注意的是，这是一种暂时调用，而非将服务固定在私有云和公有云上混合运用。

在接入 Serverless 渠道两年以来，曲库音视频均匀运用资源的 CPU 核数日均匀峰值 5000 核，日均匀谷值 3000 核。一起，一部分算法服务还凭借公有云的 Spot 弹性资源和包月资源，运用竞价方式，持有弹性的 GPU，快速申请、快速释放。云原生团队的调研显示，即使是简单的每天修正副本数，事务对这些弹性扩缩容手段的好感度也十分高。

别的在运维方面，底层运维的本钱并没有由于运用 Serverless 而增加，运维人员的实际操作量削减，将精力更多放在了 Kubernetes 的资源是否能满意事务需求上。

不过，闫东晓提醒道，关于事务研制而言，云原生团队能够将同一类的东西链封装得更安稳、运用更简单，这时 Serverless 运用功率较高，可是关于非同一类东西链，如算法等无法笼统出 CI 流水线的，收益就比较有限。

要不要用 Serverless

从云厂商产品为主到依据开源产品二次开发，网易云音乐的 Serverless 架构尽管更加贴合内部运用场景，但也需求花精力紧跟社区迭代。闫东晓表示，Serverless 也非“银弹”，本身自带如冷发动方面发动慢、销毁时造成客户端反常、对在线类服务不太能友爱等问题。别的，在既有本钱的状况下，固定副本数要比弹性扩缩容要好。

关于想要接入 Serverless 的企业，闫东晓建议能够从降本增效的视点，或许自有机房或私有云的体系资源运用率视点，看是否有偏离线的核算密集型事务。“一些离线运用往往会在短时间内需求许多的资源，这种需求往往也是一次性的。此时，能够考虑运用 Serverless 提高体系运用率。”

关于运用公有云的企业，假如直接将一切服务悉数搬迁到 Serverless 架构上，则更需求考虑各种危险，比方扩缩容过程中的冷发动问题、服务启停是否会影响事务、缩容时 pod 的销毁是否会一起关闭未处理完结的用户恳求、扩容时 pod 创建是否够快、是否会导致扩容时间内的恳求高延迟等。

企业假如考虑运用云厂商产品，闫东晓表示需求了解云厂商的技能是否关闭、是否跟随社区前进，不然之后做厂商切换、产品切换时都会比较麻烦。特别假如云厂商的 Serverless 产品在底层没有统一标准，那么滑润搬迁必然会带来本钱问题。

假如内部仅仅将固定副本数的普通云主机搬迁至 Kubernetes，那么关于封装流水线和接口的方法，事务层感知不到底层上云前后的差别，也不需求太多知识。但假如是运用微服务、挑选本身技能栈的状况，那么运用方需求能供给 Dockerfile、自行将容器封装运转，这就需求具有容器、Kubernetes 方面的知识，不然用起来会感到困惑。

结束语

网易云音乐的 Serverless 运用还在继续，比方网易云音乐考虑在事情结构中引入 RocketMQ、调度方面会引入守时并发操控，以及充分运用硬件在波谷时段的资源等。总的来说，网易云音乐 Serverless 的落地仍是环绕“降本增效”进行更细化的工作。

当然，关于整个 Serverless 职业来说，未来也还有许多路要走。Serverless 能否凭借当下企业对降本增效需求的契机得到进一步发展，咱们也将拭目以待。

本文发布自网易云音乐技能团队，文章未经授权禁止任何方式的转载。咱们终年接收各类技能岗位，假如你预备换工作，又恰好喜欢云音乐，那就加入咱们 grp.music-fe(at)corp.netease.com！