序言

羅馬不是一天建成的。語(yǔ)聊房當(dāng)前架構(gòu)也是不斷演進(jìn)的結(jié)果。

在技術(shù)架構(gòu)層面，語(yǔ)聊房作為搭建在直播體系上的業(yè)務(wù)，使用既有技術(shù)架構(gòu)體系可以幫助我們快速搭建早期產(chǎn)品，但隨著業(yè)務(wù)迭代，已有技術(shù)體系又成為新的技術(shù)架構(gòu)的負(fù)債。

同樣在業(yè)務(wù)架構(gòu)層面，語(yǔ)聊房產(chǎn)品已經(jīng)迭代一年，產(chǎn)品形態(tài)依然在快速變化，已有的業(yè)務(wù)架構(gòu)又會(huì)成為新的業(yè)務(wù)架構(gòu)的阻礙。

每一次產(chǎn)品需求的迭代，都會(huì)對(duì)已有技術(shù)架構(gòu)和業(yè)務(wù)架構(gòu)造成雙重沖擊。

本文將結(jié)合語(yǔ)聊房持續(xù)演進(jìn)的過(guò)程，談?wù)剺I(yè)務(wù)視角下的架構(gòu)演進(jìn)。以及如何構(gòu)建能應(yīng)對(duì)各種變化的系統(tǒng)，不斷達(dá)到新的平衡。

語(yǔ)聊房來(lái)龍去脈

了解架構(gòu)演進(jìn)之前，我們先了解語(yǔ)聊房業(yè)務(wù)的來(lái)龍去脈。從語(yǔ)聊房的前身PC版本多人連線(xiàn)算起，整塊業(yè)務(wù)到現(xiàn)在已經(jīng)迭代一年。

圖片

上圖介紹了這一年來(lái)的語(yǔ)聊房產(chǎn)品迭代的2個(gè)主要階段。

第一個(gè)階段是2022年7月，從0到1的產(chǎn)品探索期。直播已有的互動(dòng)能力比如主播和主播視頻PK，能力模型是圍繞一對(duì)一建設(shè)的。一方發(fā)起另一方接受就可以開(kāi)始互動(dòng)，一方退出這一場(chǎng)互動(dòng)就會(huì)結(jié)束。這種互動(dòng)模型在產(chǎn)品上存在諸多限制，比如無(wú)法支持一個(gè)房間多個(gè)主播同時(shí)互動(dòng)的業(yè)務(wù)。于是為了滿(mǎn)足用戶(hù)需求，我們開(kāi)始探索了多主播間的互動(dòng)能力，包括主播與主播，主播與觀眾的音視頻互動(dòng)的能力。在這個(gè)階段主要目標(biāo)是對(duì)齊競(jìng)品，同時(shí)完善我們開(kāi)播工具的基礎(chǔ)能力，豐富主播互動(dòng)玩法。

第二個(gè)階段是2023年，語(yǔ)聊房項(xiàng)目經(jīng)過(guò)戰(zhàn)略升級(jí)，成為專(zhuān)項(xiàng)進(jìn)行運(yùn)營(yíng)。既是一次巨大的機(jī)會(huì)，又是巨大的挑戰(zhàn)。一方面我們?cè)诠δ軐用媾c競(jìng)品還有明顯的距離。另一方面在技術(shù)架構(gòu)層面，語(yǔ)聊房的架構(gòu)是從主播與主播間互動(dòng)模型演變過(guò)來(lái)，與語(yǔ)聊房主播與用戶(hù)間的互動(dòng)還有很多需要調(diào)整的地方。同時(shí)相比探索期，專(zhuān)項(xiàng)整體迭代節(jié)奏加快，而且對(duì)技術(shù)質(zhì)量要求更高。所以在這個(gè)階段，主要目標(biāo)變成在功能層面快速迭代以滿(mǎn)足用戶(hù)訴求， 同時(shí)技術(shù)架構(gòu)上需要快速調(diào)整以響應(yīng)產(chǎn)品變化。如何又快又好的完成需求，成為這一階段技術(shù)上的主要矛盾。

圖片

上圖介紹了戰(zhàn)略升級(jí)后， 語(yǔ)聊房在用戶(hù)體驗(yàn)升級(jí)與產(chǎn)品迭代上進(jìn)行的具體功能迭代事項(xiàng)。

架構(gòu)演進(jìn)實(shí)踐

直播架構(gòu)體系

語(yǔ)聊房業(yè)務(wù)構(gòu)建與直播體系之上，所以要了解語(yǔ)聊房的架構(gòu)，就必須先了解我們當(dāng)前的直播業(yè)務(wù)和架構(gòu)，才能幫助我們建立全面的認(rèn)識(shí)，更好的理解決策時(shí)的一些思考。

圖片

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

用戶(hù)通過(guò)點(diǎn)擊直播間，進(jìn)入直播間，觀看主播推送的視頻流，同時(shí)可以通過(guò)彈幕，禮物等方式與主播進(jìn)行實(shí)時(shí)互動(dòng)。

