語聊房架構演進實踐

作者：B站開播互動組 2023-11-14 20:51:08

開發架構

隨著架構的演進，我們需要有合適的評估機制，來評估變化對架構的影響，防止架構隨著時間推移而退化。架構由很多維度構成，包括性能，安全性，穩定性，代碼規范等，對于不同的維度，我們需要建立不同的指標來評估。

序言

羅馬不是一天建成的。語聊房當前架構也是不斷演進的結果。

在技術架構層面，語聊房作為搭建在直播體系上的業務，使用既有技術架構體系可以幫助我們快速搭建早期產品，但隨著業務迭代，已有技術體系又成為新的技術架構的負債。

同樣在業務架構層面，語聊房產品已經迭代一年，產品形態依然在快速變化，已有的業務架構又會成為新的業務架構的阻礙。

每一次產品需求的迭代，都會對已有技術架構和業務架構造成雙重沖擊。

本文將結合語聊房持續演進的過程，談談業務視角下的架構演進。以及如何構建能應對各種變化的系統，不斷達到新的平衡。

語聊房來龍去脈

了解架構演進之前，我們先了解語聊房業務的來龍去脈。從語聊房的前身PC版本多人連線算起，整塊業務到現在已經迭代一年。

圖片

上圖介紹了這一年來的語聊房產品迭代的2個主要階段。

第一個階段是2022年7月，從0到1的產品探索期。直播已有的互動能力比如主播和主播視頻PK，能力模型是圍繞一對一建設的。一方發起另一方接受就可以開始互動，一方退出這一場互動就會結束。這種互動模型在產品上存在諸多限制，比如無法支持一個房間多個主播同時互動的業務。于是為了滿足用戶需求，我們開始探索了多主播間的互動能力，包括主播與主播，主播與觀眾的音視頻互動的能力。在這個階段主要目標是對齊競品，同時完善我們開播工具的基礎能力，豐富主播互動玩法。

第二個階段是2023年，語聊房項目經過戰略升級，成為專項進行運營。既是一次巨大的機會，又是巨大的挑戰。一方面我們在功能層面與競品還有明顯的距離。另一方面在技術架構層面，語聊房的架構是從主播與主播間互動模型演變過來，與語聊房主播與用戶間的互動還有很多需要調整的地方。同時相比探索期，專項整體迭代節奏加快，而且對技術質量要求更高。所以在這個階段，主要目標變成在功能層面快速迭代以滿足用戶訴求，同時技術架構上需要快速調整以響應產品變化。如何又快又好的完成需求，成為這一階段技術上的主要矛盾。

圖片

上圖介紹了戰略升級后，語聊房在用戶體驗升級與產品迭代上進行的具體功能迭代事項。

架構演進實踐

直播架構體系

語聊房業務構建與直播體系之上，所以要了解語聊房的架構，就必須先了解我們當前的直播業務和架構，才能幫助我們建立全面的認識，更好的理解決策時的一些思考。

圖片

上圖是典型的直播業務UI視圖，中間部分為視頻流播放器，上方為主播信息，榜單等信息，下方包括房間公告，彈幕互動，底部互動按鈕等業務信息。

用戶通過點擊直播間，進入直播間，觀看主播推送的視頻流，同時可以通過彈幕，禮物等方式與主播進行實時互動。

圖片

上圖所展示直播架構只是當前的直播架構的冰山一角，完整的架構遠比這個復雜。但為了更好的聚焦于語聊房架構，我們重點介紹將會與語聊房有交集的流程和模塊。

術語介紹

