網易雲音樂音視訊算法的 Serverless 探索之路

作者：廖祥俐

策劃：望宸

稽核&校對：潇航

編輯&排版：雯燕

網易雲音樂最初的音視訊技術大多都應用在曲庫的資料處理上，基于音視訊算法服務化的經驗，雲音樂曲庫團隊與音視訊算法團隊一起協作，一起共建了網易雲音樂音視訊算法處理平台，為整個雲音樂提供統一的音視訊算法處理平台。本文将分享我們如何通過 Serverless 技術去優化我們整個音視訊處理平台。

本文将從三個部分向大家介紹：

1. 現狀：音視訊技術在網易雲音樂的應用情況，引入 Serverless 技術之前遇到的問題；
2. 選型：調研 Serverless 方案時的考慮點；
3. 落地和展望：我們進行了哪些改造，最終的落地效果和未來規劃。

   現狀

   作為一家以音樂為主體的公司，音視訊技術被廣泛應用于網易雲音樂的衆多業務場景裡，為了更形象的讓大家感受到，這裡列舉了 5 個常見的場景：

   

4. 預設情況下，使用者聽到的是我們采用音頻轉碼算法預先轉好的标準化碼率的音質，但由于流量有限或自身對于音質更高的要求，想要切換到差一些或更好的音質。
5. 使用者可以使用雲音樂 APP 裡面的聽歌識曲功能去識别環境中的音樂，這背後使用到了音頻指紋提取及識别技術。
6. 在平台上的一些 VIP 歌曲，為了能給使用者更好的試聽體驗，我們會做副歌檢測，讓試聽直接定位到高潮片段，這裡用到了副歌檢測算法。
7. 在雲音樂的 K 歌場景裡，我們需要對音頻的音高進行展示并輔助打分，這裡我們用到了音高生成算法去完善 K 歌的基礎資料。
8. 為了更好的滿足雲音樂平台上，小語種使用者的聽歌體驗，我們為日語、粵語等提供了音譯歌詞，這裡用到了自動羅馬音的算法。

從上面的場景可以看到，音視訊技術被廣泛應用于雲音樂的不同場景裡面，發揮了重要的作用。

從我們的音視訊技術做一個簡單劃分，可以分為三大類：分析了解、加工處理、創作生産，這些一部分是以端上 SDK 的方式，在端上進行處理；而更多的部分，是通過算法工程化的方式，采用後端叢集部署管理，以服務的形式提供通用的音視訊能力，而這部分是我們今天分享的重點。

音視訊算法的服務化部署工作中，需要了解很多相關音視訊算法的特點，如部署環境、執行時間、能否支援并發處理等，随着我們落地算法的增加，我們總結了以下規律：

1. 算法的執行時間長：執行時間往往與原始音頻的時長成正比，雲音樂很多場景下音頻、視訊的時長 Range 範圍是很大的，基于這個特點，我們在執行單元的設計上，往往都采用異步化的模式。
2. 音視訊算法具有多語言特性：雲音樂的算法包括了 C++、Python 等語言，對接環境上下文會帶來極大的困擾，為了解決這個問題，我們采用标準化約定及鏡像傳遞的方式，解耦各類環境準備的工作，是以後續對于能否支援鏡像部署，會成為我們技術選型的一個重點考察。

3. 彈性的訴求正在變大：雲音樂平台的歌曲，從我入職時候的 500w，到現在線上超過 6000w，增量 vs 存量的 gap 越來越大，當我們快速實施一個算法時，不僅要考慮增量的接入，更要考慮存量的快速處理，是以在系統設計中，會單獨把執行單元的最小粒度剝離出來，便于快速的擴容。

   基于我們對工程化的了解，及音視訊算法處理的特點，雲音樂的音視訊處理平台的整體架構如下：

   

   對于不同音視訊算法處理的共同部分，我們做了統一的設計，包括算法處理的可視化、監控、快速試用和處理資料統計等，對于資源的配置設定也設計了統一可配置的管理模式，讓整個系統的公共部分可以盡可能抽象并複用。

   整個音視訊算法處理平台最關鍵的，也是今天的分享重點，是執行單元的互動與設計。雲音樂通過統一的對接标準、采用鏡像傳遞的方式，解決了很多對接和部署上的效率問題。針對資源的使用，由于我們不斷有新算法、存量/增量服務的存在，在上雲之前，用的是内部私有雲雲主機申請/回收、内容容器化的方式。

   為了更好的描述雲音樂執行單元的運作流程，我們将它更細化下，如下圖所示：

   

   通過消息隊列去解耦了執行單元與其他系統的互動，在執行單元内部，我們通過控制消息隊列的并發度去适配不同并發性能的算法，盡量控制執行單元的主要工作僅用于算法的計算，這樣最終在系統擴容的時候，我們能夠做到最小粒度的擴容。

   在這個模式下，我們落地了 60 多種音視訊算法，尤其是在近一年來，服務化的算法占到了一半，這些算法向雲音樂 100+ 的業務場景提供了服務能力。但更複雜的算法、更多的業務場景，對我們的服務化效率、運維部署和彈性能力都提出了更高的要求，在我們上雲之前，在内部已經用到了 1000 台以上不同規格的雲主機及實體機。

   選型

   • 成本：包含兩方面，改造的實施成本和計算資源的成本。前者可以結合具體方案進行評估，得到所需投入的人日，此外，改造後在未來的靈活拓展性，也是我們需要考慮的點。後者可以通過雲廠商官方給出的費用計算模型，結合我們的執行資料，估算出來。我們在成本方面的選型關鍵是，在改造成本能夠接受的情況下，未來的 IT 成本不會大額的增加。
   • 運作環境的支援：前面提到過，雲音樂的運作環境比較多樣化，是以鏡像傳遞的方式進行部署的；團隊内部都有相對完善的 CICD 支援，這個要求未來的更新、部署事務，例如規格配置上，是否能夠簡化開發人員對于機器等的關注。我們希望在改造後，不需要在此類事項上花費過多的時間和精力，更多的關注算法執行本身。
   • 彈性能力：除了雲廠商提供的計算資源池的規模，我們還會關注彈性算力的啟動速度，是否能夠對固定場景進行執行個體預留，以及是否提供更符合業務訴求的靈活彈性能力，以更好的支援業務的發展。

落地