從公有雲方案轉向谷歌開源Knative，網易雲音樂Severless演進實踐

背景

雲主機時代，資源焦慮幾乎普遍存在。突增的巨大任務量、短時間突然調集使用大量的計算資源等類型的業務需求越來越多，企業不願為了應對短暫的流量高峰買本地資源，對服務和擴縮容進行解耦，并接管過自動擴縮容任務的 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 平台（開源位址：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 能否借助當下企業對降本增效需求的契機得到進一步發展，我們也将拭目以待。