圖片

上圖所展示直播架構(gòu)只是當(dāng)前的直播架構(gòu)的冰山一角，完整的架構(gòu)遠(yuǎn)比這個(gè)復(fù)雜。但為了更好的聚焦于語(yǔ)聊房架構(gòu)，我們重點(diǎn)介紹將會(huì)與語(yǔ)聊房有交集的流程和模塊。

術(shù)語(yǔ)介紹

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

主播首先使用B端客戶(hù)端打開(kāi)直播間，然后通過(guò)B端客戶(hù)端采集進(jìn)行直播的內(nèi)容，比如攝像頭，話(huà)筒，游戲程序，屏幕等內(nèi)容，然后將內(nèi)容通過(guò)壓縮編碼成合適的格式推送到視頻云。視頻云需要將接收到的視頻數(shù)據(jù)轉(zhuǎn)換成不同的視頻格式并分發(fā)到全球各地不同的節(jié)點(diǎn)，用來(lái)滿(mǎn)足各地觀眾使用不同的終端，對(duì)分辨率和格式的不同的需求。

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

同時(shí)直播內(nèi)容安全也是非常重要的一環(huán)，我們需要保證觀眾看到的視頻符合法律法規(guī)。所以需要對(duì)主播推送視頻進(jìn)行審核。通過(guò)審核后的內(nèi)容才能推送給用戶(hù)觀看，所以不可避免的會(huì)造成延時(shí)，也就是主播與觀眾的時(shí)間軸不一致。上圖中專(zhuān)門(mén)在每個(gè)環(huán)節(jié)上標(biāo)注了延時(shí)時(shí)間。一方面我們需要延時(shí)來(lái)保證內(nèi)容安全，同時(shí)各個(gè)子系統(tǒng)處理，分發(fā)，流轉(zhuǎn)也需要時(shí)間，另一方面我們又希望提供主播與觀眾實(shí)時(shí)互動(dòng)的能力。畢竟如果用戶(hù)發(fā)完彈幕，幾十秒后才能收到主播反饋，那用戶(hù)體驗(yàn)將會(huì)收到極大影響。這一點(diǎn)對(duì)于實(shí)時(shí)性要求特別高的語(yǔ)聊房業(yè)務(wù)也是一個(gè)難點(diǎn)。

沉淀多人互動(dòng)模型

經(jīng)過(guò)上面的介紹我們已經(jīng)了解了直播的基本架構(gòu)。已有的架構(gòu)數(shù)據(jù)鏈路是主播音視頻數(shù)據(jù)經(jīng)過(guò)視頻云推送給用戶(hù)。舉個(gè)列子就像有一個(gè)舞臺(tái)，主播在舞臺(tái)上表演，用戶(hù)在舞臺(tái)下觀看。主播如果需要和另一個(gè)主播進(jìn)行互動(dòng)，就需要一個(gè)電話(huà)。我們使用的“電話(huà)“就是RTC，我們使用RTC技術(shù)來(lái)解決主播間實(shí)時(shí)音視頻通信的需求。

術(shù)語(yǔ)介紹

• RTC（Real-time Communications）實(shí)時(shí)通訊。RTC是對(duì)實(shí)時(shí)通信的更加寬泛的統(tǒng)稱(chēng)，包含H323 SIP 私有協(xié)議等等通信標(biāo)準(zhǔn)，涵蓋從端，服務(wù)器，支撐系統(tǒng)等一整套的通信標(biāo)準(zhǔn)，通信的形式包括實(shí)時(shí)語(yǔ)音，實(shí)時(shí)視頻，實(shí)時(shí)文本等。

在做主播多人連線(xiàn)之前，已有的互動(dòng)模式包括主播和主播視頻連線(xiàn)，主播和用戶(hù)連麥等功能都是一對(duì)一互動(dòng)模型。主播邀請(qǐng)另一個(gè)主播或用戶(hù)發(fā)起一次視頻連線(xiàn)或語(yǔ)音連麥，另一方同意即開(kāi)始互動(dòng)。然后其中一方退出本次互動(dòng)狀態(tài)就變?yōu)榻Y(jié)束。顯而易見(jiàn)，這無(wú)法滿(mǎn)足下圖這種類(lèi)似于聊天室，主播可以邀請(qǐng)多人同時(shí)互動(dòng)的業(yè)務(wù)需求。

圖片

所以我們首先需要分離出場(chǎng)次和會(huì)話(huà)的概念。

主播首先創(chuàng)建一個(gè)互動(dòng)場(chǎng)次，場(chǎng)次之內(nèi)可以分別邀請(qǐng)多個(gè)主播，單個(gè)主播的加入離開(kāi)對(duì)應(yīng)會(huì)話(huà)概念?；趫?chǎng)次與會(huì)話(huà)的抽象，主播可以創(chuàng)建場(chǎng)次后邀請(qǐng)多個(gè)主播同時(shí)進(jìn)行視頻連線(xiàn)。即使場(chǎng)次創(chuàng)建人退出，場(chǎng)次仍然可以存在。

