云視頻會(huì)議系統(tǒng)私有化實(shí)踐

編者按：云視頻會(huì)議系統(tǒng)支持多服務(wù)器動(dòng)態(tài)集群部署，并提供多臺(tái)高性能服務(wù)器，大大提升了會(huì)議穩(wěn)定性、安全性、可用性。視頻會(huì)議為用戶大幅提高溝通效率，提升內(nèi)部管理水平，已廣泛應(yīng)用在政府、交通、運(yùn)營(yíng)商、教育、企業(yè)等各個(gè)領(lǐng)域。本次LiveVideoStack特別邀請(qǐng)到了來自Cybrook的吳榮華老師，為我們從私有化、混合云、運(yùn)維與部署等方面，分享他和團(tuán)隊(duì)在云視頻會(huì)議系統(tǒng)私有化的實(shí)踐經(jīng)驗(yàn)。

先簡(jiǎn)單介紹下我自己。我叫吳榮華，是蹤視通的聯(lián)合創(chuàng)始人與工程副總。我最早是在GIPS公司任職，GIPS全稱是Global IP Solutions，它是一個(gè)瑞典的公司。行業(yè)外的大家可能不是特別熟悉，但做RTC的可能都有了解，公司的主要產(chǎn)品是實(shí)時(shí)音視頻 SDK。叫做Voice Engine和Video Engine，可以說當(dāng)時(shí)幾乎所有大廠都在用我們的SDK，包括QQ、gtalk、hangouts，yahoo messager等等。后來Google想要做WebRTC，所謂WebRTC就是把RTC的技術(shù)做到web里，換句話說就是做到瀏覽器里，這樣的話web app只要調(diào)用簡(jiǎn)單的Javascript API就可以做RTC了，所以Google就買了GIPS公司，我也就加入到了Google團(tuán)隊(duì)里。WebRTC基本上就是在我們?cè)瓉淼腣oice Engine和Video Engine基礎(chǔ)上做出來的。如果熟悉WebRTC代碼的朋友可能還知道現(xiàn)在還有個(gè)文件叫做Video Engine就是原來我們的名字。再后來我從Google離職，聯(lián)合創(chuàng)立了現(xiàn)在的公司叫Cybrook，目前我們主要在舊金山的硅谷和蘇州有研發(fā)團(tuán)隊(duì)，國(guó)內(nèi)的公司就叫蹤視通，我們主要專注于實(shí)時(shí)音視頻的應(yīng)用和技術(shù)，我們的主打的產(chǎn)品是叫TeamLink的一個(gè)云視頻會(huì)議系統(tǒng)，目前在全球 200 多個(gè)國(guó)家有近千萬的用戶。

我今天分享的題目是云視頻會(huì)議系統(tǒng)的私有化實(shí)踐。

我們公司的主打產(chǎn)品是云視頻會(huì)議系統(tǒng)，當(dāng)我們?cè)谕卣箛?guó)內(nèi)市場(chǎng)的時(shí)候，我們發(fā)現(xiàn)國(guó)內(nèi)的用戶對(duì)于私有化的需求是很大的，所以我今天主要想給大家分享一下我們?cè)趶脑埔曨l會(huì)議系統(tǒng)到給客戶做私有化部署過程中的一些經(jīng)驗(yàn)和心得，希望對(duì)大家有所幫助。我的分享會(huì)分為三部分：前面兩部分會(huì)介紹幾個(gè)比較典型的客戶需求，然后看看我們是如何解決這些需求的，第三部分會(huì)分享一下，怎么給用戶做私有化部署以及后續(xù)的運(yùn)維。

01 私有化

