共计 6447 个字符，预计需要花费 17 分钟才能阅读完成。
本文作者：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 构建事件处理框架。
<img src=”https://p6.music.126.net/obj/wonDlsKUwrLClGjCm8Kx/25949541187/6712/7b66/ddce/748dd98db07fc18dbb2f5edb65818e66.jpg” alt=”pic” style=”zoom: 50%;” />
在如何进行技术选型上，网易数帆云原生架构师闫东晓示意次要有三点须要思考。第一，产品肯定要可能满足业务场景和利用场景需要；第二，关注产品背地的反对状况，比方 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 平台（开源地址：https://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！