術(shù)語(yǔ)介紹

• 場(chǎng)次： 場(chǎng)次是多人互動(dòng)中的基本單位，通常表示一次互動(dòng)活動(dòng)，場(chǎng)次由主播創(chuàng)建，主播可以通過(guò)申請(qǐng)或邀請(qǐng)與其他主播進(jìn)行實(shí)時(shí)視頻交流。
• 會(huì)話(huà)：會(huì)話(huà)是場(chǎng)次的基本單位，通常一個(gè)場(chǎng)次關(guān)聯(lián)多個(gè)會(huì)話(huà)，一個(gè)用戶(hù)的一次加入與離開(kāi)對(duì)應(yīng)一次會(huì)話(huà)的建立與結(jié)束
• 頻道： 主播與RTC服務(wù)端鏈接的資源標(biāo)識(shí)， 通常一個(gè)會(huì)話(huà)與一個(gè)頻道一一對(duì)應(yīng)，每個(gè)頻道都有一個(gè)唯一的頻道ID，用戶(hù)可以通過(guò)頻道ID加入到指定的頻道中。

圖片

上圖是新增場(chǎng)次，會(huì)話(huà)，頻道等領(lǐng)域之后的多人互動(dòng)模型業(yè)務(wù)架構(gòu)圖，與上面直播業(yè)務(wù)架構(gòu)相比，我們屏蔽了推流到觀看過(guò)程細(xì)節(jié)，重點(diǎn)關(guān)注與rtc相關(guān)的業(yè)務(wù)交互。

當(dāng)主播使用互動(dòng)功能時(shí)，客戶(hù)端將rtc音視頻數(shù)據(jù)作為一個(gè)采集源， 與其它的采集源數(shù)據(jù)合成后推送給視頻云，最后用戶(hù)拉取視頻流觀看。

圖片

這里又引出了一個(gè)新的問(wèn)題，既然主播間可以使用rtc進(jìn)行實(shí)時(shí)音視頻互動(dòng)，那用戶(hù)也接入rtc，是否就可以不經(jīng)過(guò)視頻云直接觀看主播的直播？

答案是yes。業(yè)內(nèi)也有很多互動(dòng)直播間只基于rtc的能力實(shí)現(xiàn)。但是顯而易見(jiàn)，作為探索性業(yè)務(wù)，基于實(shí)現(xiàn)成本的考慮，作為旁路系統(tǒng)接入的實(shí)現(xiàn)成本遠(yuǎn)遠(yuǎn)低于改造整條鏈路。但帶來(lái)的缺點(diǎn)就是，業(yè)務(wù)服務(wù)需要同時(shí)考慮2套系統(tǒng)的狀態(tài)的一致性。這個(gè)狀態(tài)一致性也會(huì)在后面給系統(tǒng)的演進(jìn)帶來(lái)更多的挑戰(zhàn)。

圖片

上圖是基于業(yè)務(wù)架構(gòu)圖所對(duì)應(yīng)的應(yīng)用架構(gòu)圖

我們?cè)诜?wù)層增加新的服務(wù)，用來(lái)處理場(chǎng)次，會(huì)話(huà)和rtc渠道的關(guān)系。

B2B擴(kuò)展到B2C

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

圖片

我們認(rèn)為社交是促進(jìn)主播開(kāi)播的一個(gè)契機(jī)。，語(yǔ)音聊天是非常重要的社交場(chǎng)景，有助于激發(fā)主播開(kāi)播動(dòng)機(jī)。

為了支持產(chǎn)品訴求，我們架構(gòu)上需要做出如下的調(diào)整：

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

圖片

上圖是經(jīng)過(guò)調(diào)整后的多人語(yǔ)聊業(yè)務(wù)架構(gòu)圖，相比多人互動(dòng)架構(gòu)圖，我們屏蔽了rtc相關(guān)的交互細(xì)節(jié)，重點(diǎn)關(guān)注擴(kuò)展到C端用戶(hù)后系統(tǒng)架構(gòu)的變化。

首先是互動(dòng)能力擴(kuò)展到移動(dòng)客戶(hù)端， 產(chǎn)品層面支持C端用戶(hù)參與互動(dòng)。我們根據(jù)用戶(hù)是否參加互動(dòng)，區(qū)分用戶(hù)為觀眾態(tài)和互動(dòng)態(tài)。

觀眾態(tài)：用戶(hù)不加入rtc頻道，通過(guò)視頻云拉取主播推送的視頻流，流里包含所有互動(dòng)用戶(hù)的rtc音頻流。

互動(dòng)態(tài)：用戶(hù)不拉取視頻云視頻流， 通過(guò)rtc音頻流參與互動(dòng)

圖片

