1. 背景及技術(shù)挑戰(zhàn)

從電視看直播到手機(jī)電腦看直播，直播技術(shù)的發(fā)展讓觀眾可以隨時、隨地觀看自己喜歡的比賽，并且在看比賽時通過發(fā)送表情、發(fā)文字進(jìn)行互動。但表情、文字承載的信息量較小、溝通效率低，我們無法像線下一起看比賽那樣和好友邊看邊聊、一起為精彩的比賽吶喊，觀賽體驗(yàn)大打折扣。

為了讓觀眾獲得更好的觀賽體驗(yàn)，抖音在 2022 世界杯比賽直播中推出了“邊看邊聊”的玩法：每個觀眾都可以邀請好友（或分享聊天頻道信息邀請）一起觀看世界杯比賽；在頻道中，好友既可以發(fā)送文字、表情聊天，還可以上麥進(jìn)行語音聊天，一起為精彩進(jìn)球歡呼，大大提升“異地好友線上觀賽”的體驗(yàn)。

我們使用 RTC 來實(shí)現(xiàn)“邊看邊聊”的功能——觀眾可以隨時上麥進(jìn)行語音聊天，同時頻道中的普通觀眾也可以聽到麥上用戶的精彩評論。但在抖音“邊看邊聊世界杯”的玩法中，RTC 面臨著幾個比較大的挑戰(zhàn)：

一是高并發(fā)的問題，包括音視頻流數(shù)高并發(fā)和大量進(jìn)退房請求對系統(tǒng)的沖擊。世界杯是四年一度的體育盛會，會有大量用戶同時在線看球聊球，這為 RTC 房間帶來了持續(xù)高并發(fā)的音視頻推拉流壓力，對于系統(tǒng)的性能及穩(wěn)定性提出了巨大挑戰(zhàn)。同時，在比賽開始和比賽結(jié)束時，短時間內(nèi)大量用戶進(jìn)房、退房的請求也會對 RTC 系統(tǒng)形成沖擊 。

二是觀賽中的音視頻體驗(yàn)問題。包括外放時，比賽的聲音被麥克風(fēng)采集并發(fā)送到遠(yuǎn)端形成回聲的問題；通話人聲響度低于直播聲音響度導(dǎo)致聽不清問題；整體音質(zhì)優(yōu)化等難點(diǎn)問題。

2. 整體方案設(shè)計

抖音“邊看邊聊”的玩法允許單房間 500 人加入，每個房間允許 9 個用戶上麥聊天，另外 491 個未上麥用戶只旁聽不發(fā)言。在整體方案設(shè)計的過程中，火山引擎 RTC 考慮了“語音聊天室方案”和“ RTC 互動語聊方案”兩種方案，并對兩種方案架構(gòu)進(jìn)行了分析。

2.1 語音聊天室方案

方案選型初期，其中一個候選方案是“在直播間中再嵌入一個語音聊天室”，即，在觀看比賽直播的同時，上麥用戶加入 RTC 進(jìn)行語音聊天，其余未上麥觀眾再多拉一路 CDN 流收聽聊天內(nèi)容， 整體結(jié)構(gòu)如下：

該方案的優(yōu)勢是可以快速復(fù)用線上業(yè)務(wù)語音聊天室的主播、觀眾代碼，以及復(fù)用當(dāng)前線上業(yè)務(wù)中上麥、下麥流程，快速搭建該玩法場景。但這個方案也存在一個問題， 即未上麥的用戶（圖中好友 C、好友 D）聽到的聊天內(nèi)容會有較大的延時， 麥下用戶會在進(jìn)球后大約 1~3 秒（CDN 轉(zhuǎn)推延時）才能聽到麥上用戶聊進(jìn)球相關(guān)內(nèi)容，這會導(dǎo)致比賽進(jìn)程畫面和聊天內(nèi)容不同步、聊天內(nèi)容延時大，對于需要“同頻共振”的大型賽事觀播是無法接受的體驗(yàn)。

2.2 RTC 互動語聊方案

為了保證所有用戶“邊看邊聊、精彩共享”的核心體驗(yàn)，“邊看邊聊”玩法選擇了“ RTC 互動語聊”的方案，即所有用戶都加入 RTC 房間，使用火山引擎 RTC 為支持超大型視頻會議、在線教育大班課場景打造的“千人上麥”和“穩(wěn)定支持超百萬人同時在線”能力，來應(yīng)對百萬人并發(fā)量級的世界杯“邊看邊聊”需求。