那我們先進(jìn)入第一部分，私有化。講私有化之前，我們首先需要知道為什么用戶需要私有化部署，也即公有云服務(wù)有什么問題。上方是一個(gè)簡(jiǎn)單的示意圖，大概有這么幾方面的問題：首先是并發(fā)性，主要是內(nèi)網(wǎng)出入口帶寬的限制。假設(shè)說有一個(gè)公司內(nèi)部有很多員工都在使用云視頻會(huì)議，我們知道云視頻會(huì)議相對(duì)來說是一個(gè)需要較多帶寬的一個(gè)應(yīng)用，如果很多人同時(shí)使用的話，我們可以想見出口的網(wǎng)絡(luò)帶寬就會(huì)變得非常的擁堵。這不但會(huì)影響云視頻會(huì)議的效果，而且也會(huì)影響其他需要使用網(wǎng)絡(luò)的同事，這是云視頻會(huì)議的其中一個(gè)問題；第二個(gè)問題是對(duì)于一個(gè)語音視頻會(huì)議系統(tǒng)，它的網(wǎng)絡(luò)傳輸是通過公網(wǎng)的，但我們知道公網(wǎng)的穩(wěn)定性不是特別有保障，所以這種情況下，如果客戶對(duì)于視頻會(huì)議網(wǎng)絡(luò)的畫質(zhì)有特別高的要求的話，有可能是無法滿足的；第三個(gè)問題就是安全性。因?yàn)樵埔曨l會(huì)議系統(tǒng)的會(huì)議數(shù)據(jù)是要傳輸?shù)皆贫朔?wù)器去做緩存和處理的，所以對(duì)于安全性要求特別高的客戶也是一個(gè)問題。當(dāng)然，我們也知道云視頻會(huì)議系統(tǒng)有很多好處，一個(gè)比較顯著的優(yōu)點(diǎn)就是它特別方便，你自己不需要任何維護(hù)，基本上只需要下載一個(gè)APP，隨時(shí)隨地有網(wǎng)絡(luò)就可以開會(huì)了。

那么我們要如何去解決公有云架構(gòu)的問題呢？

我們想到的第一個(gè)的方案是做全私有化的部署，基本上就是把所有需要的服務(wù)器在私網(wǎng)里面部署，因?yàn)榭蛻舳撕头?wù)器都在內(nèi)網(wǎng)，我們就不需要再使用出口帶寬了，所以出口帶寬就不是問題。第二個(gè)，因?yàn)閮?nèi)網(wǎng)的網(wǎng)絡(luò)環(huán)境相對(duì)來說更加地穩(wěn)定和高速，所以畫質(zhì)也會(huì)有保障。再者，因?yàn)閿?shù)據(jù)并沒有出內(nèi)網(wǎng)，實(shí)現(xiàn)了物理上的隔絕，所以安全性上也更高。

當(dāng)然這也是有代價(jià)的，首先你需要在公司里有一套服務(wù)器并不斷地維護(hù)，另外一個(gè)比較大的問題是外網(wǎng)的用戶是無法加入到會(huì)議里的。假設(shè)有些同事可能在家上班或者出差的話，就會(huì)造成很大的不便；另外，因?yàn)樗沁B接的私有服務(wù)器，所以一般需要一個(gè)定制的客戶端或者至少需要在客戶端里配置一下才能連接到私有的服務(wù)器。

這就是全私有化部署的優(yōu)缺點(diǎn)，這套方案的特點(diǎn)是比較簡(jiǎn)單，實(shí)際上也可以滿足一部分客戶的需求，但是實(shí)際的客戶需求往往會(huì)比這個(gè)要略復(fù)雜一些。

02混合云

所以我們下面進(jìn)入第二部分，怎么用混合云來解決一些更復(fù)雜的需求。

比如這個(gè)客戶他首先要求能夠得到所有私有化部署的好處，同時(shí)他還增加了幾個(gè)額外的需求：第一個(gè)，他希望外網(wǎng)的用戶也能夠很方便地加入會(huì)議，這其實(shí)是一個(gè)很合理的應(yīng)用場(chǎng)景，例如你有同事在外面出差或者你的合作伙伴開會(huì)都需要從外網(wǎng)加入；另外一個(gè)要求是比較方便地加入會(huì)議，比如我們不能要求用戶在外網(wǎng)的時(shí)候還要安裝VPN才能連到會(huì)議里；然后，客戶還要求不能占用太多的公司出口帶寬，因?yàn)槿绻饩W(wǎng)的用戶可以連到內(nèi)網(wǎng)使用服務(wù)器的話，就像上圖所示，假設(shè)有5個(gè)用戶正在開會(huì)，3個(gè)用戶是在內(nèi)網(wǎng)，2個(gè)用戶在外網(wǎng)，我們可以看到，私有服務(wù)器需要給每個(gè)外網(wǎng)的用戶發(fā)送一整套的音視頻數(shù)據(jù)，當(dāng)外網(wǎng)的用戶數(shù)量增加時(shí)，出口帶寬的使用就會(huì)成倍增加，可能占用太多出口帶寬；第三個(gè)需求是用戶希望不將公司的網(wǎng)絡(luò)端口直接暴露到公網(wǎng)上，因?yàn)榭赡軙?huì)有潛在的安全隱患。