然后是基于RBAC模型的用戶(hù)權(quán)限設(shè)計(jì)。增加角色控制不同主播，管理員，用戶(hù)的權(quán)限。

術(shù)語(yǔ)定義

• 用戶(hù)：發(fā)起操作的主體，按類(lèi)型可分為2B和2C用戶(hù)，在語(yǔ)聊房場(chǎng)景中包括主播，房間管理員，用戶(hù)，審核人員，后臺(tái)管理等
• 角色：連接了用戶(hù)和權(quán)限的關(guān)系，每個(gè)角色可以關(guān)聯(lián)多個(gè)權(quán)限，同時(shí)一個(gè)用戶(hù)關(guān)聯(lián)多角色
• 權(quán)限：用戶(hù)可以訪問(wèn)的資源，包括操作權(quán)限，數(shù)據(jù)權(quán)限等。在語(yǔ)聊房場(chǎng)景中包括上下麥行為，玩法管理等。

最后是打通送禮鏈路， 以前觀眾只能給主播送禮，現(xiàn)在支持參與互動(dòng)的用戶(hù)送禮，這樣也能提升用戶(hù)互動(dòng)意愿。

麥位管理云端化

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

參考上圖多人互動(dòng)業(yè)務(wù)示意圖，主播的視頻會(huì)固定在視頻流左側(cè)，右側(cè)四個(gè)小格展示加入互動(dòng)的其他主播。

參考上圖語(yǔ)聊房業(yè)務(wù)示意圖，主播固定在上方區(qū)域，下方2排共8個(gè)圓圈展示參與互動(dòng)的用戶(hù)頭像。

麥位管理包括互動(dòng)用戶(hù)位置的分配，操作按鈕展示與控制，比如靜音，踢人，是否說(shuō)話(huà)中狀態(tài)展示等邏輯。

然后是問(wèn)題的關(guān)鍵， 云端化對(duì)應(yīng)的是本地化。最早設(shè)計(jì)時(shí)這些邏輯會(huì)什么會(huì)放到客戶(hù)端上來(lái)做？這個(gè)問(wèn)題還要從多主播互動(dòng)這個(gè)業(yè)務(wù)來(lái)回答，多主播互動(dòng)中每個(gè)房間5個(gè)位置，最多5個(gè)房間一起互動(dòng)，一共5X5=25個(gè)位置。同時(shí)每次互動(dòng)用戶(hù)上下麥，都會(huì)導(dǎo)致25個(gè)位置渲染發(fā)生變化。另一方面早期的麥位控制也比較簡(jiǎn)單。不包括復(fù)雜的位置分配等邏輯。所以當(dāng)時(shí)評(píng)估下來(lái)放在客戶(hù)端上實(shí)現(xiàn)比服務(wù)端實(shí)現(xiàn)成本低。等到多人語(yǔ)聊業(yè)務(wù)上線(xiàn)以后，最初的實(shí)現(xiàn)已經(jīng)無(wú)法滿(mǎn)足復(fù)雜的麥位管理控制需求了。所以我們需要將麥位分配與控制邏輯從客戶(hù)端遷移到服務(wù)端。

控制權(quán)的轉(zhuǎn)移

從客戶(hù)端遷移到服務(wù)端的關(guān)鍵點(diǎn)在于控制權(quán)的轉(zhuǎn)移。將之前麥位數(shù)據(jù)從B端產(chǎn)生，通過(guò)透?jìng)魍ǖ劳扑偷紺端消費(fèi)。變成由B端和C端發(fā)送數(shù)據(jù)到服務(wù)端，服務(wù)端進(jìn)行計(jì)算，存儲(chǔ)和推送。同時(shí)架構(gòu)升級(jí)過(guò)程中，需要兼容新老版本組合情況，保證程序向后兼容，不影響線(xiàn)上產(chǎn)品已有功能。

圖片

眾所周知，兼容性與代碼邏輯和數(shù)據(jù)結(jié)構(gòu)密切相關(guān)。新的代碼會(huì)產(chǎn)生新的數(shù)據(jù)結(jié)構(gòu)，同時(shí)要兼容老的數(shù)據(jù)結(jié)構(gòu)與邏輯。老的代碼處理不了新的數(shù)據(jù)結(jié)構(gòu)，需要通過(guò)版本做訪問(wèn)隔離。遷移過(guò)程中代碼與數(shù)據(jù)組合情況與測(cè)試點(diǎn)：

主播與用戶(hù)的實(shí)時(shí)狀態(tài)同步

麥位管理功能統(tǒng)一到服務(wù)端后，帶來(lái)的好處是業(yè)務(wù)擴(kuò)展更容易，方便我們擴(kuò)展更多的功能。但同樣也因?yàn)樗袛?shù)據(jù)都需要到服務(wù)端來(lái)獲取，對(duì)于服務(wù)端的接口性能和實(shí)時(shí)性帶來(lái)了巨大的壓力。特別是當(dāng)存在類(lèi)似于賽事或者活動(dòng)等大型熱門(mén)房間，百萬(wàn)用戶(hù)同時(shí)在線(xiàn)時(shí)，實(shí)時(shí)狀態(tài)同步將是一個(gè)巨大的挑戰(zhàn)。