采集（Capture）：采集是指將視頻信號從攝像頭、屏幕或其他視頻源設備中捕獲。采集設備通常是視頻編碼器、硬件捕捉卡或網絡攝像頭等。采集設備將視頻信號轉換為數字信號，并將其傳遞到下一個步驟，即編碼。
編碼（Encoding）：編碼是指將采集到的視頻信號壓縮成適合網絡傳輸的格式。在直播中，通常使用H。264或H。265這樣的視頻編碼標準來實現。編碼后的視頻文件大小更小，傳輸速度更快。
推流（Streaming）：推流是指將編碼后的視頻數據傳輸到互聯網上的服務器。推流可以使用實時傳輸協議（RTMP）、HTTP動態自適應流媒體協議（HLS）或動態自適應流傳輸協議（DASH）等協議來實現。
轉碼（Transcoding）：轉碼是指將推流服務器上的視頻文件轉換為不同的分辨率、比特率和格式，以適應不同的設備和網絡速度。轉碼可以將高清視頻轉換為標清視頻，或將視頻文件轉換為適用于移動設備的格式。
分發（Distribution）：分發是指將轉碼后的視頻文件分發到全球各地的觀眾。CDN通過使用各種技術，如邊緣緩存、負載均衡和就近路由等技術，確保視頻可以在最短的時間內傳遞給觀眾。觀眾可以通過從CDN緩存服務器請求視頻文件來觀看直播。
拉流（Playback）：拉流是指觀眾從CDN緩存服務器請求視頻文件，并在其設備上播放視頻。觀眾可以使用各種設備觀看視頻，如計算機、智能手機、平板電腦和智能電視等。拉流過程中，CDN通常會根據觀眾的設備和網絡速度，自動選擇最佳的視頻文件分辨率和比特率。
P0接口：用戶進房后需要獲取視頻流格式，清晰度，大小，地址，橫豎屏，以及房間類型等信息，為播放視頻流做準備
P1接口：完整的直播間視圖，不僅包含視頻流播放，還需要獲取房間相關的業務信息，比如房間類型，標題，分區，公告，彈幕，送禮以及相應的業務信息等
B端客戶端：指主播進行直播所使用的客戶端，包括B站官方的PC直播姬，app直播姬，web直播等，還有第三方程序比如OBS等
C端客戶端：指用戶觀看直播使用的客戶端，包括app粉版，ipad，web等。

主播首先使用B端客戶端打開直播間，然后通過B端客戶端采集進行直播的內容，比如攝像頭，話筒，游戲程序，屏幕等內容，然后將內容通過壓縮編碼成合適的格式推送到視頻云。視頻云需要將接收到的視頻數據轉換成不同的視頻格式并分發到全球各地不同的節點，用來滿足各地觀眾使用不同的終端，對分辨率和格式的不同的需求。

介紹完B端這一系列流程后，下面就是觀眾使用C端客戶端進入直播間。首先需要請求業務服務器P0和P1接口，P0接口會根據C端用戶位置，終端設備，分辨率等維度，返回視頻拉流地址，同時C端客戶端也會根據視頻橫豎屏類型，房間類型等渲染出相關的視頻內容進行播放。P1接口會根據房間和用戶屬性維度，返回當前房間相關的直播業務信息，比如房間分區，不同分區往往對應不同的業務玩法等。

同時直播內容安全也是非常重要的一環，我們需要保證觀眾看到的視頻符合法律法規。所以需要對主播推送視頻進行審核。通過審核后的內容才能推送給用戶觀看，所以不可避免的會造成延時，也就是主播與觀眾的時間軸不一致。上圖中專門在每個環節上標注了延時時間。一方面我們需要延時來保證內容安全，同時各個子系統處理，分發，流轉也需要時間，另一方面我們又希望提供主播與觀眾實時互動的能力。畢竟如果用戶發完彈幕，幾十秒后才能收到主播反饋，那用戶體驗將會收到極大影響。這一點對于實時性要求特別高的語聊房業務也是一個難點。

沉淀多人互動模型

經過上面的介紹我們已經了解了直播的基本架構。已有的架構數據鏈路是主播音視頻數據經過視頻云推送給用戶。舉個列子就像有一個舞臺，主播在舞臺上表演，用戶在舞臺下觀看。主播如果需要和另一個主播進行互動，就需要一個電話。我們使用的“電話“就是RTC，我們使用RTC技術來解決主播間實時音視頻通信的需求。

術語介紹

RTC（Real-time Communications）實時通訊。RTC是對實時通信的更加寬泛的統稱，包含H323 SIP 私有協議等等通信標準，涵蓋從端，服務器，支撐系統等一整套的通信標準，通信的形式包括實時語音，實時視頻，實時文本等。