討論最終的方案之前，我們可以先看一看一個(gè)典型的視頻會(huì)議系統(tǒng)都有哪些服務(wù)器組成。然后我們?cè)倏茨懿荒芨鶕?jù)這些服務(wù)器各自的特點(diǎn)進(jìn)行編排，有些部署在內(nèi)網(wǎng)，有些部署在外網(wǎng)，看能不能解決客戶的問題。

首先我們有一個(gè)賬號(hào)服務(wù)器，賬號(hào)服務(wù)器一般是負(fù)責(zé)用戶的登錄、注冊(cè)、用戶的好友關(guān)系管理以及用戶會(huì)議號(hào)的管理。我們知道如果想要在外網(wǎng)和內(nèi)網(wǎng)都能夠很方便地使用而且能夠互聯(lián)的話，賬號(hào)服務(wù)器應(yīng)該需要是同一個(gè)服務(wù)器，否則你在內(nèi)網(wǎng)使用一個(gè)賬號(hào)，到外網(wǎng)又要使用另外一個(gè)賬號(hào)，這樣的話就會(huì)很不方便。如果想要加一個(gè)好友可能也很復(fù)雜。另外這個(gè)服務(wù)器還有一個(gè)特點(diǎn)是它的流量其實(shí)不是很大，所以它不會(huì)對(duì)企業(yè)網(wǎng)的出口帶寬造成太多的影響，因此我們暫時(shí)認(rèn)為賬號(hào)服務(wù)器應(yīng)該放在公有云上。

第二種服務(wù)器叫做信令服務(wù)器，這個(gè)做RTC的同學(xué)比較清楚。它的主要作用是給通信雙方交換一些信令消息，比如說它們可以用什么編解碼器，在什么網(wǎng)絡(luò)端口，用什么加密密鑰。這個(gè)服務(wù)器的特點(diǎn)是它的流量不是特別大，第二個(gè)它一般不存儲(chǔ)信息，只在真正開會(huì)的時(shí)候用一下，會(huì)議結(jié)束以后就不用了。所以這個(gè)服務(wù)器我們可以認(rèn)為它只要內(nèi)網(wǎng)和外網(wǎng)的人都可以連接到，基本上就可以了，是放在公有云上還是在私有云上關(guān)系不是特別大，所以我們認(rèn)為信令服務(wù)器是都可以的。

第三個(gè)是媒體服務(wù)器，這個(gè)服務(wù)器的主要作用是處理和轉(zhuǎn)發(fā)音視頻的數(shù)據(jù)。早先的MCU還有現(xiàn)在的SFU都屬于是媒體服務(wù)器。絕大部分?jǐn)?shù)據(jù)是通過這個(gè)服務(wù)器進(jìn)行處理的，可以說這個(gè)服務(wù)器是一個(gè)主要矛盾。如果我們要解決內(nèi)網(wǎng)的帶寬問題的話，我們可能需要在私有云上部署一個(gè)媒體服務(wù)器，但是我們?cè)趺慈ソ鉀Q公有云可以方便連接的問題呢？那我們看一個(gè)方案。

這個(gè)是我們采用的混合云的架構(gòu)，這里有幾個(gè)點(diǎn)，首先我們?cè)诠W(wǎng)上部署了一個(gè)公網(wǎng)賬號(hào)服務(wù)器，那么用戶在內(nèi)網(wǎng)和外網(wǎng)使用都連接了同一個(gè)賬號(hào)服務(wù)器，這個(gè)賬號(hào)還有統(tǒng)一的會(huì)議號(hào)和好友關(guān)系。第二個(gè)點(diǎn)就是信令服務(wù)器可以在內(nèi)網(wǎng)，也可以在外網(wǎng)。那我們將其部署在外網(wǎng)，因?yàn)槿绻渴鹪趦?nèi)網(wǎng)的話，內(nèi)網(wǎng)的網(wǎng)絡(luò)防火墻可能就要打開一個(gè)額外端口，能夠讓外網(wǎng)的用戶訪問，如果把信令服務(wù)器也放在云端就沒這個(gè)問題了。第三個(gè)，我們部署了兩套媒體服務(wù)器，一個(gè)媒體服務(wù)器在內(nèi)網(wǎng)，另一個(gè)在外網(wǎng)。那么內(nèi)網(wǎng)和外網(wǎng)的用戶分別就近的加入各自的媒體服務(wù)器，這樣做的好處是內(nèi)網(wǎng)的防火墻上就只需要開一個(gè)口給媒體服務(wù)器，不需要將整個(gè)端口暴露給整個(gè)公網(wǎng)。第二個(gè)好處是，因?yàn)榉?wù)器和服務(wù)器之間進(jìn)行級(jí)聯(lián)，那么音視頻的數(shù)據(jù)的傳輸就對(duì)帶寬的使用得到最優(yōu)化，我們可以看下面的具體分析。