方案整體架構(gòu)如下：

方案核心要點(diǎn)如下:

（1）觀眾使用播放器從 CDN 拉取高清比賽直播流，播放器支持用戶手動選擇清晰度檔位、支持 seek 觀看高光時刻等操作；

（2）頻道中好友通過 RTC 進(jìn)行實(shí)時音頻通話；

（3）RTC 支持將通話的語音切片后存儲，供業(yè)務(wù)進(jìn)行審核，保障通話內(nèi)容安全；同時，平臺還可以通過踢人/拉黑等運(yùn)維 OpenAPI，處理不合規(guī)或不符合業(yè)務(wù)預(yù)期的用戶，保障平臺運(yùn)營安全。

在確認(rèn)整體方案架構(gòu)后，我們重點(diǎn)對如何應(yīng)對超高并發(fā)、如何提升邊看邊聊體驗(yàn)進(jìn)行了深度優(yōu)化。

3. 關(guān)于超高并發(fā)問題的優(yōu)化和實(shí)踐

“超高并發(fā)”是本次世界杯“邊看邊聊”場景的最大挑戰(zhàn)，由于比賽活動時間集中，相關(guān)流量都會集中出現(xiàn)在 64 場比賽的時間段，特別是在開幕戰(zhàn)、明星球隊出戰(zhàn)、決賽等熱門比賽場次，會有超大量觀眾同時進(jìn)入直播間；而且，用戶在比賽開始前后集中上線、比賽結(jié)束后集中離線也會對 RTC 系統(tǒng)穩(wěn)定運(yùn)行形成巨大壓力。

3.1 關(guān)于流數(shù)高并發(fā)的優(yōu)化

世界杯“邊看邊聊”場景的特點(diǎn)是流量大，DAU 高（預(yù)估峰值將超過百萬觀眾同時“邊看邊聊”），抽象到 RTC 場景，就是房間數(shù)量多，每個房間的用戶數(shù)也多。因此，我們設(shè)計了一套高效率的方案，來兼顧用戶實(shí)時交互體驗(yàn)以及承載更多量級用戶的需求。

3.1.1 常規(guī)方案

首先是常規(guī)方案。在常規(guī)方案中，服務(wù)器只需要轉(zhuǎn)發(fā)流，不需要做過多額外的處理，用戶在最后一公里就近接入，服務(wù)器之間做級聯(lián)。在這種架構(gòu)下，用戶的實(shí)時交互體驗(yàn)極佳，但對于大房間（用戶多）來說不夠合理，用戶訂閱壓力大，客戶端面臨一定的拉流壓力，服務(wù)端也面臨性能和容量的雙重挑戰(zhàn)。

常規(guī)方案架構(gòu)圖如下：

以“500 人房間”為例，單房間 500 個用戶看球，其中 9 個人開麥聊天，訂閱端每個用戶需要訂閱 9 路流，用戶下行拉流過多，對用戶的客戶端造成一定的性能壓力。再說服務(wù)端，假設(shè)考慮到服務(wù)器之間級聯(lián)，在最差情況下（500 個用戶連接到 500 個不同服務(wù)器節(jié)點(diǎn)，服務(wù)器之間都需要級聯(lián)轉(zhuǎn)發(fā)），平均一個用戶會給整個系統(tǒng)帶來 10+ 路媒體流。再考慮到這個場景的 DAU，這套常規(guī)方案對服務(wù)端性能、容量都會造成很大的壓力。

3.1.2 公共流擴(kuò)展方案

常規(guī)方案在房間人數(shù)多時會面臨諸多性能壓力，因此我們又設(shè)計了一套公共流擴(kuò)展方案。在公共流方案中，發(fā)布端（上麥用戶）仍然使用常規(guī)方案的設(shè)計，媒體服務(wù)器只需要純轉(zhuǎn)發(fā)，不需要做過多額外的處理；訂閱端（閉麥用戶）則訂閱經(jīng)過 MCU（Multipoint Control Units，多點(diǎn)控制單元）服務(wù)器處理的公共流，在這個架構(gòu)下，用戶的訂閱流數(shù)降低至 1 路。