在做主播多人連線之前，已有的互動模式包括主播和主播視頻連線，主播和用戶連麥等功能都是一對一互動模型。主播邀請另一個主播或用戶發起一次視頻連線或語音連麥，另一方同意即開始互動。然后其中一方退出本次互動狀態就變為結束。顯而易見，這無法滿足下圖這種類似于聊天室，主播可以邀請多人同時互動的業務需求。

圖片

所以我們首先需要分離出場次和會話的概念。

主播首先創建一個互動場次，場次之內可以分別邀請多個主播，單個主播的加入離開對應會話概念。基于場次與會話的抽象，主播可以創建場次后邀請多個主播同時進行視頻連線。即使場次創建人退出，場次仍然可以存在。

術語介紹

場次：場次是多人互動中的基本單位，通常表示一次互動活動，場次由主播創建，主播可以通過申請或邀請與其他主播進行實時視頻交流。
會話：會話是場次的基本單位，通常一個場次關聯多個會話，一個用戶的一次加入與離開對應一次會話的建立與結束
頻道：主播與RTC服務端鏈接的資源標識，通常一個會話與一個頻道一一對應，每個頻道都有一個唯一的頻道ID，用戶可以通過頻道ID加入到指定的頻道中。

圖片

上圖是新增場次，會話，頻道等領域之后的多人互動模型業務架構圖，與上面直播業務架構相比，我們屏蔽了推流到觀看過程細節，重點關注與rtc相關的業務交互。

當主播使用互動功能時，客戶端將rtc音視頻數據作為一個采集源，與其它的采集源數據合成后推送給視頻云，最后用戶拉取視頻流觀看。

圖片

這里又引出了一個新的問題，既然主播間可以使用rtc進行實時音視頻互動，那用戶也接入rtc，是否就可以不經過視頻云直接觀看主播的直播？

答案是yes。業內也有很多互動直播間只基于rtc的能力實現。但是顯而易見，作為探索性業務，基于實現成本的考慮，作為旁路系統接入的實現成本遠遠低于改造整條鏈路。但帶來的缺點就是，業務服務需要同時考慮2套系統的狀態的一致性。這個狀態一致性也會在后面給系統的演進帶來更多的挑戰。

圖片

上圖是基于業務架構圖所對應的應用架構圖

我們在服務層增加新的服務，用來處理場次，會話和rtc渠道的關系。

B2B擴展到B2C

技術層面搭建好主播與主播的互動能力以后。我們沉淀了多人互動模型的技術資產。但產品層面還遠遠不夠，一方面主播只能使用PC直播姬進行互動，缺少移動端互動能力，減少了能使用的主播數量。另一方便還不支持主播與觀眾進行互動，減少了互動功能使用場景，也減少了主播進行互動的意愿。

圖片

我們認為社交是促進主播開播的一個契機。，語音聊天是非常重要的社交場景，有助于激發主播開播動機。

為了支持產品訴求，我們架構上需要做出如下的調整：

支持用戶使用實時音視頻能力與主播進行互動
支持用戶管理上下麥行為，包括靜音，踢人等操作
支持觀眾送禮給互動用戶，提升用戶上麥互動積極性
數據鏈路從B端單向推送到C端改成雙向流動。

圖片

上圖是經過調整后的多人語聊業務架構圖，相比多人互動架構圖，我們屏蔽了rtc相關的交互細節，重點關注擴展到C端用戶后系統架構的變化。

首先是互動能力擴展到移動客戶端，產品層面支持C端用戶參與互動。我們根據用戶是否參加互動，區分用戶為觀眾態和互動態。

觀眾態：用戶不加入rtc頻道，通過視頻云拉取主播推送的視頻流，流里包含所有互動用戶的rtc音頻流。

互動態：用戶不拉取視頻云視頻流，通過rtc音頻流參與互動

圖片

然后是基于RBAC模型的用戶權限設計。增加角色控制不同主播，管理員，用戶的權限。

術語定義

用戶：發起操作的主體，按類型可分為2B和2C用戶，在語聊房場景中包括主播，房間管理員，用戶，審核人員，后臺管理等
角色：連接了用戶和權限的關系，每個角色可以關聯多個權限，同時一個用戶關聯多角色
權限：用戶可以訪問的資源，包括操作權限，數據權限等。在語聊房場景中包括上下麥行為，玩法管理等。