圖片

我們通過(guò)組合使用多個(gè)渠道，利用各自特點(diǎn)來(lái)平衡實(shí)時(shí)性與性能開(kāi)銷(xiāo)之間的矛盾。

• 基于長(zhǎng)鏈接消息的全量狀態(tài)同步。主動(dòng)push，延遲在毫秒級(jí)，但無(wú)法保證必達(dá)。
• 基于push的推拉結(jié)合方案，在長(zhǎng)鏈接不穩(wěn)定的情況下， 基于接口被動(dòng)輪詢(xún)，延遲在秒級(jí)，同時(shí)服務(wù)端性能開(kāi)銷(xiāo)大。
• 針對(duì)性能開(kāi)銷(xiāo)大的問(wèn)題，增加網(wǎng)關(guān)層內(nèi)存緩存，匯聚相同房間的請(qǐng)求，減少透?jìng)鞯綐I(yè)務(wù)服務(wù)端的壓力
• 基于視頻流里SEI，針對(duì)未登錄用戶(hù)，非重點(diǎn)保障場(chǎng)景等場(chǎng)景，使用視頻流里SEI攜帶數(shù)據(jù)來(lái)進(jìn)行同步，延遲是10秒級(jí)別但是性能開(kāi)銷(xiāo)非常小，作為最后的兜底
• 客戶(hù)端收到不同渠道來(lái)源的數(shù)據(jù)，基于數(shù)據(jù)的版本進(jìn)行排序，避免消費(fèi)數(shù)據(jù)時(shí)出現(xiàn)亂序

互動(dòng)玩法引擎

經(jīng)過(guò)上述一系列調(diào)整以后， 業(yè)務(wù)架構(gòu)基礎(chǔ)性比較穩(wěn)定，開(kāi)始探索語(yǔ)聊房?jī)?nèi)營(yíng)收相關(guān)玩法。

圖片

圖片

通過(guò)在已有的送禮鏈路上，疊加玩法生命周期管理，分?jǐn)?shù)計(jì)數(shù)，狀態(tài)轉(zhuǎn)移。構(gòu)建玩法生態(tài)。

圖片

生產(chǎn)配套體系

【全鏈路應(yīng)用監(jiān)控】

圖片

一個(gè)成熟的系統(tǒng)是一定需要一個(gè)無(wú)死角的觀測(cè)能力，在任何領(lǐng)域都是這樣。醫(yī)療、航空，包括人體系統(tǒng)。

將應(yīng)用系統(tǒng)監(jiān)控進(jìn)行分層，可以分為如下幾層：

1、基礎(chǔ)設(shè)施監(jiān)控（CPU、內(nèi)存、網(wǎng)絡(luò)、機(jī)房等）。這一層是任何計(jì)算機(jī)應(yīng)用的基礎(chǔ)依賴(lài)。

2、請(qǐng)求和成功率監(jiān)控（QPS/TPS、RT、SLO等）。這一層主要是觀測(cè)請(qǐng)求的數(shù)量和成功率。

3、業(yè)務(wù)監(jiān)控（業(yè)務(wù)漏斗轉(zhuǎn)化、業(yè)務(wù)狀態(tài)扭轉(zhuǎn)等）。這一層主要是觀測(cè)業(yè)務(wù)系統(tǒng)內(nèi)部的邏輯分支。

一般系統(tǒng)監(jiān)控上述1、2層基本是默認(rèn)都有的平臺(tái)設(shè)施。作為業(yè)務(wù)系統(tǒng)，只有1、2層是不夠的，1、2層監(jiān)控?zé)o法感知業(yè)務(wù)異動(dòng)。簡(jiǎn)單講，如果你寫(xiě)了一個(gè)在業(yè)務(wù)上有問(wèn)題的分支代碼，此代碼不會(huì)產(chǎn)生任何錯(cuò)誤code。這類(lèi)問(wèn)題，可能1、2層監(jiān)控是毫無(wú)察覺(jué)的，因?yàn)?、2層不觀測(cè)這些。業(yè)務(wù)監(jiān)控，一方面可以感知業(yè)務(wù)異動(dòng)，還可以感知到1、2層故障帶來(lái)的業(yè)務(wù)影響。

【開(kāi)播互動(dòng)問(wèn)診】

圖片

用戶(hù)看到的產(chǎn)品功能，可能只是冰山上面很小的部分。冰山下面部分是一個(gè)龐大的系統(tǒng)，會(huì)跨越多個(gè)微服務(wù)單元。語(yǔ)聊房是非常典型的多技術(shù)棧（app、pc、web、RTC、comet長(zhǎng)鏈、業(yè)務(wù)后端等） ，多業(yè)務(wù)單元（語(yǔ)聊房業(yè)務(wù)后端、看播、開(kāi)播、審核-工程、審核工作臺(tái)、視頻云、RTC等）合作的超大型項(xiàng)目。

