基於多服務商的直播方案

做者：貝聊 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. 有新的業務需求須要實現兩套，分別對接七牛雲和騰訊雲。