最后是打通送禮鏈路，以前觀眾只能給主播送禮，現在支持參與互動的用戶送禮，這樣也能提升用戶互動意愿。

麥位管理云端化

首先介紹一下麥位是什么：

參考上圖多人互動業務示意圖，主播的視頻會固定在視頻流左側，右側四個小格展示加入互動的其他主播。

參考上圖語聊房業務示意圖，主播固定在上方區域，下方2排共8個圓圈展示參與互動的用戶頭像。

麥位管理包括互動用戶位置的分配，操作按鈕展示與控制，比如靜音，踢人，是否說話中狀態展示等邏輯。

然后是問題的關鍵，云端化對應的是本地化。最早設計時這些邏輯會什么會放到客戶端上來做？這個問題還要從多主播互動這個業務來回答，多主播互動中每個房間5個位置，最多5個房間一起互動，一共5X5=25個位置。同時每次互動用戶上下麥，都會導致25個位置渲染發生變化。另一方面早期的麥位控制也比較簡單。不包括復雜的位置分配等邏輯。所以當時評估下來放在客戶端上實現比服務端實現成本低。等到多人語聊業務上線以后，最初的實現已經無法滿足復雜的麥位管理控制需求了。所以我們需要將麥位分配與控制邏輯從客戶端遷移到服務端。

控制權的轉移

從客戶端遷移到服務端的關鍵點在于控制權的轉移。將之前麥位數據從B端產生，通過透傳通道推送到C端消費。變成由B端和C端發送數據到服務端，服務端進行計算，存儲和推送。同時架構升級過程中，需要兼容新老版本組合情況，保證程序向后兼容，不影響線上產品已有功能。

圖片

眾所周知，兼容性與代碼邏輯和數據結構密切相關。新的代碼會產生新的數據結構，同時要兼容老的數據結構與邏輯。老的代碼處理不了新的數據結構，需要通過版本做訪問隔離。遷移過程中代碼與數據組合情況與測試點：

服務端數據	服務端代碼	B端版本	C端版本	說明
老	新	老	老	兼容測試 ,分平臺測試(PC直播姬,ios直播姬,Android直播姬,ios粉開播,Android粉開播)
老	老	老	老	回歸測試
老	老	新	老	不存在, 數據版本會和B端版本保持一致
老	新	新	老	不存在, 數據版本會和B端版本保持一致
新	新	新	老	功能測試
新	老	新	老	人為使用姿勢問題, 在未發布服務端代碼的環境使用新版本

主播與用戶的實時狀態同步

麥位管理功能統一到服務端后，帶來的好處是業務擴展更容易，方便我們擴展更多的功能。但同樣也因為所有數據都需要到服務端來獲取，對于服務端的接口性能和實時性帶來了巨大的壓力。特別是當存在類似于賽事或者活動等大型熱門房間，百萬用戶同時在線時，實時狀態同步將是一個巨大的挑戰。

圖片

我們通過組合使用多個渠道，利用各自特點來平衡實時性與性能開銷之間的矛盾。

基于長鏈接消息的全量狀態同步。主動push，延遲在毫秒級，但無法保證必達。
基于push的推拉結合方案，在長鏈接不穩定的情況下，基于接口被動輪詢，延遲在秒級，同時服務端性能開銷大。
針對性能開銷大的問題，增加網關層內存緩存，匯聚相同房間的請求，減少透傳到業務服務端的壓力
基于視頻流里SEI，針對未登錄用戶，非重點保障場景等場景，使用視頻流里SEI攜帶數據來進行同步，延遲是10秒級別但是性能開銷非常小，作為最后的兜底
客戶端收到不同渠道來源的數據，基于數據的版本進行排序，避免消費數據時出現亂序

互動玩法引擎

經過上述一系列調整以后，業務架構基礎性比較穩定，開始探索語聊房內營收相關玩法。

圖片

通過在已有的送禮鏈路上，疊加玩法生命周期管理，分數計數，狀態轉移。構建玩法生態。

圖片

生產配套體系

【全鏈路應用監控】

圖片

一個成熟的系統是一定需要一個無死角的觀測能力，在任何領域都是這樣。醫療、航空，包括人體系統。

