序言

羅馬不是一天建成的。語聊房當前架構(gòu)也是不斷演進的結(jié)果。

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

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

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

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

語聊房來龍去脈

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

圖片

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

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

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

圖片

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

架構(gòu)演進實踐

直播架構(gòu)體系

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

圖片

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

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

圖片

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

術(shù)語介紹

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

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

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

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

沉淀多人互動模型

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

術(shù)語介紹

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

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

圖片

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

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

術(shù)語介紹

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

圖片

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

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

圖片

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

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

圖片

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

我們在服務(wù)層增加新的服務(wù)，用來處理場次，會話和rtc渠道的關(guān)系。

B2B擴展到B2C

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

圖片

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

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

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

圖片

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

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

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

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

圖片

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

術(shù)語定義

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

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

麥位管理云端化

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

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

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

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

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

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

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

圖片

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

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

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

圖片

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

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

互動玩法引擎

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

圖片

圖片

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

圖片

生產(chǎn)配套體系

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

圖片

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

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

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

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

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

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

【開播互動問診】

圖片

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

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

圖片

圖片

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

底層思維

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

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

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

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

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

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

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

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

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

從直接經(jīng)驗到感性認識

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

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

圖片

圖片

圖片

圖片

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

圖片

圖片

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

從感性認識到理性認識

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

圖片

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

理性認識用于指導(dǎo)行動實踐

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

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

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

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

圖片

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

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

圖片

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

隨著行動實踐的過程中調(diào)整理性認識

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

最小迭代和增量更新

圖片

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

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

風(fēng)險基線

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

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

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

圖片

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

圖片

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

圖片

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

圖片

參考文章

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

本期作者

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

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

趙書彬嗶哩嗶哩高級開發(fā)工程師