簡介： 基於音視訊算法服務化的經驗，網易雲音樂曲庫團隊與音視訊算法團隊一起協作，一起共建了網易雲音樂音視訊算法處理平臺，為整個雲音樂提供統一的音視訊算法處理平臺。本文將分享我們如何通過 Serverless 技術去優化我們整個音視訊處理平臺。

作者 | 廖祥俐

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

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

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

現狀

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

1）默認情況下，用戶聽到的是我們採用音頻轉碼算法預先轉好的標準化碼率的音質，但由於流量有限或自身對於音質更高的要求，想要切換到差一些或更好的音質。

2）用戶可以使用雲音樂 APP 裡面的聽歌識曲功能去識別環境中的音樂，這背後使用到了音頻指紋提取及識別技術。

3）在平臺上的一些 VIP 歌曲，為了能給用戶更好的試聽體驗，我們會做副歌檢測，讓試聽直接定位到高潮片段，這裡用到了副歌檢測算法。

4）在雲音樂的 K 歌場景裡，我們需要對音頻的音高進行展示並輔助打分，這裡我們用到了音高生成算法去完善K歌的基礎數據。

5）為了更好的滿足雲音樂平臺上，小語種用戶的聽歌體驗，我們為日語、粵語等提供了音譯歌詞，這裡用到了自動羅馬音的算法。

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

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

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

1） 算法的執行時間長：執行時間往往與原始音頻的時長成正比，雲音樂很多場景下音頻、視訊的時長 Range 範圍是很大的，基於這個特點，我們在執行單元的設計上，往往都採用異步化的模式。

2）音視訊算法具有多語言特性：雲音樂的算法包括了 C++、Python 等語言，對接環境上下文會帶來極大的困擾，為了解決這個問題，我們採用標準化約定及鏡像交付的方式，解耦各類環境準備的工作，所以後續對於能否支持鏡像部署，會成為我們技術選型的一個重點考察。

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

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

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

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

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

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

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

選型

隨著業務場景和算法龐雜度的增加，雖然通過了很多方式去簡化了內部業務場景、算法等的對接，但越來越多夾雜存量、增量處理的算法，不同流量的業務場景規模，以及不同業務場景可能會復用同一類算法的，讓我們在處理機器資源的時間，遠比我們在開發的時間更多。

這個也促使我們開始去考慮更多的方式方法，去解決我們遇到的問題，最直接的有三個痛點。

第一個是存量和增量的差異變大，和新算法落地的增多，我們花在處理存量和增量的資源協調時間越來越多；其次是隨著算法龐雜度的增高，我們在申請/採購機器的時候，需要關註機器的整體規格、利用率等；最後是，我們希望存量的處理能夠加快，在處理存量的時候有足夠大的資源，在海量音視訊數據處理時候，能夠壓縮存量與增量不一致的時間。總的來講，我們希望能夠有足夠大規模的彈性資源，讓音視訊算法服務不用再多去關註機器管理。

然而，實際改造不僅僅是關註最終服務能力，還需要綜合考慮投入的 ROI。具體來看：

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

這些其實都符合 Serverless 的定義，構建和運行應用程序都不需要對服務器進行管理、彈性能力出眾等。綜合以上的考量，我們選擇了公有雲函數計算的方式，它能直觀的映射我們目前的計算執行過程，同時也能滿足後續想嘗試通過 Schema 進行算法的編排。下面我會重點分享下引入函數計算 FC 的過程。

落地

我們在一周內快速試用了函數計算 FC，然而一個完整的、高可靠的架構，需要考慮更多的因素。因此我們的改造重點是隻把算力任務通過函數計算 FC 彈出去，系統在整體的對外輸入輸出上仍保持不變，並且系統擁有流量控制能力，能夠在遇到特殊情況時，降級到私有雲進行處理，保障系統的高可靠性，具體的架構改造如下圖所示：

雲音樂的開發環境與函數計算的適配是改造的重點，我們重點針對部署、監控和混合雲支持進行了改造。部署上，我們充分應用了函數計算在 CICD 上的支持及鏡像部署的支持，實現了鏡像的自動化拉取；在監控設計上，一方面利用雲上的監控報警功能，另一方面把它轉化為我們內部已有監控系統的參數，讓整體的開發運維處理能夠維持一致性，最後是從代碼設計上，考慮能夠兼容混合雲部署的實現，最終完成了我們音視訊處理平臺的 Serverless 改造。

從函數計算的計費策略上，我們可以看到，有三大因素在影響最終費用，記憶體的規格、觸發計算的次數，以及公網出流量的費用。直接從技術架構上看，大家可能更關註前兩者，實際上流量費用也是一筆不小的費用，這個對於我們來講，也是關註的一個重點。

我們根據函數計算的費用特性，在存儲體系仍然使用網易私有雲的情況下，在第一階段，首先選取的是公網出流量比較少的音視訊算法。關於公網出流量比較少，我舉個例子，對音頻進行特征提取，如一個音頻進去，提取一個 256 維的數組，獲取的結果就只是一個 256 維數組，它是遠遠小於音頻自身的流量，因此出公網的流量費用會比較少。

在引入函數計算的第一階段，特征提取類的算法得到了 10 倍速的提升；稀疏類的算法，可以理解為日常使用率很低的算法，在成本上得到了極大的節約。除此之外，通過函數計算的鏡像緩存加速能力，優化了我們節點的啟動速度，讓所有的服務拉起可以在秒級完成。這些工作，降低了算法運維處理中大量的運維成本，讓我們能夠更聚焦關註在算法及業務自身。

上方右邊這幅圖是雲音樂其中一個算法的運行範例，可以看到，我們在彈性上的變化範圍是非常大的，而函數計算很好的滿足了這個訴求。

未來，我們希望能夠更進一步通過 Serverless 技術去解放我們在運維上的人力投入，並將從存儲長進行嘗試，進而解決公網出流量的問題，讓更多場景的音視訊算法可以自然的實現；其次，隨著算法龐雜度的進一步提升，使得計算資源上使用的更加龐雜，希望通過 GPU 實例來優化計算過程；最後，在雲音樂的業務場景中，實時音視訊處理的場景也越來越多，同樣的，它也有明顯的高峰、低谷的波動特點，我們希望沉淀更多的 Serverless 服務使用經驗，最終助力雲音樂實時音視訊技術的發展。

作者：廖祥俐，2015年加入網易雲音樂，雲音樂曲庫研發負責人。

本文為阿裡雲原創內容，未經允許不得轉載。