將應用系統監控進行分層，可以分為如下幾層：

1、基礎設施監控（CPU、內存、網絡、機房等）。這一層是任何計算機應用的基礎依賴。

2、請求和成功率監控（QPS/TPS、RT、SLO等）。這一層主要是觀測請求的數量和成功率。

3、業務監控（業務漏斗轉化、業務狀態扭轉等）。這一層主要是觀測業務系統內部的邏輯分支。

一般系統監控上述1、2層基本是默認都有的平臺設施。作為業務系統，只有1、2層是不夠的，1、2層監控無法感知業務異動。簡單講，如果你寫了一個在業務上有問題的分支代碼，此代碼不會產生任何錯誤code。這類問題，可能1、2層監控是毫無察覺的，因為1、2層不觀測這些。業務監控，一方面可以感知業務異動，還可以感知到1、2層故障帶來的業務影響。

【開播互動問診】

圖片

用戶看到的產品功能，可能只是冰山上面很小的部分。冰山下面部分是一個龐大的系統，會跨越多個微服務單元。語聊房是非常典型的多技術棧（app、pc、web、RTC、comet長鏈、業務后端等），多業務單元（語聊房業務后端、看播、開播、審核-工程、審核工作臺、視頻云、RTC等）合作的超大型項目。

人工排查一個問題的成本是非常高的。在項目初上線時，當時的相關系統配套并不完善，一個小問題都要把業務鏈條上的所有環節的人都要拉上一起排查。通過問診平臺可以一鍵全鏈路觀測到所有節點。

圖片

可以看到一個用戶的所有生命周期，對于排障基本可以節省90%時間。

底層思維

上面介紹完語聊房業務形態和系統架構一年以來的變遷。我們了解了因為產品形態調整，架構需要調整來適配新的產品形態。有些調整短期是好的，但長期又花了更多時間處理新來的問題有些調整踩了一些坑。為了技術現狀或者工時排期要求原因導致的架構妥協，然后事后又付出更多的工時成本遷移。回過頭來想想是什么原因導致我們的已有架構在變動產品形態調整時，總是在償還已有技術債務，或者自己挖了新坑自己再去填坑？

互聯網從業人員可能最討厭的一個詞就是“變化“。產品需求變了，導致技術方案需要調整，代碼需要重寫。代碼改動了，測試用例又得重新設計。工作量增加又導致項目時間調整，輕則軟件bug，重則項目失控。

那么有沒有通用的萬能法則可以指導我們進行架構演進的，以不變應萬變，真正又好又快？看過或者聽過“沒有銀彈“這句話的人，可能已經知道問題的答案了。但是為什么沒有呢？探討一個可以解釋萬事萬物的萬能法則，不管是誰聽了都會熱血澎湃。古人也不例外，早在兩千多年前，古希臘哲學家亞里士多德認為在各種物理規則的基礎上，還有一種東西可以統轄和解釋所有的物理規則。在他的作品集中，把他對邏輯、含義和原因等抽象知識的討論編排在他討論物理學的書冊《自然學》之后，并給這些討論一個標簽：《在自然學之后》（τ? μετ? τ? φυσικ? βιβλ?α）。從古希臘文翻譯到英文，于是就有了Metaphysics這個詞，看到這個詞就會聯想到最近很火的Metaverse，還有改名為Meta的Facebook。如果按照元宇宙的譯法，那么metaphysics就可以翻譯為“元物理”。但日本人在翻譯這個詞語時，從《易經》找到了 “形而上者謂之道，形而下者謂之器”一詞。于是Metaphysics便翻譯成了大家耳熟能詳但又不太了解的“形而上學”這一詞。

不管是亞里士多德的“本原“還是老子的“道“，都認為事物的現象背后必定有一個統一的規律，可以統轄和解釋所有的規則，闡述天地世間萬象變化。基于這種思想，就有了“格物致知”的說法。既然道存在于萬事萬物之中。那么同樣的萬事萬物中也都包含著道，也就是說只要把一個事務研究透了，自然也就獲得了道。王陽明和他的學生錢德洪一起切磋學問，二人都認為要做成儒家的“圣賢”，就得格盡天下之物，于是就指著園內的竹子，讓錢德洪去看。錢德洪一入夜就去窮究竹子的道理，竭盡心思想了三天三夜，也沒格出個所以然，還積勞成疾了。于是王陽明親自去格竹，也是竭盡心思早晚想不到竹子的道理，到了第七天，也因勞思而得病。