這是帶寬的對(duì)比圖，左邊方案里所有的客戶端都連到統(tǒng)一的媒體服務(wù)器，右邊的客戶端通過兩個(gè)媒體服務(wù)器進(jìn)行級(jí)聯(lián)，也就是我們剛剛說的混合云的架構(gòu)，我們可以看到同樣是5人的會(huì)議，3人在內(nèi)網(wǎng)，2人在外網(wǎng)，左邊的方案需要使用的出口帶寬是右邊的兩倍，因?yàn)樗@個(gè)服務(wù)器需要將音視頻數(shù)據(jù)分別發(fā)送給每一個(gè)外網(wǎng)客戶端，右邊只需要發(fā)送一份給外網(wǎng)的媒體服務(wù)器就可以。而且我們可以預(yù)想到，如果外網(wǎng)用戶增加的話，左邊方案的帶寬使用會(huì)成倍增加，假如外網(wǎng)用戶變成4倍的話，左邊方案的帶寬就會(huì)是右邊的4倍。

我們可以再回顧一下剛才客戶的需求。我們認(rèn)為該方案是比較理想的，它兼顧了私有部署的好處的同時(shí)讓內(nèi)、外網(wǎng)用戶也能夠很方便地使用，而且不占用太多出口帶寬，也沒有將公司網(wǎng)絡(luò)端口暴露到公網(wǎng)上。那么有了混合云的架構(gòu)加上全私有部署的架構(gòu)，我們已經(jīng)可以基本滿足大部分用戶的需求。

當(dāng)然可能還有一些更復(fù)雜的需求，那我們可以在現(xiàn)有的架構(gòu)的基礎(chǔ)上做一些變形，比如這個(gè)用戶的需求是在不同的點(diǎn)都有辦公室，比如他在北京和上海各有辦公室，那么我們只需要在混合云部署的架構(gòu)的基礎(chǔ)上，在不同的辦公室部署額外的媒體服務(wù)器，然后讓媒體服務(wù)器之間實(shí)現(xiàn)級(jí)聯(lián)就可以解決這個(gè)問題。

03部署，運(yùn)維

我們?cè)谇懊鎯刹糠纸榻B了幾個(gè)典型的客戶需求以及解決方案，對(duì)于私有化部署來說，除了方案以外，很重要的一點(diǎn)是部署和后續(xù)運(yùn)維，因?yàn)槟悴恢揽蛻舻那闆r是怎么樣的，差別會(huì)非常大。我們進(jìn)入第三部分來談一談我們?cè)诓渴鸷瓦\(yùn)維方面的一些方案。

我們大概知道服務(wù)的部署方式經(jīng)過了這樣一個(gè)演化過程，最早的時(shí)候大家把服務(wù)直接部署在硬件服務(wù)器上，后來有了虛擬化技術(shù)，大家就使用虛擬機(jī)部署服務(wù)。現(xiàn)在比較流行的是容器化部署，因?yàn)槿萜骰渴鹩泻芏嗪锰帲热缫恢滦?、可管理等。因?yàn)槲覀儫o法事先知道私有化部署的客戶環(huán)境，所以服務(wù)的可一致性以及可管理就非常重要，那么我們肯定要采用容器化部署?，F(xiàn)有服務(wù)如果沒有容器化的話，首先需要把它進(jìn)行容器化。

第二個(gè)，因?yàn)槲覀冎揽蛻舡h(huán)境千差萬別，可能有些客戶是有自己的機(jī)房，有些客戶可能就是買一臺(tái)主機(jī)來安裝服務(wù)，所以我們通常采用容器化加虛擬機(jī)的方案。我們一般先在虛擬機(jī)里把需要的服務(wù)器模塊配置好，然后將虛擬機(jī)的鏡像文件導(dǎo)出來交給客戶，客戶那邊的部署就會(huì)比較簡(jiǎn)單了，他只要啟動(dòng)虛擬機(jī)的鏡像，然后做一些簡(jiǎn)單的網(wǎng)絡(luò)配置，基本上就可以把整個(gè)服務(wù)跑起來。

