云视频会议系统私有化实践

点击上方“LiveVideoStack”关注我们

▲扫描图中二维码或点击阅读原文▲

了解音视频技术大会更多信息

编者按：云视频会议系统支持多服务器动态集群部署，并提供多台高性能服务器，大大提升了会议稳定性、安全性、可用性。视频会议为用户大幅提高沟通效率，提升内部管理水平，已广泛应用在政府、交通、运营商、教育、企业等各个领域。本次LiveVideoStack特别邀请到了来自Cybrook的吴荣华老师，为我们从私有化、混合云、运维与部署等方面，分享他和团队在云视频会议系统私有化的实践经验。

文/吴荣华

整理/LiveVideoStack

先简单介绍下我自己。我叫吴荣华，是踪视通的联合创始人与工程副总。我最早是在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会更复杂一些，所以它比较适合集群化部署。