按照我們現代人的思維里，即使把竹子研究的再好，也造不了汽車。同樣的竹子格的再好，也成不了圣賢。世界上也不存在靜止的，孤立的“道“能夠解釋萬事萬物。這件事也成為王陽明日后心學思想體系建立過程中的重要事件。心學主張知行合一，按照通俗的話也就是討論“認識”和“行動”的關系。

我們都知道，不管是做技術架構，還是代碼結構組成方式，都反應了我們對產品的認知。如果沒有恰當的認知，就不可能做出合適的架構，甚至可能會導致項目徹底失敗。既然沒有永恒不變的“道“，那我們應該用什么樣認知來指導我們的行動呢？

這個問題在《實踐論》中做出了回答：

通過實踐而發現真理，又通過實踐而證實真理和發展真理。從感性認識而能動地發展到理性認識，又從理性認識而能動地指導革命實踐，改造主觀世界和客觀世界。實踐、認識、再實踐、再認識，這種形式，循環往復以至無窮，而實踐和認識之每一循環的內容，都比較地進到了高一級的程度。這就是辯證唯物論的全部認識論，這就是辯證唯物論的知行統一觀。

下面我將結合語聊房實際業務聊聊到對這幾個階段的認識。

從直接經驗到感性認識

眾所周知，互聯網產品是對我們生活或者生產過程中的抽象，除了極少數天才級的產品大師能夠設計出引領人類社會的產品，大多數的產品還只是打破時間和空間的限制，滿足人類社會的需求。

下面是我們常用的一些產品對現實生活中的實現。

圖片

同樣的道理，語聊房這個產品也不是憑空產生的，聊天的需求一樣存在于現實生活中

圖片

現實世界的場景是個例化的，與實際產品還有很大的鴻溝。首先了解現實世界的運行邏輯，具有初步的感性認識后，我們需要進一步抽象成通用型的業務模型。然后通過觀察競品的類似產品的實現也有助于幫助我們建立感性認識。經過這個階段，我們會對架構產生初步的概念。

從感性認識到理性認識

現實的情況和競品的實現幫助我們建立初步感性認識，通過對這些感性認識的整理，加以概念定義，類型歸類，邏輯重組等階段就能建立初步理性認識。但不同競品的商業模式，品牌調性以及完成度都會與我們千差萬別，直接全盤照抄往往是失敗的前兆，同時工期上也是不可接受的。通過與產運規劃對齊，理清實現路徑，幫助我們了解每個階段的主要目標和主要矛盾。

圖片

到這個階段，我們已經對所要做的事情有了初步的理性判斷，這有助于我們下一步架構落地。

理性認識用于指導行動實踐

抽象與統一認知

抽象是指從具體的事物中抽離出共性的概念或特點，將它們提煉出來形成一種抽象的概念或理論。計算機領域有一句名言，“任何問題都可以通過增加一層間接的中間層來解決“。原因就在于人的認知能力是有限的，抽象有助于降低我們理解復雜事物的成本。但是抽象同樣也會帶來模糊實現的問題。當我提起“馬“，我可能指的是河馬，你腦海中可能想到的是斑馬。所以我們需要，通過顯示的定義概念來統一語言，幫助我們更好地溝通和理解彼此的意思，才能做到團隊理解一致性。在領域驅動設計中，抽象和統一語言是非常重要的概念，它們可以幫助我們更好地理解和設計領域模型，從而創建高質量的軟件系統。

面向領域設計

語言只有在特定語境中才有意義，在不同語境中同一個概念往往會有不同的意義。特定語境往往對應確定的業務模型，比如同樣是“訂單”，在秒殺領域，拼單領域，團購領域等往往代表著不同的業務流程和現實意義。在代碼實現上，我們通過package，class等方式來進行模塊劃分。在領域驅動設計中，我們通過限界上下文來保證領域內概念的一致性。

圖片