服務(wù)并不是只有一個(gè)服務(wù)模塊，視頻會(huì)議系統(tǒng)通常是由多個(gè)服務(wù)模塊構(gòu)成的，所以我們需要考慮容器的編排，其中一個(gè)方案是采用docker compose。只要我們把配置文件寫好需要哪些容器，它們之間的依賴關(guān)系如何，設(shè)置好后只要一個(gè)命令，就可以把所有服務(wù)都啟動(dòng)起來。我們一般是在虛擬機(jī)里把容器都安裝好，配置好導(dǎo)出成一個(gè)類似OVA的鏡像文件，這樣一來，客戶部署是十分方便的。

docker compose比較適合做單機(jī)部署，因?yàn)樗貏e簡(jiǎn)單易用，如果在單機(jī)部署時(shí)只有一臺(tái)機(jī)器，上面跑多個(gè)container，用docker compose配置好就可以。但它的缺點(diǎn)是不太適合多機(jī)部署，如果你有多臺(tái)服務(wù)器，用docker compose的話后續(xù)管理會(huì)比較麻煩，比如你要升級(jí)服務(wù)就要登錄到每一臺(tái)虛擬機(jī)器進(jìn)行操作，虛擬機(jī)之間也沒有統(tǒng)一的方法可以查看每一個(gè)容器的運(yùn)行狀態(tài)，虛擬機(jī)之間的容器也沒法互相發(fā)現(xiàn)。另外一個(gè)就是虛擬機(jī)的資源利用不充分，因?yàn)樗歉髯耘渲玫?，所以即使虛擬機(jī)有剩余資源也沒辦法進(jìn)行統(tǒng)一的調(diào)配。

所以對(duì)于比較復(fù)雜的部署，我們通常采用k8s的方式去部署。我們通常制作兩個(gè)虛擬機(jī)的鏡像，一個(gè)是k8s的nodes，另外一個(gè)是docker image的repo。我們把docker鏡像放在docker image repo里，然后k8s node的配置指向docker image repo，這樣的話啟動(dòng)了以后k8s的node就從docker image repo里拉取相應(yīng)的image來啟動(dòng)它的服務(wù)模塊。這個(gè)方式比較適合略復(fù)雜一些的，特別是多機(jī)的部署。

使用了k8s以后，升級(jí)一個(gè)服務(wù)，我們只需要把docker image推到repo里，然后登錄任意一臺(tái)的master-node就可以通過kubectl完成升級(jí)。管理服務(wù)也非常簡(jiǎn)單，因?yàn)閗8s是一個(gè)集群，所以所有的服務(wù)、虛擬機(jī)、資源、情況都可以很簡(jiǎn)單地查看。而且虛擬機(jī)的資源能夠更充分利用，如果某一臺(tái)虛擬機(jī)有較多的資源，k8s可以自動(dòng)把某些pod分配到空閑的虛擬機(jī)上。因?yàn)閗8s有自帶的負(fù)載均衡策略，我們可以利用它的高可用，如果 pod 出問題，那它會(huì)自動(dòng)剔除，創(chuàng)建新的pod。當(dāng)然這些也不是沒有代價(jià)的，這種部署需要?jiǎng)?chuàng)建一個(gè)k8s的集群，相對(duì)比docker compose一臺(tái)機(jī)器就搞定來說，k8s會(huì)更復(fù)雜一些，所以它比較適合集群化部署。

我們給客戶部署完了還有后續(xù)的運(yùn)維，如果我們采用k8s就可以用k8s的命令函工具或者用圖形的dashboard界面做運(yùn)維。

當(dāng)然，為了能夠更加定制化，也可以做自己的定制運(yùn)維平臺(tái)。因?yàn)槲覀冎纊8s提供一整套的HTTP接口，在這個(gè)接口的基礎(chǔ)上實(shí)現(xiàn)定制平臺(tái)是比較容易的，但如果你采用的是docker compose的方法的話，那可能就需要做一些額外工作，因?yàn)樗皇翘貏e適合多機(jī)的部署。

以上就是我的全部分享內(nèi)容。主要介紹了一些我們遇到的常見的私有化部署的需求以及我們的方案，另外介紹了一下我們最新的部署和后續(xù)的運(yùn)維，希望對(duì)大家能夠有所幫助。謝謝大家！

審核編輯 ：李倩