進入直播領域有段時間了。
跟大多數同學一樣，剛接觸直播這個領域都非常好奇這個領域的巨集觀架構大概是什麼樣子的。
這裡根據自己的這段時間學習，粗淺總結下分享給感興趣的小夥伴掃掃盲。
目前直播平臺有很多，抖/快、B站、鬥/虎等。
直播這種高效的互動方式是各行業需要具備的能力，隨著網路技術的發展也是必然趨勢。
先拋開每家直播的內容不同之外，一個完整的直播平臺至少需要包含如下幾個核心功能。
觀看直播、傳送彈幕、打賞送禮、主播互動。
我們以一個普通的C端使用者的視角，來看下這幾個核心功能背後的大概應用架構。
觀看直播
當我們進入直播間首先就是觀看直播內容。
【拉流】
直播內容是通過 流媒體播放器 播放出來，而流媒體播放器通過 流地址 來拉取 流資料，再處理相關 解碼 工作，最後呈現出畫面和聲音。
為了保證全國甚至海外使用者都能夠流暢的觀看直播內容，就需要比較強大的物理網路覆蓋。
流媒體資料通過上游CDN源站推（或推拉結合）到所有邊緣節點。
不同地域的使用者通過 全域性CDN-DNS 排程後，就近訪問CDN節點。
為了儘可能覆蓋所有地區，不可能每家公司都去建設龐大的網路基建。
這時候就需要藉助強大的公有云平臺（BAT、華為、金山、位元組等）。
公有云廠商砸了鉅額資金建設物理鏈路，作為應用型企業只需要使用雲產品能力即可，一切即服務。
當我們愉快的看著直播時，會好奇這些直播內容源頭在哪裡，這些畫面是如何被採集的，資料又如何傳輸的。
【推流】
通常開播都有一個開播工具，開播工具是專門用來採集流媒體（音視訊裝置）資訊及媒體流合成的，也可以用 OBS 等強大的推流工具。
當開播工具採集到媒體資訊之後會進行本地壓縮，然後通過 RTMP（Real Time Message Protocol） 協議將資料推送到RTMP伺服器。
RTMP伺服器收到流媒體資料之後，會將流資訊解碼並且進行 HLS（HTTP Live Streaming） 檔案切片。
將RTMP伺服器部署在公有云主機上，是為了藉助公有云內部服務（LAAS、PAAS）的親和性，可以最大化便捷的覆蓋到CDN邊緣節點。
你可能好奇，為什麼推流用RTMP協議而拉流用HLS協議。
播端使用RTMP，是因為RTMP基於TCP的實時協議，可以保證推流的可靠性和實時性。
看端使用HLS是因為HLS是基於靜態小檔案，這就比較方便在大規模百萬 PCU（Peak concurrent users ） 時，利用靜態CDN容易分發的優勢來覆蓋。
使用HLS同時也便於在不同位元速率之間進行動態切換，以此來達到根據使用者的網路情況選擇最優的觀看體驗。
比如，使用者處於弱網下，我們就切到低位元速率下觀看。
使用者網路良好時，我們就切到高位元速率下觀看，同時也可以使用一些高階的觀看體驗和互動。
當然，HLS還有非常多的優勢，在壓縮、加解密等方面都非常成熟。
在2C大規模直播場景下，flv是過去時，HLS才是未來。
【P2P】
為了儘可能節省CDN帶來的巨大成本，會使用 P2P（Peer to Peer） 技術來減少公有云頻寬使用。
同樣，為了儘可能將 STUN 伺服器 、信令伺服器 離使用者近一些，這兩個伺服器都是部署在公有云邊緣主機上。
進一步壓榨成本，還可以使用 PCDN（P2PCDN） 服務。
由於公有云強大的終端網路覆蓋（路由器、終端裝置等）可以將CDN分發內容進一步邊緣化。
利用數以萬計的邊緣計算能力將內容和計算一直延伸到使用者末端。
其實P2P技術已經非常成熟且發展歷史要比WEB網際網路久遠。
傳送彈幕
觀看直播時非常重要的一個訴求就是與主播互動，而彈幕是資訊承載量最大的互動方式。
彈幕 現在已經是視訊領域必不可少的媒體元素。
彈幕最早其實是在點播領域裡，日本的 Niconico 算是彈幕互動的鼻祖。
A站 （Acfun）基本是國內彈幕視訊網站的文化發源地 。
但是目前國內把彈幕玩出新次元的當屬B站（bilibili）了。
彈幕從傳送到接受，依賴 長連線 中介軟體。
考慮到平臺可用性，長連線服務整體需要支援容災，整個架構需要支援多機房混合部署。
在彈幕訊息投遞端需要做機房線路探活，根據探活後的相關資料擇優選擇機房。
使用公有云還有一個好處，可以享受一定額度 “對等連線” 增值服務。
整體架構越來越趨向混合雲，就是為了儘可能平衡私有云的核心資料閉環，同時藉助公有云強大的網路覆蓋。
公有云高效能主機一般在低頻下能扛個百萬連線，瓶頸基本在記憶體和頻寬。
機器成本其實還好，因為機器理論上可以無限擴充套件，但是頻寬是有物理上限的，所以比較貴。
【輿情管控】
任何有一定體量的網際網路公司，根據所處的行業和內容不同，需要對使用者的參與行為進行輿情管控。
彈幕區就是需要管控的一個主要陣地，也是各安全中心所負責的核心戰場之一。
彈幕的特點也恰恰是很難管控的，通常思路根據AI演算法（如NLP）對彈幕內容進行前置敏感詞過濾、情感分析負向過濾等。
其實，AI演算法能處理的都是相對簡單和容易識別的語意。
中國文字和文化博大精深，再加上覆雜的詞藻、詞梗組合起來，就算再強大的演算法都無法絕對識別。
需要人工輔助稽核，人工還需要有一定的“文化”底蘊和相當廣的“知識面”。
所以必然是一個非常龐大的稽核隊伍。
一般應用企業，做彈幕功能技術含量並不高，而且現在雲廠商、開源sdk，稍微組合下架構基本就搭能起來。
反而是，安全、輿情管控才是最關鍵和重點投入的地方。
現在做第三方輿情發現和管控的公司也慢慢多了，社會類輿情管控公司還是比較多的，細分垂直類是比較少。
送禮打賞
在觀看一段主播賣力的表演之後，就需要通過打賞來表達誠意了。
一個看似簡單的送禮，其實需要涉及非常多的系統，這些系統位於不同的職責層面上。
但是不論是在直播領域還是電商、教育，基本都是類似的，只是售賣不同的商品而已。
送禮鏈路上，訂單、賬戶、清結算其實是比較成熟的交易、財務模型。
這兩塊基本上按照模式來套，目的就是完成公司的確認收入和資金結算。
【整體鏈路】
我們將整個鏈路分兩層，第一層是售賣業務層，該層由一系列售賣單元組成，比如商城、促銷中心等。
在直播領域，送禮系統就是位於這一層，送禮物可以認為是一種虛擬商品的交易。
送禮場景可以非常多樣化，但都是在變相的促進交易的達成。
一旦當商品售賣成功之後，根據業務性質的不同，確認收入的金額和時間點也不同。
在直播送禮中，送出去的禮物基本就是近實時確認收入，此時就需要交易訂單（或叫業務訂單）來承載這部分交易職責。
在售賣業務層下層是交易結算層，是收入的分賬、結算、打款部分。
該部分的核心是支撐業務售賣的交易，清結算各個角色的收入。是交易結算系統最複雜的地方，也是及容易出現資損的地方。
不論我們售賣什麼，要想在交易系統裡完整的跑起來，首先就需要將虛擬的售賣概念進行商品化。
有了商品之後就可以通過售賣層上架去銷售。
送禮本身業務比較簡單，將個人賬戶的虛擬資產進行扣除，加到主播賬戶中去，就完成了業務上的基本流程。
這一步完成之後，緊接著就需要對這筆交易訂單進行分賬處理。需要分別計算平臺、外部商家/機構等各個角色參與者分別得多少錢。
送禮成功之後至少是需要平臺、主播（或工會）進行一定分成。
該部分是清結算系統中的清算部分職責，該部分通過計費、分攤分別計算好各個角色結算明細。
結算系統再通過定期撈取合同簽訂的結算週期（T+N/月結等）給商家結算並且打款，該部分多數是有賬期的。
簡言之，送禮打賞偏交易結算領域，整個系統的核心在於賬務、交易、財務等業務知識。
同時在系統設計上，資料一致性、對賬流程和場景是整個系統架構設計的核心。
主播互動
在直播間裡，送禮不管對主播還是平臺來說，都是最終目的。但是這個最終目的不可能一步達到，是需要不斷的通過其他場景來轉化。
直播使用者的絕大部分需求是荷爾蒙需求，如何通過各種互動工具、互動形式，讓使用者與主播彼此多互動，才能促進送禮。
從使用者視角來看互動形式主要分為三類，彈幕、手勢、送禮。
如抖/快雙擊螢幕點贊，虎牙的長按喚起快捷皮膚，B站的傳送特殊彈幕觸發“熱力風暴”特效等。
同時基本每家都有的特殊禮物互動，通過贈送特殊禮物來達到房間主題變化、主播裝扮變化等。
所有的互動形式我們都需要統一的進行抽象管理，可以用一句話概括： “在指定的房間指定的時間段，啟用一個或多個互動活動/玩法”。
至於某個具體的互動玩法，該玩法需要哪些素材，需要哪些觸發媒介，除了通道部分可以走訂閱方式，其他都需要定製開發。
比如，彈幕互動中的蓄力類的，除了通用的彈幕通道之後，哪些詞，在多少時間視窗內命中多少次，然後觸發什麼業務邏輯。
或連擊送禮蓄力類，除了送禮通道是通用部分之外，哪些禮物，在多少時間視窗內送出多少個，金額滿足多少都屬於業務邏輯需要捕獲和處理的地方。
整個互動是需要打通看端和播端。
看端特效和播端特效是有明顯區別的，看端多數是在直播間裡可以互動的特效元素，而播端特效最終是在流裡體現的。
比如，一個送禮互動特效，使用者“連續”贈送禮物到達一定的閾值就觸發播端的互動邏輯，最終將訊息輸入到流裡，同時看需求是否新增 SEI（Supplemental Enhancement Information） 資訊。
房間主題
如果我們將直播間比喻成現實中的房間，我們希望是千人千面的，並且具有一定的定製性。
同時，我們希望房間可以根據日曆自動感知到節日的 娛樂性 、 嚴肅性 。
如果將直播間比喻成線上的社群單元，那此地也不是法外之地，需要受到不同程度的輿情、社敏性、法律安全監管。
直播間按照業務形態劃分，有非常多的維度去分，比如商業化房間（帶貨/電商/分銷）、遊戲房間、K歌房、放映廳等。
最終，不同的房間需要開放、管制一些能力，互動娛樂，送禮，主播行為等。
日曆和主題管理是整個房間生成的基礎基因。
需要對房間整個架構進行工程化設計，要面向介面、面向開放標準。
只有這樣才能具備定製性和擴充套件性。
整個房間大概有幾個核心區域， ___送禮區、播放器區、彈幕區、互動區。
這幾個區域的實現需要分成兩層，第一層實現最核心的核心基礎功能。
這部分功能可以直接排除主題相關性。
第二層是其他帶有裝飾的功能，這部分實現需要具備主題感知能力。
在此基礎之上，我們假設實現一個彈幕區的特殊彈幕效果。
該實現外掛通過工程化介面和標準，拿到日曆&主題便可以感知到節日的屬性。在實現上可以分離出基礎功能和效果功能。
這樣設計還便於將效果類功能做全年的特殊節日的自動化測試和業務巡檢。
房間推薦演算法需要加入日曆推薦因子，這部分是比較好理解的。比較有意思的是房間構造中心才是房間成品的出口。
活動保障
最後分享下技術保障方面的內容。
這部分就精簡總結下，不敘述過程。
簡言之，保障主要關注兩個重點。
第一個重點是我們大多數比較熟悉的應用系統常規的抗高併發，這裡包括一系列的中介軟體、DB、快取、微服務套件等。
第二個重點是跟PCU相關的線性資源CDN頻寬、P2P頻寬、長連頻寬、打點、實時報表計算等。
按照看、播兩端分別來看。
播端，需要重點保障推流的可用性，所以基本上在推流側至少有兩路流互相backup。
看端，QPS、TPS相關介面基本是斜率或突增流量相關。
（注：某介面峰值可以扛住10wQPS，到達這個峰值是每秒鐘加1w緩慢增加，還是1s到達10w是不一樣的。）
斜率本質考驗的是後端相關資源的擴容速度。
在大併發場景下，有時候我們需要提前擴容就是為了防止突增流量。
這也是按照斜率來評估擴容資源的難點。
另外一方面是跟PCU線性相關的。
PCU直接帶來的是相關公有云頻寬、連線池等比例增加，這部分需要做好資源預購。
當線上的人數非常高時，資料上報、實時資料處理也都是線性增加的。
這部分儲存資源是需要提前預備好，計算資源可以適當彈性排程。
所有上述場景在合理的容量範圍內系統都可以承載，但是一旦有非預期的流量進來我們也要有自我保護的機制和拉閘能力。
這部分相關的，限流、降級能力也是必不可少的。