使用.NET Core搭建分布式音頻效果處理服務（一）需求、問題和解決方案的幾個坑

最近公司需要在伺服器上實作兩個音頻的合成及效果處理。

哇，乍一聽功能很簡單吧，就是将兩個音頻疊加，随便一個媒體處理軟體幾秒鐘即可完成，但這僅僅隻是針對單使用者而言而已。其次，本來這種服務原本就不應該在伺服器上面實作，為何？

1. 流媒體處理是相當耗費伺服器資源的，包括IO，CPU，bandwidth等等。
2. 伺服器資源并不是毫無限制的，比如實體數量就會涉及到整體成本。
3. 如果是一台機器維護到也簡單，但實際運作場景遠不止這麼簡單。
4. 處理這類流媒體，時間上絕不是用毫秒級的方式來響應，這樣就會衍生出更多的問題，比如一些莫名其妙的運作時錯誤。

如果在C/S模式下，完全可以采用client原生的在客戶機上面進行流資料媒體處理，再将處理後的檔案上傳到指定的雲存儲位置（比如阿裡雲的OSS），這樣對于伺服器來說0壓力，隻是做個中間資料傳遞即可。一切就那麼簡單，不存在大并發問題，不存在擴充性問題，可兩個關鍵問題又來了：

1. 如果所有互動裝置都使用統一的流媒體處理庫進行處理（比如ffmpeg），那麼，最終得到的效果檔案将必定是一樣的，可目前關鍵是目前IOS小組和ANDROID小組參數一樣，得到的效果卻完全不一樣，IOS上有很明顯的電流聲和雜音（如果有高手指點一下，鄙人非常感謝，嘿嘿）。
2. 在原生的軟體（APP）上調用ffmpeg是可行的，在網頁上怎麼辦？畢竟目前網頁也可以實作錄音的功能，比如微信API、 Recorder.js ，使用者需要将自己的錄制的聲音進行一些效果處理的時候，那麼網頁将是無能為力的。

如上的最終效果不一緻、平台功能沒有100%覆寫問題，将又是這個産品實際的最大隐患，一緻性和通用性并不隻是針對技術要求，使用者在産品的回報上同樣也需要一緻性和通用性。是以，這樣就需要伺服器來統一處理這類功能需求和問題，如下幾點優勢（僅針對這個項目而言）：

1. 一緻性。不論在哪種裝置和作業系統（現在誰沒有幾台的智能裝置啊），通過伺服器統一回報回來的音頻檔案試聽效果均是一樣的。
2. 通用性。隻需要統一的一個接口調用，不論PC，APP，H5網頁，甚至包括嵌入式裝置，隻要能通信，那使用者就能實作自己想要的音頻合成效果。
3. 不發燒。還有一個就是使用者的可移動裝置不用在因為處理某個音頻而發燒燙手了，喝喝（對于部分低配的ANDROID手機）。

純粹的點對點C/S模式，這裡就不畫圖了，下一節我們開始慢慢的畫餅o(∩_∩)o 哈哈。

感謝閱讀