人工排查一個(gè)問(wèn)題的成本是非常高的。在項(xiàng)目初上線(xiàn)時(shí)，當(dāng)時(shí)的相關(guān)系統(tǒng)配套并不完善，一個(gè)小問(wèn)題都要把業(yè)務(wù)鏈條上的所有環(huán)節(jié)的人都要拉上一起排查。通過(guò)問(wèn)診平臺(tái)可以一鍵全鏈路觀測(cè)到所有節(jié)點(diǎn)。

圖片

圖片

可以看到一個(gè)用戶(hù)的所有生命周期，對(duì)于排障基本可以節(jié)省90%時(shí)間。

底層思維

上面介紹完語(yǔ)聊房業(yè)務(wù)形態(tài)和系統(tǒng)架構(gòu)一年以來(lái)的變遷。我們了解了因?yàn)楫a(chǎn)品形態(tài)調(diào)整，架構(gòu)需要調(diào)整來(lái)適配新的產(chǎn)品形態(tài)。有些調(diào)整短期是好的，但長(zhǎng)期又花了更多時(shí)間處理新來(lái)的問(wèn)題有些調(diào)整踩了一些坑。為了技術(shù)現(xiàn)狀或者工時(shí)排期要求原因?qū)е碌募軜?gòu)妥協(xié)，然后事后又付出更多的工時(shí)成本遷移?；剡^(guò)頭來(lái)想想是什么原因?qū)е挛覀兊囊延屑軜?gòu)在變動(dòng)產(chǎn)品形態(tài)調(diào)整時(shí)，總是在償還已有技術(shù)債務(wù)，或者自己挖了新坑自己再去填坑？

互聯(lián)網(wǎng)從業(yè)人員可能最討厭的一個(gè)詞就是“變化“。產(chǎn)品需求變了，導(dǎo)致技術(shù)方案需要調(diào)整，代碼需要重寫(xiě)。代碼改動(dòng)了，測(cè)試用例又得重新設(shè)計(jì)。工作量增加又導(dǎo)致項(xiàng)目時(shí)間調(diào)整，輕則軟件bug，重則項(xiàng)目失控。

那么有沒(méi)有通用的萬(wàn)能法則可以指導(dǎo)我們進(jìn)行架構(gòu)演進(jìn)的，以不變應(yīng)萬(wàn)變，真正又好又快？看過(guò)或者聽(tīng)過(guò)“沒(méi)有銀彈“這句話(huà)的人，可能已經(jīng)知道問(wèn)題的答案了。但是為什么沒(méi)有呢？探討一個(gè)可以解釋萬(wàn)事萬(wàn)物的萬(wàn)能法則，不管是誰(shuí)聽(tīng)了都會(huì)熱血澎湃。古人也不例外，早在兩千多年前，古希臘哲學(xué)家亞里士多德認(rèn)為在各種物理規(guī)則的基礎(chǔ)上，還有一種東西可以統(tǒng)轄和解釋所有的物理規(guī)則。在他的作品集中，把他對(duì)邏輯、含義和原因等抽象知識(shí)的討論編排在他討論物理學(xué)的書(shū)冊(cè)《自然學(xué)》之后，并給這些討論一個(gè)標(biāo)簽：《在自然學(xué)之后》（τ? μετ? τ? φυσικ? βιβλ?α）。從古希臘文翻譯到英文，于是就有了Metaphysics這個(gè)詞，看到這個(gè)詞就會(huì)聯(lián)想到最近很火的Metaverse，還有改名為Meta的Facebook。如果按照元宇宙的譯法，那么metaphysics就可以翻譯為“元物理”。但日本人在翻譯這個(gè)詞語(yǔ)時(shí)，從《易經(jīng) 》找到了 “形而上者謂之道，形而下者謂之器”一詞。于是Metaphysics便翻譯成了大家耳熟能詳?shù)植惶私獾摹靶味蠈W(xué)”這一詞。

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

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

我們都知道，不管是做技術(shù)架構(gòu)，還是代碼結(jié)構(gòu)組成方式，都反應(yīng)了我們對(duì)產(chǎn)品的認(rèn)知。如果沒(méi)有恰當(dāng)?shù)恼J(rèn)知，就不可能做出合適的架構(gòu)，甚至可能會(huì)導(dǎo)致項(xiàng)目徹底失敗。既然沒(méi)有永恒不變的“道“，那我們應(yīng)該用什么樣認(rèn)知來(lái)指導(dǎo)我們的行動(dòng)呢？

這個(gè)問(wèn)題在《實(shí)踐論》中做出了回答：