同樣以“500 人房間”為例，單房間 500 個用戶看球，其中 9 個人開麥聊天，訂閱端每個用戶只需要訂閱 1 路流，釋放了客戶端使用壓力。對于服務(wù)端來說，平均一個用戶只會給整個系統(tǒng)只會帶來 2-3 路媒體流的增加，極大優(yōu)化了服務(wù)端資源消耗。

這套方案架構(gòu)可以很好地解決熱流分發(fā)的壓力，相同的服務(wù)器資源可以承載更大的容量，單流可支持 10w 量級的并發(fā)訂閱。客戶端也因?yàn)橛嗛喿兩?，性能得到很大的提升。但這套方案架構(gòu)也會對用戶的交互體驗(yàn)產(chǎn)生影響，當(dāng)用戶從“只訂閱的角色”切換至“發(fā)布 + 訂閱”的角色時，用戶需要先切換到“常規(guī)方案”，即“從公共流”進(jìn)入到“RTC 房間”，這個時候，用戶的流內(nèi)容會發(fā)生切換，用戶會有“卡頓一下”的感覺。如果這個用戶頻繁地切換角色，那就會頻繁地感覺到“卡頓”，用戶體驗(yàn)反而惡化。

3.1.3 融合方案

常規(guī)方案帶給用戶的交互性好，但是增加了大多數(shù)訂閱端用戶的設(shè)備端性能壓力以及服務(wù)端的資源消耗；公共流方案減少了 RTC 系統(tǒng)全鏈路并發(fā)音視頻流數(shù)，緩解了訂閱端用戶的性能壓力，但是在頻繁上下麥時，頻繁地“常規(guī)方案”和“公共流方案”之間切換會導(dǎo)致戶體驗(yàn)受損。基于以上特點(diǎn)，火山引擎 RTC 在抖音“邊看邊聊”場景中設(shè)計了一套“有房間+公共流”的融合方案，來兼顧用戶體驗(yàn)和設(shè)備端、服務(wù)端性能優(yōu)化。

融合方案設(shè)計流程如下：

具體流程為：

用戶進(jìn)房 a. 當(dāng)一個聊天頻道的用戶小于 M 人時，該房間使用“常規(guī)方案”，用戶使用“靜默用戶”的身份進(jìn)入 RTC 房間并訂閱流； b. 當(dāng)一個聊天頻道的用戶大于等于 M 人時，用戶使用“公共流擴(kuò)展方案”加入。

首次上麥 a. 當(dāng)用戶以常規(guī) RTC 方案訂閱流時，上麥時用戶改變狀態(tài)，靜默用戶 -> 非靜默用戶； b. 當(dāng)用戶以公共流方式訂閱流時，上麥時用戶以非靜默用戶身份直接進(jìn)入 RTC 房間。

二次上麥 a. 用戶改變狀態(tài)，靜默用戶 -> 非靜默用戶。

用戶下麥 a. 用戶改變狀態(tài)，非靜默用戶 -> 靜默用戶。

將常規(guī)方案與公共流方案結(jié)合的方案融合了兩者的優(yōu)點(diǎn)：

（1）用戶默認(rèn)以訂閱公共流的方式加入“大房間”中，可以減少 RTC 系統(tǒng)全鏈路的并發(fā)音視頻流數(shù)，擴(kuò)大 RTC 系統(tǒng)并發(fā)容量；

（2）能有效減少用戶在不拉流時候的設(shè)備端性能壓力；

（3）用戶在上麥時切換為常規(guī) RTC 方案“有房間”的模式，可以保證用戶實(shí)時的交互音視頻體驗(yàn)。在切換為有房間模式后，后續(xù)的上下麥則不會再變更模式，保證了用戶的平滑體驗(yàn)。

3.2 系統(tǒng)容災(zāi)保護(hù)

抖音 DAU 很大，參與“邊看邊聊”玩法的用戶并發(fā)峰值超過百萬量級，并且，世界杯類大型賽事活動有個特征——在比賽開始的時候，用戶集中進(jìn)房；比賽結(jié)束時刻，用戶又會集中停止使用音視頻功能，所以在比賽開始和結(jié)束的時候會有大量請求發(fā)到 RTC 云端服務(wù)器，對云服務(wù)造成很大壓力，極端情況下甚至?xí)?dǎo)致服務(wù)異常。針對進(jìn)房和退房的不同特點(diǎn)，火山引擎 RTC 分別采用了“多級限流”的進(jìn)房保護(hù)策略和“延時處理”的退房保護(hù)策略。

