263运营级云视频平台搭建的技术迭代历程

本次LiveVideoStackCon 2020北京线下峰会我们邀请到了北京二六三企业通信有限公司技术总监李志涛来做分享。经过多年的打造，263云视频平台已经支持多协议、多种终端的使用场景，他将以视频+战略为导向，分享263运营级云视频平台搭建的技术迭代历程。

大家好，我是来自北京二六三企业通信有限公司的李志涛，主要负责公司音视频业务线的开发工作。

大家可能对263网络通信有限公司比较陌生，用一句话概括：263深耕行业20年，做最懂企业互联网通信的服务商。公司成立于1993年，前身是海诚寻呼。在1999年成为基础运营商以外国内最大的拨号接入服务商。2001年，263自建机房成为国内首批四星级IDC机房。2004年，263获得国家多方通信牌照的电信增值服务商。2005年，263推出的企业邮箱成为企业邮箱外包服务国内第一品牌。2010年，263网络通信在深圳上市，股票代码：002467，同年公司推出了263电话会议系统，这也是当年我们国内成长最快的远程会议服务提供商。2015年，263收购展视互动，成为了国内当时最大的多媒体互动直播技术服务商。2018年，263获得了国内首批移动转售牌照，推出企业定制移动化通信服务，同年263推出了视频+战略。自此战略上已经从之前的寻呼、接入、消息、邮箱、电话会议，到现在基于音视频的实时服务提供商，做了重大战略转型。

接下来，我将主要从四点来介绍263音视频这块，以视频+战略为导向，技术构建方面的迭代方向。 1 263云视产品简介

经过多年的打造，以263视频云为基础，支持多协议、多终端的使用场景，其中主要包括263云终端。云终端包括多款硬件终端，硬件终端主要根据企业办公场景，针对个人参会、小型会议、中型会议、大型会议时，我们提出了多种终端的解决方案。除了会议室级别的，我们也支持任何场景、任何地域、任何时间都可以从移动端、PC端、Windows端、Mac端、iOS端、安卓端入会，进行实时音视频会议沟通。 263视频云对各种音视频通信方式做了整个协议层的兼容，以WebRTC协议为主，兼容了VP8/VP9/H.264等编解码方式，以及对多浏览器的兼容适配，对微软Lync协议的接入支持。现有相当数量的企业客户拥有大量的基于SIP和H.323协议的硬件终端，263视频云对这些终端也做了协议支持，可以直接进行接入使用。有些客户购买的成本比较高的思科、宝利通的硬件的MCU，我们打通了整个的视频云来接入使用。 视频云对我们传统的PSTN网络的电话会议进行了融合接入。移动电话以及座机可以通过电话会议平台来进行音频接入，与视频云进行音频的融合。视频云的实时内容以RTMP标准协议推送到云端进行直播或点播。 1.1 能力矩阵

263视频云系统的整个能力矩阵主要是有业务的管理系统、支撑管理、用户管理、多业务平台的管理、用户认证及权限信息管理。263视频云提供了多种视频服务场景：会议服务是解决企业远程办公的；教育类服务，像大班、小班、双师还有K12；远程医疗服务，远程医疗培训讲解、远程手术等。 消息系统，主要有以下几类消息，IM消息、应用消息、消息通知；信令中转系统，包括语音信令、音视频信令、调度信令。出席系统主要是解决了用户在登入之后，对他的消息调度进行定位与管控。 实时RTC系统是我们的核心，包括WebRTC Service、Streaming Service。WebRTC Service主要接入的是用户实时音视频通信的Web服务和App的服务，Streaming Service主要接入的是用户推流和直播服务。Core核心系统主要是进行整个集群的管理和调度，包括整个集群硬件可用性的管理，硬件服务器上限、下限的管理，负载均衡与失效转移的管理，系统平行扩展的管理，根据系统负载情况进行ROOM级别的任务调度管理。基于音视频配置进行MCU转码和混屏处理。SIP Service主要是解决了和外系统SIP模块的对接，包括电话会议和基于SIP限令的第三方硬件、第三方系统。Recording 是对会议、教育、远程医疗等业务有录制需求的，进行按需录制的服务。 263直播网络，主要对接到263现有的直播系统，同时也向阿里云、腾讯云进行推流。导播台基于推流直播时做一些导播、插播的增值服务功能。直播管理针对直播的权限、直播会场管控等进行管理。云存储是与录制件相关联的，录制件基于对象存储方式存放在云存储之后，可以进行相关业务需求的VOD点播。 公共应用系统有多重应用服务，调查问卷、投票、打赏等。电话会议系统以硬件会议桥为核心的PSTN会议系统。SIP MCU可以对接外系统SIP MCU或与SIP终端进行对接。 1.2 SaaS&PaaS

