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

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

我今天分享的題目是云視頻會議系統的私有化實踐。

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

01 私有化

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

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

我們想到的第一個的方案是做全私有化的部署，基本上就是把所有需要的服務器在私網里面部署，因為客戶端和服務器都在內網，我們就不需要再使用出口帶寬了，所以出口帶寬就不是問題。第二個，因為內網的網絡環境相對來說更加地穩定和高速，所以畫質也會有保障。再者，因為數據并沒有出內網，實現了物理上的隔絕，所以安全性上也更高。

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

這就是全私有化部署的優缺點，這套方案的特點是比較簡單，實際上也可以滿足一部分客戶的需求，但是實際的客戶需求往往會比這個要略復雜一些。

02混合云

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

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

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

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

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

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

這個是我們采用的混合云的架構，這里有幾個點，首先我們在公網上部署了一個公網賬號服務器，那么用戶在內網和外網使用都連接了同一個賬號服務器，這個賬號還有統一的會議號和好友關系。第二個點就是信令服務器可以在內網，也可以在外網。那我們將其部署在外網，因為如果部署在內網的話，內網的網絡防火墻可能就要打開一個額外端口，能夠讓外網的用戶訪問，如果把信令服務器也放在云端就沒這個問題了。第三個，我們部署了兩套媒體服務器，一個媒體服務器在內網，另一個在外網。那么內網和外網的用戶分別就近的加入各自的媒體服務器，這樣做的好處是內網的防火墻上就只需要開一個口給媒體服務器，不需要將整個端口暴露給整個公網。第二個好處是，因為服務器和服務器之間進行級聯，那么音視頻的數據的傳輸就對帶寬的使用得到最優化，我們可以看下面的具體分析。

這是帶寬的對比圖，左邊方案里所有的客戶端都連到統一的媒體服務器，右邊的客戶端通過兩個媒體服務器進行級聯，也就是我們剛剛說的混合云的架構，我們可以看到同樣是5人的會議，3人在內網，2人在外網，左邊的方案需要使用的出口帶寬是右邊的兩倍，因為它這個服務器需要將音視頻數據分別發送給每一個外網客戶端，右邊只需要發送一份給外網的媒體服務器就可以。而且我們可以預想到，如果外網用戶增加的話，左邊方案的帶寬使用會成倍增加，假如外網用戶變成4倍的話，左邊方案的帶寬就會是右邊的4倍。

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

當然可能還有一些更復雜的需求，那我們可以在現有的架構的基礎上做一些變形，比如這個用戶的需求是在不同的點都有辦公室，比如他在北京和上海各有辦公室，那么我們只需要在混合云部署的架構的基礎上，在不同的辦公室部署額外的媒體服務器，然后讓媒體服務器之間實現級聯就可以解決這個問題。

03部署，運維

我們在前面兩部分介紹了幾個典型的客戶需求以及解決方案，對于私有化部署來說，除了方案以外，很重要的一點是部署和后續運維，因為你不知道客戶的情況是怎么樣的，差別會非常大。我們進入第三部分來談一談我們在部署和運維方面的一些方案。

我們大概知道服務的部署方式經過了這樣一個演化過程，最早的時候大家把服務直接部署在硬件服務器上，后來有了虛擬化技術，大家就使用虛擬機部署服務。現在比較流行的是容器化部署，因為容器化部署有很多好處，比如一致性、可管理等。因為我們無法事先知道私有化部署的客戶環境，所以服務的可一致性以及可管理就非常重要，那么我們肯定要采用容器化部署。現有服務如果沒有容器化的話，首先需要把它進行容器化。

第二個，因為我們知道客戶環境千差萬別，可能有些客戶是有自己的機房，有些客戶可能就是買一臺主機來安裝服務，所以我們通常采用容器化加虛擬機的方案。我們一般先在虛擬機里把需要的服務器模塊配置好，然后將虛擬機的鏡像文件導出來交給客戶，客戶那邊的部署就會比較簡單了，他只要啟動虛擬機的鏡像，然后做一些簡單的網絡配置，基本上就可以把整個服務跑起來。

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

docker compose比較適合做單機部署，因為它特別簡單易用，如果在單機部署時只有一臺機器，上面跑多個container，用docker compose配置好就可以。但它的缺點是不太適合多機部署，如果你有多臺服務器，用docker compose的話后續管理會比較麻煩，比如你要升級服務就要登錄到每一臺虛擬機器進行操作，虛擬機之間也沒有統一的方法可以查看每一個容器的運行狀態，虛擬機之間的容器也沒法互相發現。另外一個就是虛擬機的資源利用不充分，因為它是各自配置的，所以即使虛擬機有剩余資源也沒辦法進行統一的調配。

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

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

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

當然，為了能夠更加定制化，也可以做自己的定制運維平臺。因為我們知道k8s提供一整套的HTTP接口，在這個接口的基礎上實現定制平臺是比較容易的，但如果你采用的是docker compose的方法的話，那可能就需要做一些額外工作，因為它不是特別適合多機的部署。

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

審核編輯 ：李倩