WebRTC 除了一對(duì)一通信外，最常見(jiàn)的使用場(chǎng)景便是多人視頻會(huì)議。不要只考慮傳統(tǒng)的會(huì)議室場(chǎng)景，有很多場(chǎng)景都超出了會(huì)議室的范疇，比如網(wǎng)上學(xué)習(xí)、客服支持、或者實(shí)時(shí)廣播。在每個(gè)場(chǎng)景中，最重要的能力便是如何分發(fā)多路音視頻流。
其實(shí)根據(jù)不同的需求，存在幾種架構(gòu)；這些架構(gòu)基本都圍繞兩個(gè)維度展開(kāi)，即中心化 vs 點(diǎn)對(duì)點(diǎn)連接（P2P）；混流 vs 路由中繼。我會(huì)在這里介紹幾種最流行的架構(gòu)。
Mesh
Mesh 是最簡(jiǎn)單的架構(gòu)。它在新的 WebRTC 服務(wù)供應(yīng)商中很受歡迎，因?yàn)樗ɑ荆┎恍枰魏位A(chǔ)設(shè)施。該架構(gòu)對(duì)于每個(gè)發(fā)送者和它所有可能的接收者而言，都會(huì)創(chuàng)建連接。盡管這種架構(gòu)看起來(lái)很低效，但實(shí)踐證明它非常有效；并且由于每個(gè)接收者都具備開(kāi)箱即用的帶寬自適應(yīng)功能，可以將延遲降至最低。
唯一的問(wèn)題在于，這種架構(gòu)需要大量的上行鏈路帶寬才能同時(shí)推流給所有接收者，并且目前的瀏覽器實(shí)現(xiàn)需要消耗大量的 CPU 資源才能對(duì)視頻并行編碼。
混流
傳統(tǒng)的多人會(huì)議架構(gòu)采用的是混流模式，并且這種架構(gòu)已經(jīng)使用了很多年了。這是因?yàn)樗枰目蛻舳四芰ψ钌佟＿@種架構(gòu)使用中心節(jié)點(diǎn)與每個(gè)參與者保持一對(duì)一連接；中心節(jié)點(diǎn)接收每個(gè)發(fā)送方的視頻流并將它們混合成單個(gè)視頻流，然后發(fā)送給每個(gè)參與者。在視頻會(huì)議領(lǐng)域，這些中心節(jié)點(diǎn)被稱為 MCU（Multipoint Control Unit，多端控制器）。
混流架構(gòu)的兼容性最好，可以兼容很多老舊設(shè)備；它也支持帶寬自適應(yīng)模式，因?yàn)榛炝鲉卧梢詾槊總€(gè)接收者分別生成不同質(zhì)量的視頻流。混流架構(gòu)的另一個(gè)優(yōu)點(diǎn)是它能利用硬件解碼，許多 WebRTC 客戶端的芯片都具有解碼單個(gè)視頻流的能力。
混流架構(gòu)的主要問(wèn)題是 MCU 的架構(gòu)成本。此外，混流既需要解碼還需重新編碼，因此會(huì)增加延遲以及降低畫質(zhì)。同時(shí)混流也降低了客戶端 UI 的靈活性（盡管存在一些解決方案）。
路由中繼
路由中繼架構(gòu)是 H.264 SVC 普及后流行起來(lái)的，并且已經(jīng)被廣泛應(yīng)用于新的沒(méi)有歷史包袱的 WebRTC 平臺(tái)。該架構(gòu)使用中心節(jié)點(diǎn)接收每個(gè)發(fā)送方的視頻流，并將其轉(zhuǎn)發(fā)給其他參與者。中心節(jié)點(diǎn)對(duì)數(shù)據(jù)包僅僅進(jìn)行檢查和轉(zhuǎn)發(fā)，而不進(jìn)行解碼和再編碼。
路由中繼提供了一種廉價(jià)的且可擴(kuò)展的多人會(huì)議架構(gòu)；與混流架構(gòu)相比，它具有較低的延遲，并且沒(méi)有畫質(zhì)損失。但另一方面，大部分從業(yè)者往往缺乏搭建這種架構(gòu)的經(jīng)驗(yàn)，并且對(duì)于不同的接收方適配起來(lái)較為棘手。這需要發(fā)送方支持生成一個(gè)流的多個(gè)版本（比如 Simulcast 或者 VP8），路由器會(huì)根據(jù)接收方的客戶端能力選擇性地轉(zhuǎn)發(fā)對(duì)應(yīng)的流。
該使用哪種架構(gòu)？
不幸的是，這并不是一個(gè)簡(jiǎn)單的問(wèn)題。一些服務(wù)供應(yīng)商為了滿足不同客戶的需求，提供了上述所有架構(gòu)的支持。不過(guò)這里還是有一些通用的選擇方式以供參考。
如果你提供的是純音頻服務(wù)，或者需要兼容老舊設(shè)備，那么混流架構(gòu)是不錯(cuò)的選擇。此外，假如你的成本開(kāi)銷并不是問(wèn)題；并且參與者們各自的連接性非常不同，也可以使用混流。
如果你的服務(wù)的使用者們有著非常好的網(wǎng)絡(luò)，他們的設(shè)備配置也很給力（比如公司內(nèi)部服務(wù)），并且參與者數(shù)量有限，那么 Mesh 架構(gòu)是不錯(cuò)的選擇。
如果你要部署大規(guī)模服務(wù)，那么就選擇路由中繼架構(gòu)。總的來(lái)說(shuō)，路由中繼架構(gòu)既能較好地利用客戶端算力，同時(shí)還能保持良好的擴(kuò)展性和靈活性。