通過(guò)實(shí)踐而發(fā)現(xiàn)真理，又通過(guò)實(shí)踐而證實(shí)真理和發(fā)展真理。從感性認(rèn)識(shí)而能動(dòng)地發(fā)展到理性認(rèn)識(shí)，又從理性認(rèn)識(shí)而能動(dòng)地指導(dǎo)革命實(shí)踐，改造主觀世界和客觀世界。實(shí)踐、認(rèn)識(shí)、再實(shí)踐、再認(rèn)識(shí)，這種形式，循環(huán)往復(fù)以至無(wú)窮，而實(shí)踐和認(rèn)識(shí)之每一循環(huán)的內(nèi)容，都比較地進(jìn)到了高一級(jí)的程度。這就是辯證唯物論的全部認(rèn)識(shí)論，這就是辯證唯物論的知行統(tǒng)一觀。

下面我將結(jié)合語(yǔ)聊房實(shí)際業(yè)務(wù)聊聊到對(duì)這幾個(gè)階段的認(rèn)識(shí)。

從直接經(jīng)驗(yàn)到感性認(rèn)識(shí)

眾所周知，互聯(lián)網(wǎng)產(chǎn)品是對(duì)我們生活或者生產(chǎn)過(guò)程中的抽象，除了極少數(shù)天才級(jí)的產(chǎn)品大師能夠設(shè)計(jì)出引領(lǐng)人類(lèi)社會(huì)的產(chǎn)品，大多數(shù)的產(chǎn)品還只是打破時(shí)間和空間的限制，滿(mǎn)足人類(lèi)社會(huì)的需求。

下面是我們常用的一些產(chǎn)品對(duì)現(xiàn)實(shí)生活中的實(shí)現(xiàn)。

圖片

圖片

圖片

圖片

同樣的道理，語(yǔ)聊房這個(gè)產(chǎn)品也不是憑空產(chǎn)生的，聊天的需求一樣存在于現(xiàn)實(shí)生活中

圖片

圖片

現(xiàn)實(shí)世界的場(chǎng)景是個(gè)例化的，與實(shí)際產(chǎn)品還有很大的鴻溝。首先了解現(xiàn)實(shí)世界的運(yùn)行邏輯，具有初步的感性認(rèn)識(shí)后，我們需要進(jìn)一步抽象成通用型的業(yè)務(wù)模型。然后通過(guò)觀察競(jìng)品的類(lèi)似產(chǎn)品的實(shí)現(xiàn)也有助于幫助我們建立感性認(rèn)識(shí)。經(jīng)過(guò)這個(gè)階段，我們會(huì)對(duì)架構(gòu)產(chǎn)生初步的概念。

從感性認(rèn)識(shí)到理性認(rèn)識(shí)

現(xiàn)實(shí)的情況和競(jìng)品的實(shí)現(xiàn)幫助我們建立初步感性認(rèn)識(shí)，通過(guò)對(duì)這些感性認(rèn)識(shí)的整理，加以概念定義，類(lèi)型歸類(lèi)，邏輯重組等階段就能建立初步理性認(rèn)識(shí)。但不同競(jìng)品的商業(yè)模式，品牌調(diào)性以及完成度都會(huì)與我們千差萬(wàn)別，直接全盤(pán)照抄往往是失敗的前兆，同時(shí)工期上也是不可接受的。通過(guò)與產(chǎn)運(yùn)規(guī)劃對(duì)齊，理清實(shí)現(xiàn)路徑，幫助我們了解每個(gè)階段的主要目標(biāo)和主要矛盾。

圖片

到這個(gè)階段，我們已經(jīng)對(duì)所要做的事情有了初步的理性判斷，這有助于我們下一步架構(gòu)落地。

理性認(rèn)識(shí)用于指導(dǎo)行動(dòng)實(shí)踐

抽象與統(tǒng)一認(rèn)知

抽象是指從具體的事物中抽離出共性的概念或特點(diǎn)，將它們提煉出來(lái)形成一種抽象的概念或理論。計(jì)算機(jī)領(lǐng)域有一句名言，“任何問(wèn)題都可以通過(guò)增加一層間接的中間層來(lái)解決“。原因就在于人的認(rèn)知能力是有限的，抽象有助于降低我們理解復(fù)雜事物的成本。但是抽象同樣也會(huì)帶來(lái)模糊實(shí)現(xiàn)的問(wèn)題。當(dāng)我提起“馬“， 我可能指的是河馬，你腦海中可能想到的是斑馬。所以我們需要，通過(guò)顯示的定義概念來(lái)統(tǒng)一語(yǔ)言，幫助我們更好地溝通和理解彼此的意思，才能做到團(tuán)隊(duì)理解一致性。在領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)中，抽象和統(tǒng)一語(yǔ)言是非常重要的概念，它們可以幫助我們更好地理解和設(shè)計(jì)領(lǐng)域模型，從而創(chuàng)建高質(zhì)量的軟件系統(tǒng)。

面向領(lǐng)域設(shè)計(jì)