3.2.1 進(jìn)房多級限流保護(hù)

火山引擎 RTC 采用“邊緣+中心”結(jié)構(gòu)，用戶就近接入邊緣節(jié)點(diǎn)，數(shù)據(jù)則存儲在中心機(jī)房。在做限流保護(hù)的時候，我們也采用了相似的策略，即多級保護(hù)、分段限流，包括全局分布式 QPS 限流，中心 QPS 限流，中心房間數(shù)限流。

架構(gòu)如下：

全局分布式QPS限流

全局分布式 QPS 限流采用滑動窗口算法實(shí)現(xiàn)。中心信令通過存儲維護(hù)每秒可以消耗的令牌數(shù)量，邊緣節(jié)點(diǎn)定時向中心同步自己的令牌數(shù)量，同時中心返回當(dāng)前時間戳內(nèi)消耗的總令牌數(shù)。進(jìn)房時刻的尖峰流量對中心節(jié)點(diǎn)不友好，全局分布式 QPS 限流可以保證限流平滑，即使部分節(jié)點(diǎn)有瞬時尖峰流量，整個系統(tǒng)也不會受到過大沖擊。

中心QPS限流

中心 QPS 限流采用令牌桶算法實(shí)現(xiàn)。中心信令以恒定的速率產(chǎn)生令牌，然后把令牌放到令牌桶中，令牌桶有一個容量，當(dāng)令牌桶滿了后，如果再向其中放入令牌，多余令牌就會被丟棄。當(dāng)中心信令想要處理一個請求的時候，需要從令牌桶中取出一個令牌，如果此時令牌桶中沒有令牌，那么該請求就會被拒絕，客戶端會收到服務(wù)端返回的錯誤碼提示。

中心房間數(shù)限流

中心信令會在存儲中維護(hù)當(dāng)前系統(tǒng)可以承載的最大房間數(shù)量，每當(dāng)新用戶使用火山引擎 RTC 之后，中心信令就會查詢存儲判斷當(dāng)前的房間數(shù)量是否已到達(dá)上限，如果超過了，則會拒絕本次用戶的請求，客戶端會收到服務(wù)端返回的錯誤碼提示。

全局分布式 QPS 限流、中心 QPS 限流，中心房間數(shù)限流“三管齊下”的進(jìn)房多級限流保護(hù)措施解決了“邊看邊聊”場景大流量對整個系統(tǒng)的威脅。云服務(wù)系統(tǒng)在處理高并發(fā)請求時，先進(jìn)行全局分布式 QPS 限流，然后再進(jìn)行中心 QPS 限流，當(dāng)整體系統(tǒng)處于高水位時，又會采取全局分布式房間數(shù)限流。

3.2.2 退房/斷連延時處理保護(hù)

進(jìn)房操作對實(shí)時性要求很高，如果進(jìn)房慢，用戶的體驗(yàn)也會嚴(yán)重受損。不同于進(jìn)房操作，用戶可以在一定程度上忍受“退房慢”，因此服務(wù)端的保護(hù)策略上也和進(jìn)房略有不同。退房/斷連保護(hù)的策略核心是“延時處理”，在邊緣節(jié)點(diǎn)設(shè)置一個定長的 FIFO 隊列，每個邊緣節(jié)點(diǎn)的請求先進(jìn)入 FIFO 隊列中，后續(xù)按照一定的速率重新發(fā)送到中心信令。經(jīng)過這樣的保護(hù)，服務(wù)可以處理超百萬 QPS 的退房操作。

退房/斷連保護(hù)的基本執(zhí)行步驟：

檢測用戶退房事件（包括用戶正常離開房間與斷網(wǎng)離房）的 QPS，如果 QPS 超過可以立即處理的閾值，將事件觸發(fā)的上下文保存到隊列中，且記錄當(dāng)前時間戳到事件的上下文中；

在隊列中啟動一個 Loop，嘗試獲取隊列中請求任務(wù)去執(zhí)行，每次在執(zhí)行前，還會檢查退房事件觸發(fā)事件的時間戳與當(dāng)前時間差是否小于某個定義的閾值，小于該閾值的請求會被執(zhí)行發(fā)送到中心信令；大于等于該閾值的請求則會被丟棄；

