最近公司需要在伺服器上實現兩個音頻的合成及效果處理。 哇，乍一聽功能很簡單吧，就是將兩個音頻疊加，隨便一個媒體處理軟體幾秒鐘即可完成，但這僅僅只是針對單用戶而言而已。其次，本來這種服務原本就不應該在伺服器上面實現，為何？ 流媒體處理是相當耗費伺服器資源的，包括IO，CPU，bandwidth等等。 ...
最近公司需要在伺服器上實現兩個音頻的合成及效果處理。
哇，乍一聽功能很簡單吧，就是將兩個音頻疊加，隨便一個媒體處理軟體幾秒鐘即可完成，但這僅僅只是針對單用戶而言而已。其次，本來這種服務原本就不應該在伺服器上面實現，為何？
- 流媒體處理是相當耗費伺服器資源的，包括IO，CPU，bandwidth等等。
- 伺服器資源並不是毫無限制的，比如物理數量就會涉及到整體成本。
- 如果是一臺機器維護到也簡單，但實際運行場景遠不止這麼簡單。
- 處理這類流媒體，時間上絕不是用毫秒級的方式來響應，這樣就會衍生出更多的問題，比如一些莫名其妙的運行時錯誤。
如果在C/S模式下，完全可以採用client原生的在客戶機上面進行流數據媒體處理，再將處理後的文件上傳到指定的雲存儲位置（比如阿裡雲的OSS），這樣對於伺服器來說0壓力，只是做個中間數據傳遞即可。一切就那麼簡單，不存在大併發問題，不存在擴展性問題，可兩個關鍵問題又來了：
- 如果所有交互設備都使用統一的流媒體處理庫進行處理（比如ffmpeg），那麼，最終得到的效果文件將必定是一樣的，可目前關鍵是目前IOS小組和ANDROID小組參數一樣，得到的效果卻完全不一樣，IOS上有很明顯的電流聲和雜音（如果有高手指點一下，鄙人非常感謝，嘿嘿）。
- 在原生的軟體（APP）上調用ffmpeg是可行的，在網頁上怎麼辦？畢竟目前網頁也可以實現錄音的功能，比如微信API、Recorder.js，用戶需要將自己的錄製的聲音進行一些效果處理的時候，那麼網頁將是無能為力的。
如上的最終效果不一致、平臺功能沒有100%覆蓋問題，將又是這個產品實際的最大隱患，一致性和通用性並不只是針對技術要求，用戶在產品的反饋上同樣也需要一致性和通用性。因此，這樣就需要伺服器來統一處理這類功能需求和問題，如下幾點優勢（僅針對這個項目而言）：
- 一致性。不論在哪種設備和操作系統（現在誰沒有幾台的智能設備啊），通過伺服器統一反饋回來的音頻文件試聽效果均是一樣的。
- 通用性。只需要統一的一個介面調用，不論PC，APP，H5網頁，甚至包括嵌入式設備，只要能通信，那用戶就能實現自己想要的音頻合成效果。
- 不發燒。還有一個就是用戶的可移動設備不用在因為處理某個音頻而發燒燙手了，喝喝（對於部分低配的ANDROID手機）。
純粹的點對點C/S模式，這裡就不畫圖了，下一節我們開始慢慢的畫餅o(∩_∩)o 哈哈。
感謝閱讀
