作者：廖祥俐
策劃：望宸
稽核&校對：瀟航
編輯&排版：雯燕

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

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

1. 現狀：音影片技術在網易雲音樂的應用情況，引入 Serverless 技術之前遇到的問題；

2. 選型：調研 Serverless 方案時的考慮點；

3. 落地和展望：我們進行了哪些改造，最終的落地效果和未來規劃。

# 現狀

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

![1.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/3e7a36cba2374a85a5210b5f4de0ad0c~tplv-k3u1fbpfcp-zoom-1.image)

1. 預設情況下，使用者聽到的是我們採用音訊轉碼演算法預先轉好的標準化位元速率的音質，但由於流量有限或自身對於音質更高的要求，想要切換到差一些或更好的音質。

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

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

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

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

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

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

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

![2.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/9d60c22d3b374dda81d40e34a34f7ce8~tplv-k3u1fbpfcp-zoom-1.image)

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

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

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

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

![3.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/6fde959b9354479197847ccf7c47be41~tplv-k3u1fbpfcp-zoom-1.image)

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

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

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

![4.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/3f130f2c06eb491bb9e2f75540ae8221~tplv-k3u1fbpfcp-zoom-1.image)

透過訊息佇列去解耦了執行單元與其他系統的互動，在執行單元內部，我們透過控制訊息佇列的併發度去適配不同併發效能的演算法，儘量控制執行單元的主要工作僅用於演算法的計算，這樣最終在系統擴容的時候，我們能夠做到最小粒度的擴容。

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

# 選型

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

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

![5.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/2fa58a2bc6e543fcb43e8d77f9d5f7ac~tplv-k3u1fbpfcp-zoom-1.image)

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

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

- 成本：包含兩方面，改造的實施成本和計算資源的成本。前者可以結合具體方案進行評估，得到所需投入的人日，此外，改造後在未來的靈活擴充性，也是我們需要考慮的點。後者可以透過雲廠商官方給出的費用計算模型，結合我們的執行資料，估算出來。我們在成本方面的選型關鍵是，在改造成本能夠接受的情況下，未來的 IT 成本不會大額的增加。

- 執行環境的支援：前面提到過，雲音樂的執行環境比較多樣化，是以映象交付的方式進行部署的；團隊內部都有相對完善的 CICD 支援，這個要求未來的升級、部署事務，例如規格配置上，是否能夠簡化開發人員對於機器等的關注。我們希望在改造後，不需要在此類事項上花費過多的時間和精力，更多的關注演算法執行本身。

- 彈效能力：除了雲廠商提供的計算資源池的規模，我們還會關注彈性算力的啟動速度，是否能夠對固定場景進行例項預留，以及是否提供更符合業務訴求的靈活彈效能力，以更好的支援業務的發展。

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

# 落地

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

![6.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/dce5840f392349f89898486a8125422b~tplv-k3u1fbpfcp-zoom-1.image)

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

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

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

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

![7.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/8816e1d3c9d6402cbee824ed9e4f68a2~tplv-k3u1fbpfcp-zoom-1.image)

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

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

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

瞭解更多相關資訊，請掃描下方二維碼或搜尋微訊號（AlibabaCloud888）新增雲原生小助手！獲取更多相關資訊！

![二維碼.png](https://p3-juejin.byteimg.com/tos-cn-i-k3u1fbpfcp/8561051ea15146669e13d3b773996796~tplv-k3u1fbpfcp-zoom-1.image)

網易雲音樂音影片演算法的 Serverless 探索之路

相關文章