基於多服務商的直播方案

作者：貝聊 JAVA工程師 葉志偉

程序員們的工作大部分都是被動實現產品經理需求，這裡分享一次由程序員主動推動並實現需求的過程。

1. 需求背景

看寶寶與明日之星是貝聊的視頻直播產品，目前只是使用七牛一家的直播雲服務。基本業務是通過攝像頭設備或老師的手機直播，推流到七牛，家長通過H5的頁面觀看。業務流程圖如下：

可以明顯發現：貝聊服務端和客戶端都完全依賴七牛雲的服務，萬一七牛雲出現故障，整個視頻直播產品就癱瘓了！於是我們的需求就誕生了：接入另一家直播雲服務商，提高服務可用性。如此一來，既可做為容災，也可做流量切換。

2. 直播雲服務商選擇

經過調研，我們鎖定的備選服務商有騰訊雲、阿里雲、金山雲、網易雲。新的直播雲服務商選擇，不能拍腦袋決定。需要考慮各服務商的優缺點、成本以及是否能滿足我們的功能要求等。總結主要有以下幾點：

• 客戶端的限制：我們的貝聊老師版APP，安卓系統要求最低是版本4.0，而阿里雲和網易雲要求最低版本是4.3
• 現有功能點的限制：產品已經上線，新的服務商應與七牛的功能相似，包括推拉流、鑒權、定時截圖、狀態回調通知、保存回放等
• 成本的問題：騰訊雲成本最高，阿里雲和金山雲相對較低

由於客戶端的限制，備選服務商基本鎖定在騰訊雲和金山雲。既然是作為備用，成本就是次要因素了，穩定可靠才是我們的核心關注點。因此，我們最終選擇了騰訊雲作為備選直播服務商。

3. 實現過程

接入一家新的直播雲服務商，業務流程圖調整如下：

3.1 業務變化

1. 後台增加操作功能，可切換服務商和客戶端使用的SDK。目前只有人工切換服務商，後續可以加入系統檢測報警機制，並自動進行切換。但若完全靠系統自動切換，會有誤報風險。
2. 直播是以節目為單位，在創建節目時增加一個欄位標識使用哪個服務商。後續一切操作，例如：生成推流地址、拉流地址、截圖、保存回放都調用這個服務商的介面。
3. 推流地址是伺服器生成並簽名後返回給客戶端，客戶端無需關心使用的服務商，只需關心使用哪個SDK。優先使用騰訊雲SDK，由於無法保證其穩定性，所以前期同時接入七牛雲和騰訊雲的SDK，由後台配置各自使用比例。
4. 增加對騰訊雲回調通知的處理
5. 包括推流狀態回調、截圖回調、生成錄製文件回調。一個節目有一個流空間，七牛雲和騰訊雲的流空間是全局唯一的，所以不管是七牛雲還是騰訊雲的每個回調都能準確的找到對應的節目。
6. 生成回放的方式完全不同。七牛雲是在直播結束時調用介面生成的，而騰訊雲是在推流地址後加參數&record=mp4&record_interval=5400，然後接收回調。騰訊雲還可以配置全局的推流自動保存。
7. 騰訊雲區分生產環境和測試環境。騰訊雲的回調通知是全局配置的，無法區分環境，使用多個賬號又增加成本，於是把回調通知都配置成生產環境的，調用非同步處理介面時把taskId存到資料庫，生產環境找不到則轉發到測試環境。

3.2 代碼結構變化

最初只接入一家服務商，代碼結構比較簡單。如今，為了避免有重複代碼，過多使用if、else，所以使用了簡單工廠模式。業務代碼統一調用工廠類VideoTV3rdLiveServiceFactory，七牛雲和騰訊雲各寫了一套業務代碼，分別是VideoTVQcloudLiveService和VideoTVQiniuLiveService，實現生成推流地址、獲取拉流地址、保存回放等與業務相關的邏輯代碼。QcloudService是對騰訊雲API和SDK的封裝，PiliService和StorageService是對七牛雲SDK的封裝。

4. 後續工作

1. 實現系統故障檢測報警。系統定時嘗試推流，如果失敗累計達到n次後發送郵件、簡訊報警。
2. 有新的業務需求需要實現兩套，分別對接七牛雲和騰訊雲。

推薦閱讀：