在發(fā)送成功后，從隊列中刪除該事件的上下文信息。

異常場景考慮

用戶發(fā)送退房請求，且被攔截保存到緩存隊列中，之后很短時間內(nèi)用戶又重新進(jìn)房，那么會出現(xiàn)用戶退房事件與用戶下次進(jìn)房存在時序問題，我們用引入“退房時間戳”來解決這個問題。中心信令在接收到用戶退房請求時，會比較當(dāng)前用戶進(jìn)房時間戳與退房時間戳，若進(jìn)房時間晚于退房時間，說明是用戶退房后再進(jìn)房，系統(tǒng)可以直接忽略該用戶的離房請求。

退房請求放入隊列超過一定時長后可能會觸發(fā)斷連請求。這里的處理方式就是依次處理退房請求和斷連請求，如果用戶已經(jīng)退房，則忽略斷連請求。

4. 極致用戶體驗(yàn)

極致的音視頻體驗(yàn)是業(yè)務(wù)玩法獲得用戶認(rèn)可的必要條件。在邊看邊聊場景中，我們面對著本地直播音頻被麥克風(fēng)采集形成回聲、使用通話模式導(dǎo)致直播音質(zhì)變差、比賽聲音比聊天聲音大導(dǎo)致人聲聽不清楚等問題，這些問題都嚴(yán)重影響了用戶的邊看邊聊體驗(yàn)；為了解決相關(guān)問題，我們使用了直播音頻托管 RTC 播放、全鏈路音頻媒體通道模式、智能音頻閃避等方案，為邊看邊聊提供了良好的音視頻體驗(yàn)。

4.1 音頻托管

回聲消除問題是 RTC 的重點(diǎn)和難點(diǎn)問題；在邊看邊聊場景中，部分用戶會使用外放音頻方式來觀看比賽， 在這種情況下，RTC 播放的遠(yuǎn)端人聲和直播播放器播放的比賽聲音會被麥克風(fēng)采集后發(fā)送到遠(yuǎn)端形成回聲。

為了解決邊看邊聊場景的回聲問題，RTC 和播放器提供了播放器音頻托管由 RTC 來播放的解決方案，由播放器將解碼后的直播音頻數(shù)據(jù)調(diào)用 RTC 音頻托管接口來播放；在 RTC 內(nèi)部，直播音頻會和遠(yuǎn)端用戶音頻進(jìn)行混合，再調(diào)用系統(tǒng)音頻播放接口進(jìn)行播放，同時將混合信號送到 RTC 回聲消除模塊，回聲消除模塊會將麥克風(fēng)采集到的聲音中的遠(yuǎn)端音頻和直播比賽聲音消除，這樣就得到了沒有回聲的本地人聲數(shù)據(jù)，這些數(shù)據(jù)會在編碼后送到遠(yuǎn)端，避免了回聲問題的出現(xiàn)。

4.2 外放媒體模式

在移動端設(shè)備上，音頻播放區(qū)分通話模式（通話模式音頻通道）和媒體模式（媒體模式音頻通道），二者在音質(zhì)表現(xiàn)、音量控制上略有不同，從而適用于不同的業(yè)務(wù)場景， 具體表現(xiàn)如下：

由于邊看邊聊場景是在直播間觀看比賽過程中開啟音頻通話，我們既要保障通話沒有回聲，也要保障直播音頻音質(zhì)；我們分別對邊看邊聊場景 RTC 使用媒體通道和通話通道進(jìn)行了對比測試結(jié)果如下：

為了給用戶提供更好的音質(zhì)體驗(yàn)，本次邊看邊聊場景配置了外放媒體模式；為了解決外放媒體模式時系統(tǒng)回聲消除效果差的問題，火山引擎 RTC 引入了基于深度學(xué)習(xí)的回音消除算法，對傳統(tǒng)算法難以覆蓋的場景進(jìn)行音質(zhì)提升，比如信號回聲比較大的情況，非線性失真加大的情況，以及音樂場景等，在保障聊天回聲消除條件下，達(dá)到了高音質(zhì)體驗(yàn)。

4.3 智能音頻閃避