我们提供SaaS&PaaS的接口能力，上半部分主要是SaaS层的能力，会议类、教育类的应用，还有远程医疗类的应用。整个系统包括消息SDK、共享SDK、标注SDK， RTC的SDK、点播SDK和直播SDK。我们也可以给有深入开发能力的客户提供PaaS层能力的开发接口。整个调用方式是方法、函数调用，底层基于Socket或RPC形式进行通信。 2 技术架构

接下来是近几年我们整个的技术架构的迭代的步骤。

263云视技术开源基础基于Google开源的WebRTC和Intel开源的OWT这两个项目。 2.1 架构拓扑V1.0

整个的技术框架是从第一代开始搭建。第一代系统，按照功能分为两层构建，采用集群分布式部署，基本分布了4类IDC，第一层IDC是我们核心的BJ DC，第二层主要解决国内南北互联互通，跨运营商访问的接入问题。针对海外用户访问系统，我们提供了海外接入点。 到目前为止，由于对成本的考虑，不可能对全国各大城市都去布机房布节点，所以我们在用户使用比较多的地方，布了几个节点，其他的节点我们目前使用阿里云进行补充。我们主要使用阿里云的ECS和它的带宽，目前就全国用户接入263视频云系统来说访问阿里云的几个节点质量还是不错的，可以保障国内用户使用的全覆盖。这是我们整个系统架构拓扑的1.0系统。 1.0系统最大的问题是同区域同运营商不同IDC的交互都需要到中心节点交换，成本较高。再有数据链路较长，用户延时比较大，针对RTC应用来说，正常是在400毫秒可以接受，而物理距离来回两千公里，这个延时可观。基于这些问题，我们开发了2.0版本。 2.2 架构拓扑V2.0

基于架构拓扑1.0的问题，我们开发了2.0版本,主要做了一个分层，加了一个Relay 池，同一区域，相同运营商，或是跨区域相同运营商的用户访问层之间可以互通。如果他们之间不能互通，可以通过Relay池进行互转，这个Relay可以进行平衡扩展的。整个架构从1.0的二层变成了2.0的三层，北京IDC及Relay层IDC走的是多线BGP机房进行部署。 针对海外，基于美国、德国、欧洲、香港加了Relay层节点。用户是基于本地进行交互的，直接从本地走，不需要到核心机房进行数据中转，用户的延时感受会很好。同时北京的核心机房做了高可用改造，当其中一个核心机房遭到攻击，可以迅速进行热备切到其他机房。 2.3 媒体信令逻辑

系统中媒体信令逻辑主要体现了三个层，背景核心层，中间的多线接入机房Relay层，还有用户就近访问的接入访问层。核心逻辑OWT Core，基于Intel的OWT来进行的二次开发，主要负责整个系统的计算、管控、调度。SRC解决智能选路问题，用户会在全球各地接入访问，SRC负责找到一个离他访问网络质量最好的Access。MC系统负责服务器可用性的访问甄别，分配负载低、运行同质业务的服务器给用户。 3 媒体通讯模式

