對標(biāo)蘋果的靈動島 華為帶來實況窗功能
繼蘋果的靈動島之后，華為也在今天正式推出了“實況窗”功能。據(jù)今天鴻蒙OS 4.0的現(xiàn)場演示顯示，華為的實況窗可以更高效的展現(xiàn)出實時通知，比如鎖屏上就能看到外賣、打車、銀行
羅馬不是一天建成的。語聊房當(dāng)前架構(gòu)也是不斷演進(jìn)的結(jié)果。
在技術(shù)架構(gòu)層面，語聊房作為搭建在直播體系上的業(yè)務(wù)，使用既有技術(shù)架構(gòu)體系可以幫助我們快速搭建早期產(chǎn)品，但隨著業(yè)務(wù)迭代，已有技術(shù)體系又成為新的技術(shù)架構(gòu)的負(fù)債。
同樣在業(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ù)演進(jìn)的過程，談?wù)剺I(yè)務(wù)視角下的架構(gòu)演進(jìn)。以及如何構(gòu)建能應(yīng)對各種變化的系統(tǒng)，不斷達(dá)到新的平衡。
了解架構(gòu)演進(jìn)之前，我們先了解語聊房業(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ù)。于是為了滿足用戶需求，我們開始探索了多主播間的互動能力，包括主播與主播，主播與觀眾的音視頻互動的能力。在這個階段主要目標(biāo)是對齊競品，同時完善我們開播工具的基礎(chǔ)能力，豐富主播互動玩法。
第二個階段是2023年，語聊房項目經(jīng)過戰(zhàn)略升級，成為專項進(jìn)行運營。既是一次巨大的機會，又是巨大的挑戰(zhàn)。一方面我們在功能層面與競品還有明顯的距離。另一方面在技術(shù)架構(gòu)層面，語聊房的架構(gòu)是從主播與主播間互動模型演變過來，與語聊房主播與用戶間的互動還有很多需要調(diào)整的地方。同時相比探索期，專項整體迭代節(jié)奏加快，而且對技術(shù)質(zhì)量要求更高。所以在這個階段，主要目標(biāo)變成在功能層面快速迭代以滿足用戶訴求， 同時技術(shù)架構(gòu)上需要快速調(diào)整以響應(yīng)產(chǎn)品變化。如何又快又好的完成需求，成為這一階段技術(shù)上的主要矛盾。
圖片
上圖介紹了戰(zhàn)略升級后， 語聊房在用戶體驗升級與產(chǎn)品迭代上進(jìn)行的具體功能迭代事項。
語聊房業(yè)務(wù)構(gòu)建與直播體系之上，所以要了解語聊房的架構(gòu)，就必須先了解我們當(dāng)前的直播業(yè)務(wù)和架構(gòu)，才能幫助我們建立全面的認(rèn)識，更好的理解決策時的一些思考。
圖片
上圖是典型的直播業(yè)務(wù)UI視圖，中間部分為視頻流播放器，上方為主播信息，榜單等信息，下方包括房間公告，彈幕互動，底部互動按鈕等業(yè)務(wù)信息。
用戶通過點擊直播間，進(jìn)入直播間，觀看主播推送的視頻流，同時可以通過彈幕，禮物等方式與主播進(jìn)行實時互動。
圖片
上圖所展示直播架構(gòu)只是當(dāng)前的直播架構(gòu)的冰山一角，完整的架構(gòu)遠(yuǎn)比這個復(fù)雜。但為了更好的聚焦于語聊房架構(gòu)，我們重點介紹將會與語聊房有交集的流程和模塊。
主播首先使用B端客戶端打開直播間，然后通過B端客戶端采集進(jìn)行直播的內(nèi)容，比如攝像頭，話筒，游戲程序，屏幕等內(nèi)容，然后將內(nèi)容通過壓縮編碼成合適的格式推送到視頻云。視頻云需要將接收到的視頻數(shù)據(jù)轉(zhuǎn)換成不同的視頻格式并分發(fā)到全球各地不同的節(jié)點，用來滿足各地觀眾使用不同的終端，對分辨率和格式的不同的需求。
介紹完B端這一系列流程后，下面就是觀眾使用C端客戶端進(jìn)入直播間。首先需要請求業(yè)務(wù)服務(wù)器P0和P1接口，P0接口會根據(jù)C端用戶位置，終端設(shè)備，分辨率等維度，返回視頻拉流地址，同時C端客戶端也會根據(jù)視頻橫豎屏類型，房間類型等渲染出相關(guān)的視頻內(nèi)容進(jìn)行播放。P1接口會根據(jù)房間和用戶屬性維度，返回當(dāng)前房間相關(guān)的直播業(yè)務(wù)信息，比如房間分區(qū)，不同分區(qū)往往對應(yīng)不同的業(yè)務(wù)玩法等。
同時直播內(nèi)容安全也是非常重要的一環(huán)，我們需要保證觀眾看到的視頻符合法律法規(guī)。所以需要對主播推送視頻進(jìn)行審核。通過審核后的內(nèi)容才能推送給用戶觀看，所以不可避免的會造成延時，也就是主播與觀眾的時間軸不一致。上圖中專門在每個環(huán)節(jié)上標(biāo)注了延時時間。一方面我們需要延時來保證內(nèi)容安全，同時各個子系統(tǒng)處理，分發(fā)，流轉(zhuǎn)也需要時間，另一方面我們又希望提供主播與觀眾實時互動的能力。畢竟如果用戶發(fā)完彈幕，幾十秒后才能收到主播反饋，那用戶體驗將會收到極大影響。這一點對于實時性要求特別高的語聊房業(yè)務(wù)也是一個難點。
經(jīng)過上面的介紹我們已經(jīng)了解了直播的基本架構(gòu)。已有的架構(gòu)數(shù)據(jù)鏈路是主播音視頻數(shù)據(jù)經(jīng)過視頻云推送給用戶。舉個列子就像有一個舞臺，主播在舞臺上表演，用戶在舞臺下觀看。主播如果需要和另一個主播進(jìn)行互動，就需要一個電話。我們使用的“電話“就是RTC，我們使用RTC技術(shù)來解決主播間實時音視頻通信的需求。
在做主播多人連線之前，已有的互動模式包括主播和主播視頻連線，主播和用戶連麥等功能都是一對一互動模型。主播邀請另一個主播或用戶發(fā)起一次視頻連線或語音連麥，另一方同意即開始互動。然后其中一方退出本次互動狀態(tài)就變?yōu)榻Y(jié)束。顯而易見，這無法滿足下圖這種類似于聊天室，主播可以邀請多人同時互動的業(yè)務(wù)需求。
圖片
所以我們首先需要分離出場次和會話的概念。
主播首先創(chuàng)建一個互動場次，場次之內(nèi)可以分別邀請多個主播，單個主播的加入離開對應(yīng)會話概念。基于場次與會話的抽象，主播可以創(chuàng)建場次后邀請多個主播同時進(jìn)行視頻連線。即使場次創(chuàng)建人退出，場次仍然可以存在。
術(shù)語介紹
圖片
上圖是新增場次，會話，頻道等領(lǐng)域之后的多人互動模型業(yè)務(wù)架構(gòu)圖，與上面直播業(yè)務(wù)架構(gòu)相比，我們屏蔽了推流到觀看過程細(xì)節(jié)，重點關(guān)注與rtc相關(guān)的業(yè)務(wù)交互。
當(dāng)主播使用互動功能時，客戶端將rtc音視頻數(shù)據(jù)作為一個采集源， 與其它的采集源數(shù)據(jù)合成后推送給視頻云，最后用戶拉取視頻流觀看。
圖片
這里又引出了一個新的問題，既然主播間可以使用rtc進(jìn)行實時音視頻互動，那用戶也接入rtc，是否就可以不經(jīng)過視頻云直接觀看主播的直播？
答案是yes。業(yè)內(nèi)也有很多互動直播間只基于rtc的能力實現(xiàn)。但是顯而易見，作為探索性業(yè)務(wù)，基于實現(xiàn)成本的考慮，作為旁路系統(tǒng)接入的實現(xiàn)成本遠(yuǎn)遠(yuǎn)低于改造整條鏈路。但帶來的缺點就是，業(yè)務(wù)服務(wù)需要同時考慮2套系統(tǒng)的狀態(tài)的一致性。這個狀態(tài)一致性也會在后面給系統(tǒng)的演進(jìn)帶來更多的挑戰(zhàn)。
圖片
上圖是基于業(yè)務(wù)架構(gòu)圖所對應(yīng)的應(yīng)用架構(gòu)圖
我們在服務(wù)層增加新的服務(wù)，用來處理場次，會話和rtc渠道的關(guān)系。
技術(shù)層面搭建好主播與主播的互動能力以后。我們沉淀了多人互動模型的技術(shù)資產(chǎn)。但產(chǎn)品層面還遠(yuǎn)遠(yuǎn)不夠，一方面主播只能使用PC直播姬進(jìn)行互動，缺少移動端互動能力，減少了能使用的主播數(shù)量。另一方便還不支持主播與觀眾進(jìn)行互動，減少了互動功能使用場景，也減少了主播進(jìn)行互動的意愿。
圖片
我們認(rèn)為社交是促進(jìn)主播開播的一個契機。，語音聊天是非常重要的社交場景，有助于激發(fā)主播開播動機。
為了支持產(chǎn)品訴求，我們架構(gòu)上需要做出如下的調(diào)整：
圖片
上圖是經(jīng)過調(diào)整后的多人語聊業(yè)務(wù)架構(gòu)圖，相比多人互動架構(gòu)圖，我們屏蔽了rtc相關(guān)的交互細(xì)節(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ù)語定義
最后是打通送禮鏈路， 以前觀眾只能給主播送禮，現(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ù)雜的位置分配等邏輯。所以當(dāng)時評估下來放在客戶端上實現(xiàn)比服務(wù)端實現(xiàn)成本低。等到多人語聊業(yè)務(wù)上線以后，最初的實現(xiàn)已經(jīng)無法滿足復(fù)雜的麥位管理控制需求了。所以我們需要將麥位分配與控制邏輯從客戶端遷移到服務(wù)端。
從客戶端遷移到服務(wù)端的關(guān)鍵點在于控制權(quán)的轉(zhuǎn)移。將之前麥位數(shù)據(jù)從B端產(chǎn)生，通過透傳通道推送到C端消費。變成由B端和C端發(fā)送數(shù)據(jù)到服務(wù)端，服務(wù)端進(jìn)行計算，存儲和推送。同時架構(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ù)組合情況與測試點：
服務(wù)端數(shù)據(jù) | 服務(wù)端代碼 | B端版本 | C端版本 | 說明 |
老 | 新 | 老 | 老 | 兼容測試 ,分平臺測試(PC直播姬,ios直播姬,Android直播姬,ios粉開播,Android粉開播) |
老 | 老 | 老 | 老 | 回歸測試 |
老 | 老 | 新 | 老 | 不存在, 數(shù)據(jù)版本會和B端版本保持一致 |
老 | 新 | 新 | 老 | |
新 | 新 | 新 | 老 | 功能測試 |
新 | 老 | 新 | 老 | 人為使用姿勢問題, 在未發(fā)布服務(wù)端代碼的環(huán)境使用新版本 |
麥位管理功能統(tǒng)一到服務(wù)端后，帶來的好處是業(yè)務(wù)擴展更容易，方便我們擴展更多的功能。但同樣也因為所有數(shù)據(jù)都需要到服務(wù)端來獲取，對于服務(wù)端的接口性能和實時性帶來了巨大的壓力。特別是當(dāng)存在類似于賽事或者活動等大型熱門房間，百萬用戶同時在線時，實時狀態(tài)同步將是一個巨大的挑戰(zhàn)。
圖片
我們通過組合使用多個渠道，利用各自特點來平衡實時性與性能開銷之間的矛盾。
經(jīng)過上述一系列調(diào)整以后， 業(yè)務(wù)架構(gòu)基礎(chǔ)性比較穩(wěn)定，開始探索語聊房內(nèi)營收相關(guān)玩法。
圖片
圖片
通過在已有的送禮鏈路上，疊加玩法生命周期管理，分?jǐn)?shù)計數(shù)，狀態(tài)轉(zhuǎn)移。構(gòu)建玩法生態(tài)。
圖片
圖片
一個成熟的系統(tǒng)是一定需要一個無死角的觀測能力，在任何領(lǐng)域都是這樣。醫(yī)療、航空，包括人體系統(tǒng)。
將應(yīng)用系統(tǒng)監(jiān)控進(jì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層基本是默認(rèn)都有的平臺設(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等）合作的超大型項目。
人工排查一個問題的成本是非常高的。在項目初上線時，當(dāng)時的相關(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)我們進(jìn)行架構(gòu)演進(jìn)的，以不變應(yīng)萬變，真正又好又快？看過或者聽過“沒有銀彈“這句話的人，可能已經(jīng)知道問題的答案了。但是為什么沒有呢？探討一個可以解釋萬事萬物的萬能法則，不管是誰聽了都會熱血澎湃。古人也不例外，早在兩千多年前，古希臘哲學(xué)家亞里士多德認(rèn)為在各種物理規(guī)則的基礎(chǔ)上，還有一種東西可以統(tǒng)轄和解釋所有的物理規(guī)則。在他的作品集中，把他對邏輯、含義和原因等抽象知識的討論編排在他討論物理學(xué)的書冊《自然學(xué)》之后，并給這些討論一個標(biāo)簽：《在自然學(xué)之后》（τ? μετ? τ? φυσικ? βιβλ?α）。從古希臘文翻譯到英文，于是就有了Metaphysics這個詞，看到這個詞就會聯(lián)想到最近很火的Metaverse，還有改名為Meta的Facebook。如果按照元宇宙的譯法，那么metaphysics就可以翻譯為“元物理”。但日本人在翻譯這個詞語時，從《易經(jīng) 》找到了 “形而上者謂之道，形而下者謂之器”一詞。于是Metaphysics便翻譯成了大家耳熟能詳?shù)植惶私獾摹靶味蠈W(xué)”這一詞。
不管是亞里士多德的“本原“還是老子的“道“，都認(rèn)為事物的現(xiàn)象背后必定有一個統(tǒng)一的規(guī)律，可以統(tǒng)轄和解釋所有的規(guī)則，闡述天地世間萬象變化。基于這種思想，就有了“格物致知”的說法。既然道存在于萬事萬物之中。那么同樣的萬事萬物中也都包含著道，也就是說只要把一個事務(wù)研究透了，自然也就獲得了道。王陽明和他的學(xué)生錢德洪一起切磋學(xué)問，二人都認(rèn)為要做成儒家的“圣賢”，就得格盡天下之物，于是就指著園內(nèi)的竹子，讓錢德洪去看。錢德洪一入夜就去窮究竹子的道理，竭盡心思想了三天三夜，也沒格出個所以然，還積勞成疾了。于是王陽明親自去格竹，也是竭盡心思早晚想不到竹子的道理，到了第七天，也因勞思而得病。
按照我們現(xiàn)代人的思維里，即使把竹子研究的再好，也造不了汽車。同樣的竹子格的再好，也成不了圣賢。世界上也不存在靜止的，孤立的“道“能夠解釋萬事萬物。這件事也成為王陽明日后心學(xué)思想體系建立過程中的重要事件。心學(xué)主張知行合一，按照通俗的話也就是討論“認(rèn)識”和“行動”的關(guān)系。
我們都知道，不管是做技術(shù)架構(gòu)，還是代碼結(jié)構(gòu)組成方式，都反應(yīng)了我們對產(chǎn)品的認(rèn)知。如果沒有恰當(dāng)?shù)恼J(rèn)知，就不可能做出合適的架構(gòu)，甚至可能會導(dǎo)致項目徹底失敗。既然沒有永恒不變的“道“，那我們應(yīng)該用什么樣認(rèn)知來指導(dǎo)我們的行動呢？
這個問題在《實踐論》中做出了回答：
通過實踐而發(fā)現(xiàn)真理，又通過實踐而證實真理和發(fā)展真理。從感性認(rèn)識而能動地發(fā)展到理性認(rèn)識，又從理性認(rèn)識而能動地指導(dǎo)革命實踐，改造主觀世界和客觀世界。實踐、認(rèn)識、再實踐、再認(rèn)識，這種形式，循環(huán)往復(fù)以至無窮，而實踐和認(rèn)識之每一循環(huán)的內(nèi)容，都比較地進(jìn)到了高一級的程度。這就是辯證唯物論的全部認(rèn)識論，這就是辯證唯物論的知行統(tǒng)一觀。
下面我將結(jié)合語聊房實際業(yè)務(wù)聊聊到對這幾個階段的認(rèn)識。
眾所周知，互聯(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)實世界的運行邏輯，具有初步的感性認(rèn)識后，我們需要進(jìn)一步抽象成通用型的業(yè)務(wù)模型。然后通過觀察競品的類似產(chǎn)品的實現(xiàn)也有助于幫助我們建立感性認(rèn)識。經(jīng)過這個階段，我們會對架構(gòu)產(chǎn)生初步的概念。
現(xiàn)實的情況和競品的實現(xiàn)幫助我們建立初步感性認(rèn)識，通過對這些感性認(rèn)識的整理，加以概念定義，類型歸類，邏輯重組等階段就能建立初步理性認(rèn)識。但不同競品的商業(yè)模式，品牌調(diào)性以及完成度都會與我們千差萬別，直接全盤照抄往往是失敗的前兆，同時工期上也是不可接受的。通過與產(chǎn)運規(guī)劃對齊，理清實現(xiàn)路徑，幫助我們了解每個階段的主要目標(biāo)和主要矛盾。
圖片
到這個階段，我們已經(jīng)對所要做的事情有了初步的理性判斷，這有助于我們下一步架構(gòu)落地。
抽象是指從具體的事物中抽離出共性的概念或特點，將它們提煉出來形成一種抽象的概念或理論。計算機領(lǐng)域有一句名言，“任何問題都可以通過增加一層間接的中間層來解決“。原因就在于人的認(rèn)知能力是有限的，抽象有助于降低我們理解復(fù)雜事物的成本。但是抽象同樣也會帶來模糊實現(xiàn)的問題。當(dāng)我提起“馬“， 我可能指的是河馬，你腦海中可能想到的是斑馬。所以我們需要，通過顯示的定義概念來統(tǒng)一語言，幫助我們更好地溝通和理解彼此的意思，才能做到團隊理解一致性。在領(lǐng)域驅(qū)動設(shè)計中，抽象和統(tǒng)一語言是非常重要的概念，它們可以幫助我們更好地理解和設(shè)計領(lǐng)域模型，從而創(chuàng)建高質(zhì)量的軟件系統(tǒng)。
語言只有在特定語境中才有意義，在不同語境中同一個概念往往會有不同的意義。特定語境往往對應(yīng)確定的業(yè)務(wù)模型，比如同樣是“訂單”，在秒殺領(lǐng)域，拼單領(lǐng)域，團購領(lǐng)域等往往代表著不同的業(yè)務(wù)流程和現(xiàn)實意義。在代碼實現(xiàn)上，我們通過package，class等方式來進(jìn)行模塊劃分。在領(lǐng)域驅(qū)動設(shè)計中，我們通過限界上下文來保證領(lǐng)域內(nèi)概念的一致性。
圖片
在不同的BoundContext（限界上下文）中，同樣的一個名詞代表不同的業(yè)務(wù)模型或者模型的不同維度。
拿【語聊房間】來說，在內(nèi)容安全Subdomain → 審核BoundContext中，這個【房間實體】是有著特定字端的（房間管控等級、是否需要認(rèn)證手機號、是否大陸身份等）。這些字端是【語聊房間】概念實體在安全領(lǐng)域上下文中的特定表現(xiàn)。在整個開發(fā)架構(gòu)上，我們也是參考領(lǐng)域來劃分每個模塊的職責(zé)邊界。
圖片
領(lǐng)域模型是逐步下沉的業(yè)務(wù)載體，彼此獨立。最終通過在usercase 層 application來組裝編排領(lǐng)域模型。
對業(yè)務(wù)問題空間求解是軟件開發(fā)的首要問題。通過對問題空間的不斷定義與探索，我們映射得到對應(yīng)解空間的系統(tǒng)架構(gòu)與應(yīng)用架構(gòu)。這一階段主要目標(biāo)是持續(xù)交付我們的架構(gòu)。
圖片
在網(wǎng)上流傳廣泛的介紹MVP的圖。
先制作出一個最小可行的產(chǎn)品（例如小型滑板車或自行車），測試用戶對其概念的認(rèn)可程度，再根據(jù)反饋來決定如何進(jìn)一步完善產(chǎn)品。MVP策略的優(yōu)點在于試錯成本低速度快風(fēng)險低，能夠滿足快速迭代的需求。
隨著架構(gòu)的演進(jìn)，我們需要有合適的評估機制，來評估變化對架構(gòu)的影響，防止架構(gòu)隨著時間推移而退化。架構(gòu)由很多維度構(gòu)成，包括性能，安全性，穩(wěn)定性，代碼規(guī)范等，對于不同的維度，我們需要建立不同的指標(biāo)來評估。
在開發(fā)架構(gòu)管理上，進(jìn)行代碼級別的保障，包括以下措施：
在CICD上增加代碼質(zhì)量檢查，保證代碼符合規(guī)范：
圖片
在自動化測試平臺上，與測試團隊共建自動化測試用例，覆蓋全部關(guān)鍵場景用例，保證每次代碼變更不會產(chǎn)生預(yù)期外的業(yè)務(wù)影響：
圖片
Devops方面，對關(guān)鍵接口P999響應(yīng)時間進(jìn)行監(jiān)控，保證系統(tǒng)性能不劣化：
圖片
每日自動巡檢，保證服務(wù)健康度：
圖片
參考文章
朱德江嗶哩嗶哩資深開發(fā)工程師
王清培嗶哩嗶哩資深開發(fā)工程師
趙書彬嗶哩嗶哩高級開發(fā)工程師
本文鏈接：http://www.www897cc.com/showinfo-26-26003-0.html語聊房架構(gòu)演進(jìn)實踐
聲明：本網(wǎng)頁內(nèi)容旨在傳播知識，若有侵權(quán)等問題請及時與本網(wǎng)聯(lián)系，我們將在第一時間刪除處理。郵件：2376512515@qq.com
Copyright ? 2016-2023 天津谷騏科技有限公司 版權(quán)所有 sitemap.xml
違法及侵權(quán)請聯(lián)系：2376512515@qq.com 津ICP備18001702號
津公網(wǎng)安備 12010102000574號