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

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

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

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

01 私有化

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

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

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

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

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

02混合云

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

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

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

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

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

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

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

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

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

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

03部署，運(yùn)維

我們在前面兩部分介紹了幾個典型的客戶需求以及解決方案，對于私有化部署來說，除了方案以外，很重要的一點(diǎn)是部署和后續(xù)運(yùn)維，因?yàn)槟悴恢揽蛻舻那闆r是怎么樣的，差別會非常大。我們進(jìn)入第三部分來談一談我們在部署和運(yùn)維方面的一些方案。

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

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

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

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

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

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

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

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

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

審核編輯 ：李倩