語(yǔ)言只有在特定語(yǔ)境中才有意義，在不同語(yǔ)境中同一個(gè)概念往往會(huì)有不同的意義。特定語(yǔ)境往往對(duì)應(yīng)確定的業(yè)務(wù)模型，比如同樣是“訂單”，在秒殺領(lǐng)域，拼單領(lǐng)域，團(tuán)購(gòu)領(lǐng)域等往往代表著不同的業(yè)務(wù)流程和現(xiàn)實(shí)意義。在代碼實(shí)現(xiàn)上，我們通過(guò)package，class等方式來(lái)進(jìn)行模塊劃分。在領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)中，我們通過(guò)限界上下文來(lái)保證領(lǐng)域內(nèi)概念的一致性。

圖片

在不同的BoundContext（限界上下文）中，同樣的一個(gè)名詞代表不同的業(yè)務(wù)模型或者模型的不同維度。

拿【語(yǔ)聊房間】來(lái)說(shuō)，在內(nèi)容安全Subdomain → 審核BoundContext中，這個(gè)【房間實(shí)體】是有著特定字端的（房間管控等級(jí)、是否需要認(rèn)證手機(jī)號(hào)、是否大陸身份等）。這些字端是【語(yǔ)聊房間】概念實(shí)體在安全領(lǐng)域上下文中的特定表現(xiàn)。在整個(gè)開(kāi)發(fā)架構(gòu)上，我們也是參考領(lǐng)域來(lái)劃分每個(gè)模塊的職責(zé)邊界。

圖片

領(lǐng)域模型是逐步下沉的業(yè)務(wù)載體，彼此獨(dú)立。最終通過(guò)在usercase 層 application來(lái)組裝編排領(lǐng)域模型。

隨著行動(dòng)實(shí)踐的過(guò)程中調(diào)整理性認(rèn)識(shí)

對(duì)業(yè)務(wù)問(wèn)題空間求解是軟件開(kāi)發(fā)的首要問(wèn)題。通過(guò)對(duì)問(wèn)題空間的不斷定義與探索，我們映射得到對(duì)應(yīng)解空間的系統(tǒng)架構(gòu)與應(yīng)用架構(gòu)。這一階段主要目標(biāo)是持續(xù)交付我們的架構(gòu)。

最小迭代和增量更新

圖片

在網(wǎng)上流傳廣泛的介紹MVP的圖。

先制作出一個(gè)最小可行的產(chǎn)品（例如小型滑板車(chē)或自行車(chē)），測(cè)試用戶(hù)對(duì)其概念的認(rèn)可程度，再根據(jù)反饋來(lái)決定如何進(jìn)一步完善產(chǎn)品。MVP策略的優(yōu)點(diǎn)在于試錯(cuò)成本低速度快風(fēng)險(xiǎn)低，能夠滿(mǎn)足快速迭代的需求。

風(fēng)險(xiǎn)基線(xiàn)

隨著架構(gòu)的演進(jìn)，我們需要有合適的評(píng)估機(jī)制，來(lái)評(píng)估變化對(duì)架構(gòu)的影響，防止架構(gòu)隨著時(shí)間推移而退化。架構(gòu)由很多維度構(gòu)成，包括性能，安全性，穩(wěn)定性，代碼規(guī)范等，對(duì)于不同的維度，我們需要建立不同的指標(biāo)來(lái)評(píng)估。

在開(kāi)發(fā)架構(gòu)管理上，進(jìn)行代碼級(jí)別的保障，包括以下措施：

在CICD上增加代碼質(zhì)量檢查，保證代碼符合規(guī)范：

圖片

在自動(dòng)化測(cè)試平臺(tái)上，與測(cè)試團(tuán)隊(duì)共建自動(dòng)化測(cè)試用例，覆蓋全部關(guān)鍵場(chǎng)景用例，保證每次代碼變更不會(huì)產(chǎn)生預(yù)期外的業(yè)務(wù)影響：

圖片

Devops方面，對(duì)關(guān)鍵接口P999響應(yīng)時(shí)間進(jìn)行監(jiān)控，保證系統(tǒng)性能不劣化：

圖片

每日自動(dòng)巡檢，保證服務(wù)健康度：

圖片

參考文章

• 企業(yè)級(jí)業(yè)務(wù)架構(gòu)設(shè)計(jì)：方法論與實(shí)踐（https://weread.qq.com/web/bookDetail/b20326d0718f6395b20f4af）
• 演進(jìn)式架構(gòu)（https://weread.qq.com/web/bookDetail/29b32c7071c9562629b5940）
• 解構(gòu)領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)（https://weread.qq.com/web/bookDetail/4fc328a0729350754fc56d4）
• 持續(xù)交付：發(fā)布可靠軟件的系統(tǒng)方法（https://weread.qq.com/web/bookDetail/44232e40717db787442af8a）

本期作者

朱德江嗶哩嗶哩資深開(kāi)發(fā)工程師

王清培嗶哩嗶哩資深開(kāi)發(fā)工程師

趙書(shū)彬嗶哩嗶哩高級(jí)開(kāi)發(fā)工程師