邊看邊聊場景的另外一個特點(diǎn)是直播流中現(xiàn)場聲音、解說聲音的音量通常會比好友之間聊天聲音音量大，這就造成了聊天的聲音偏小或者幾乎聽不到遠(yuǎn)端好友聲音的問題；為了解決直播聲音大而聊天聲音比較小的問題，我們在邊看邊聊場景中調(diào)整了遠(yuǎn)端人聲和直播聲音的音量配比，保障遠(yuǎn)端聊天人聲和直播聲音響度基本持平。

為了更進(jìn)一步避免比賽聲音和遠(yuǎn)端人聲沖突導(dǎo)致無法聽清聊天內(nèi)容的問題， 我們引入了智能音頻閃避算法。音頻閃避（Audio Ducking）的功能是當(dāng)檢測到 A 信號出現(xiàn)時，將 B 信號的電平降低，仿佛 B 信號「躲避」了 A 信號，因此得名「閃避」。閃避算法非常適合在「邊看邊聊」和「游戲直播」場景中開啟，在邊看邊聊場景中，A 信號是遠(yuǎn)端用戶人聲，B 信號是播放器播放的比賽聲音。開啟閃避功能后，RTC 在收到遠(yuǎn)端語音時，將播放的直播聲音進(jìn)行閃避，能讓用戶更清晰地聽到遠(yuǎn)端好友的語音， 經(jīng)過驗(yàn)證，達(dá)到了非常好的音頻體驗(yàn)。

邊看邊聊場景添加智能音頻閃避后的音頻處理流程如圖：

關(guān)于智能音頻閃避功能中的音頻增益控制，還有一些經(jīng)驗(yàn)性原則需注意：

增益下降應(yīng)足夠快，否則語音的開始片段仍會被音樂掩蔽；但又不能過快，導(dǎo)致出現(xiàn)音質(zhì)問題；

增益下降后，應(yīng)該保持足夠的時間，等待人聲消失一段時間后再恢復(fù)，否則，正常講話的停頓會頻繁觸發(fā)閃避效果，體驗(yàn)很差；

增益的恢復(fù)可以稍慢，不要給人很突然的感覺；

要對遠(yuǎn)端人聲進(jìn)行智能識別檢測，避免遠(yuǎn)端噪聲引起過度閃避。

5. 總結(jié)與展望

火山引擎 RTC 邊看邊聊場景解決方案， 通過 RTC 公共流 + RTC 有房間無縫切換的方案，在兼顧實(shí)時音視頻體驗(yàn)基礎(chǔ)上，支持了單流超大規(guī)模的并發(fā)，降低了用戶拉流數(shù)量，不僅提高了觀賽機(jī)型滲透率也提高了 RTC 系統(tǒng)容量；針對世界杯觀賽用戶集中進(jìn)房 ，集中退房的特點(diǎn)，RTC 服務(wù)端制定了 “邊緣限流”，“中心限流” ，“信令平滑發(fā)送” 等重保策略，提高了 RTC 服務(wù)在高 QPS 場景下的穩(wěn)定性；使用直播流音頻托管給 RTC 播放的方案，解決了雙端同時播放直播流音頻引入的回聲問題；使用外放媒體模式 + 軟件 3A 方案，在兼顧回聲消除基礎(chǔ)上保障了高音質(zhì)邊看邊聊體驗(yàn)；通過調(diào)整音量配比和智能音頻閃避功能，解決了直播流聲音大， 聊天聲音小的問題。經(jīng)線上打磨驗(yàn)證，方案設(shè)計合理有效，為世界杯邊看邊聊觀賽體驗(yàn)提供了有力的保障。

更進(jìn)一步，在一起看短視頻、一起看電影等場景，業(yè)務(wù)還可以通過實(shí)時信令(RTS)來對房間中各個用戶觀看進(jìn)度進(jìn)行集中控制，保障房間中用戶觀看相同內(nèi)容；業(yè)務(wù)還可以選擇打開視頻， 更進(jìn)一步增加好友之間的觀影、觀賽體驗(yàn)；在UGC 大咖解說場景，我們還可以支持用戶上麥與主播進(jìn)行互動聊天，更進(jìn)一步拉近主播和觀眾的距離，實(shí)現(xiàn)更好的互動效果。

6. Demo 和場景搭建

我們將支持邊看邊聊的材料整理成了場景化解決方案文檔和 Demo， 供有需要的開發(fā)者來快速實(shí)現(xiàn)自己的業(yè)務(wù)場景。

審核編輯 ：李倩