流媒體：依託於聲網的連麥解決方案

{"type":"doc","content":[{"type":"heading","attrs":{"align":null,"level":1},"content":[{"type":"text","text":"一、背景","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":" 近些年，直播連麥這把火在流媒體領域整整燃燒了6年。從剛開始的簡單探索，到現在的成熟全鏈路方案，不得不說日益增長的激烈競爭，已將讓原本的藍海領域變成了深海互搏。在這樣的大環境下，是否意味着小廠將再也沒有機會追逐流媒體行業風口，以小搏大呢？答案當然不是，感謝多年來的市場驅動帶來的技術思想碰撞，由此誕生了一批專精通訊的技術供應商。使得任何組織都可通過合理的對端方案設計，實現流媒體賦能。而聲網作爲這樣的合作伙伴，則是其中的佼佼者。\n 這就是這篇文章將要談到的內容：基於聲網的對端連麥方案。","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"heading","attrs":{"align":null,"level":1},"content":[{"type":"text","text":"二、宏觀流程","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":" 在我們正式開始前，首先需要做的就是根據連麥的參與者，和連麥的階段，進行階段角色劃分。從整體流程上看，對於任意連麥的兩端來說，自己都是主播端，而另一方都是連麥端。因此，唯一的區別不在於身份上，而在於誰先發起了連麥的請求。這會決定整個連麥從發起到接通的完整鏈路流，是一個怎樣的過程。\n 所以，我們就有了基本的框架需求：\n 1. 從被連麥端開始，構建建立房間、開始連麥、連麥中、結束連麥的完整鏈路\n 2. 業務層處理流程，刨除底層複雜技術實現的快速集成方案\n 3. 高接通率健壯性，從實現角度保證請求的及時準確\n 根據這三則核心訴求，我們提供如下的連麥解決方案。","attrs":{}}]},{"type":"image","attrs":{"src":"https://static001.geekbang.org/infoq/9c/9c6176acdc92b2e2b368dd00506fd115.png","alt":null,"title":"圖2-1 宏觀流程說明","style":[{"key":"width","value":"50%"},{"key":"bordertype","value":"none"}],"href":"","fromPaste":false,"pastePass":false}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":" 接下來，我們就來分別拆分來看一下。","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"heading","attrs":{"align":null,"level":1},"content":[{"type":"text","text":"三、階段拆解","attrs":{}}]},{"type":"heading","attrs":{"align":null,"level":4},"content":[{"type":"text","text":"主播啓播階段","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":" 對於主播啓播階段的處理，主要是通過當前主播服務側的特徵數據，來決定該主播是否能夠開啓連麥直播間。爲什麼會就直播間是否是連麥直播間而進行區分呢？主要還是涉及到連麥直播間全鏈路對於各環節要求會更多一些。在這裏做區分一方面對於主播來說操作代價並不大，另一方面也可以減少服務端對於此類直播間的記錄，並利於維持更合適的預準備策略資源池大小。\n 主播在請求啓播時，向服務器發出的啓播地址請求，會被服務器根據啓播策略篩選開啓直播間類型。服務器會根據判斷結果，選擇是否開啓具有連麥擴展能力的直播間並返回其推流地址到主播端。主播就可以以此地址進行開播推流了。","attrs":{}}]},{"type":"image","attrs":{"src":"https://static001.geekbang.org/infoq/93/93988d67f187b873775303f247df300c.png","alt":null,"title":"圖3-1 啓播階段關鍵環節示意圖","style":[{"key":"width","value":"100%"},{"key":"bordertype","value":"none"}],"href":"","fromPaste":false,"pastePass":false}},{"type":"heading","attrs":{"align":null,"level":4},"content":[{"type":"text","text":"連麥發起階段","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":" 在主播開啓直播間後，所有滿足連麥要求的對端，都可以向主播發起連麥請求。連麥請求的一方有可能存在競爭。因此對於先發起請求的連麥方，在其或者主播並未因爲客觀原因明確否定本次連麥活動前。我們應該通過綁定主播和連麥端的方式，來避免旁路干擾。\n 當然呢，在確立連麥關係前，我們需要對連麥方的資格進行校驗。目的是爲了保證，當次連麥活動的實際有效性。否則我們對於不滿足資質的連麥方分配了連麥關係，就會等於變相的搶佔了對單一直播間來說本就稀少的連麥權限。這將會帶來不少的安全和管理風險。同時爲了避免發起連麥端，在發起之後相當短的時間內反悔連麥操作。我們需要預留出來部分時間用來提供一個“返回窗口期”，這部分的時間策略具體閾值界定，就需要產品根據用戶特徵來進行數據分析決定了。\n 一旦連麥關係確定，那麼對於連麥端來說，就需要進入“連麥等待”狀態了。此時主播則會接收到連麥請求。根據主播決定同意/拒絕，來決定是否需要建立連麥直播間。\n 如果主播選擇拒絕，則當前連麥綁定關係被釋放，發起連麥方會收到單推並獲之失敗原因，其他用戶也可以從新競爭連麥。\n 如果主播同意，則在預準備策略中進行預處理的資源會被直接分配給當前確立的連麥活動。並就此將原有直播間提升爲連麥直播間。服務端會開啓推流地址的動態切換策略，並將關聯信息返回給推流雙端，以完成聲網鏈接初始化。","attrs":{}}]},{"type":"image","attrs":{"src":"https://static001.geekbang.org/infoq/f1/f1de3c226b89ab7e56d4b17697429e6c.png","alt":null,"title":"圖3-2 發起階段關鍵環節示意圖","style":[{"key":"width","value":"100%"},{"key":"bordertype","value":"none"}],"href":"","fromPaste":false,"pastePass":false}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":" 整個連麥發起階段對於用戶來說，基本是無縫銜接的。這主要通過混合推流來實現這樣的操作。在主播連麥前，主播端相當於直接將本地流推送到推流服務器，由推流服務器進行後續的包括轉碼分發等操作。而當連麥建立後，雙端推流首先通過聲網服務器進行了流混合。之後通過我們傳遞的主播端推流地址，將混合後的流轉發給我們自身的推流服務器。這也就相當於，用聲網完成處理後的流替換了我們原始主播的直推流，服務端只需要就此完成部分時間戳校驗同步服務，減小了切流帶來的卡頓影響。","attrs":{}}]},{"type":"heading","attrs":{"align":null,"level":4},"content":[{"type":"text","text":"連麥過程階段","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":" 當主播和連麥方完整建立連接後，就進入了連麥過程階段。這一階段就心跳維持和推拉流來說，爲了保證穩定鏈接和一定的交互擴展性，應該在聲網自身IM消息判斷外，額外維持一套獨立的心跳請求。通過心跳請求，將雙端時間戳發由服務端進行連麥實際時長同步。同時，也利於服務端根據具體情況，就一些關鍵數據與雙端進行協同。另一方面，如果不採用強綁定機制，即推流CDN等相關流推送部分爲非聲網的第三方供應商時，我們也需要通過心跳請求來得到並判斷當前網絡狀態。當然，除了心跳請求這種方式外，還存在諸如控制流消息定製等其他方式可以實現相同的效果。這種方式保活相對快捷方便消耗較小，不需要維持長鏈接，不過需要小心請求的安全處理。\n","attrs":{}}]},{"type":"image","attrs":{"src":"https://static001.geekbang.org/infoq/b0/b03bec1b07c83ecf1945d40aabe36972.png","alt":null,"title":"圖3-3 連麥過程關鍵環節示意圖","style":[{"key":"width","value":"100%"},{"key":"bordertype","value":"none"}],"href":"","fromPaste":false,"pastePass":false}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":" 連麥中，雙端經常有一些交互活動。對於類似於打賞的操作，建議通過直播間消息管線來實現。這樣的話可以不需要再獨立維護一套自建IM用於雙路雙端的消息傳遞，而可以直接利用直播間現有消息管線實現雙端通訊。如此不論直播間如何切換，消息管線都是持續存在且不用重啓，保證了主播和觀衆的體驗。其實，如果沒有一些特殊的定製化操作，連麥端的消息處理和其餘觀衆是一樣的，即消息邏輯一致。","attrs":{}}]},{"type":"heading","attrs":{"align":null,"level":4},"content":[{"type":"text","text":"連麥斷開階段","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":" 那麼什麼時候連麥結束呢？這個實際上是有多種情況的。最常見的就是主播或者連麥端的主動斷開，除此之外還有網絡波動斷開、服務端策略斷開等情況。從大體上講可以分成兩類，即主動斷連和被動斷連。\n 主動斷連，指的是由參與連麥的雙端中的一端或者多端，單方面或者達成一致的短線操作。\n 被動斷連，指的是由於外部干擾或者服務端策略影響，導致的連線終止。\n 對於被動斷連（如：斷連、費用不足、持續掉線等），我們最好在問題發生前，有足夠的策略能夠進行容錯處理。其目的是爲了保證，在斷開後直播間還能夠恢復正常，而不至於因此產生健壯性問題。","attrs":{}}]},{"type":"image","attrs":{"src":"https://static001.geekbang.org/infoq/56/56b111399af76d87208e5356706d3d00.png","alt":null,"title":"圖3-4 連麥斷開關鍵環節示意圖","style":[{"key":"width","value":"100%"},{"key":"bordertype","value":"none"}],"href":"","fromPaste":false,"pastePass":false}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":" 連麥中我們使用聲網來作爲了真正的推流端，聲網混流服務器將混合好的數據推送到我們自建/第三方推流服務器上，並以此分發到CDN。當一端退出時，退出的消息會隨着視頻流（聲網將對應的狀態消息封裝到了數據流中的關鍵字段上，以保證鏈接方畫面與接收操作的端上一致性）推送到對端。對端接收到消息後，也需要向當前佔用的聲網直播間發送退出房間消息，才能使連麥房間真正變成雙端無關的房間（有時存在審覈需求，連麥房間內可能存在除連麥雙方外的多個用戶，這些用戶都屬於在服務端的審覈機器人或着人工賬號），進而才能由服務端釋放房間資源歸還到資源池，或者重新分配給新場景。\n 當連麥結束後，主播端情況選擇是否請求服務端直播間地址更新（個人建議執行，讓服務端選擇是否更新），在取得後切換當前端推流地址爲取得的地址。連麥方則關閉推流模塊，重啓拉流模塊並重新進入被連麥的主播直播間。\n 就此，連麥流程完畢。","attrs":{}}]},{"type":"heading","attrs":{"align":null,"level":1},"content":[{"type":"text","text":"四、總結","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":" 相比起獨立開發連麥功能的大量工作，採用我們介紹的混和實現的方案，既能夠保證整體框架的低捆綁高兼容，又能夠藉助聲網成熟的通訊處理體系來降低風險成本。同時，與所有第三方的松耦合，也意味着我們能隨時在接入方面進行替換。\n 不過我相信，聲網還是會一如既往的以穩定高效的網絡和專業下沉的技術，來讓您感嘆：直接使用聲網還是更加高效便捷。屆時，自研連麥外加聲網連麥的混合方式，也未嘗不是一種優雅的選擇。\n","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}}]}