3.1 基本模式

目前263云视频各方面的技术保障已经能解决一些接入访问的质量问题，但如果一些业务场景、业务模式错误地使用了基本通信模式，导致流量增大、带宽受限、服务器计算资源占用过高，网络抖动、丢包、延迟对实时音视频适量的影响较大等问题。上图主要表述了WebRTC目前为止使用的几种通信模式。第一种MESH模式，WebRTC两个点是直连的，媒体走P2P方式进行互通。 第二种SFU与MESH之间有一些共性，区别是它把所有的媒体都经过服务器进行转发。针对每一个客户端，流的上行是1路，下行是n-1路。两者劣势基本一样，优势是流通过服务器进行Relay，便于混流推流直播或者其录制操作。 第三种是基于MCU方式，MCU好处是1路上行，1路下行，客户端耗费带宽小，由于该种模式需要对音视频进行Mixer混流，消耗服务器CPU及GPU的计算资源。以上几种通信模式各有利弊，后续会讲到基于不同业务使用场景而采用的基本通信方式外加混合通信方式的组合方式。 3.2 版本1.0

上图是1.0使用的数据流程图。Client按照业务逻辑进行音视频的发布和订阅，右边是服务器，在1.0中我们同时支持MCU和SFU。我举例了4个Access模块，虚线代表基于UDP协议的用户层访问。如果用SFU模式的话，就不涉及服务器后台的运算能力。端上使用不同的编解码方式也会使用到服务器后台的MCU模块的转码能力，转码之后再进行下发客户端。采用MCU的业务场景会到MCU模块进行音频和视频的混音合屏。在这个版本中SFU缺少SVC或Simulcast的加持，所以音视频质量不好保障。 3.3 版本1.5

我们在中间又推出了1.5版本，主要用服务器MCU合屏，客户端屏幕剪切方式实现了用户使用场景的灵活性。剪切完以后每一路都是可以单独显示，灵活布局。 3.4 版本2.0

2.0版本基于1.0版本演变而来，原有SFU增加了Simulcast功能，同时也沿用了MCU。MCU我们又做了一些功能的拓展，包括RTMP推流，RTMP推流时可以按照用户自定义的编码格式、自定义布局推送。可以和SIP网关打通，既可以和硬件MCU系统进行融合，也可以通过SIP网关与PSTN电话会议进行融合。 3.5Hybrid模式

这是前面提到的，我们整个系统是基于SFU和MCU这种方式来实现。SFU的优势是灵活分发、并发高，实时性也高，劣势是下行转发路数多，带宽占用高，影响体验，客户端维护多路连接的成本高。MCU的优势是下行带宽占用少，劣势是服务器性能要求高，部署成本太高，同时增加服务器环节，实时性略差。 我们采用的混合模式是基于MCU+SFU，业务场景决定了用MCU还是SFU。如果是五方以下的，SFU优势还是合适的，成本较低。如果是超过6方以上的，客户的附加值高一些的话，使用MCU计算资源。交互方式决定通信模式。 4 运营级技术叠加

我们刚才讲了WebRTC和OWT这块。我们在实际使用中，根据我们遇到的弱网质量问题，优化了音视频传输的NACK和FEC功能。解决音视频唇音不同步的问题。通过切流功能，解决我们在MCU方式下用户的各端TV端、电脑端、移动端等所希望收到不同分辨率的问题，大屏是1080P，PC端是720P，移动端可能是360P已经足够了。同时也解决了不同的用户根据自己的网络质量获取不同码流数据的问题。 系统在跨IDC时，集群内部偶发网络闪断，会出现一些异常，增加了容错机制确保系统的健壮性。数据库方面使用了MongoDB集群，RabbitMQ消息总线使用了HAProxy+3RMQ高可用。 以上这些分享都是我们对这套系统所做的一个适合运营级的改造。

责任编辑：lq