CCtalk高可用多媒体服务技术选型与实现

简介: 版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/vn9PLgZvnPs1522s82g/article/details/81124938 ...
版权声明:本文为博主原创文章,未经博主允许不得转载。 https://blog.csdn.net/vn9PLgZvnPs1522s82g/article/details/81124938

640?wx_fmt=jpeg


本文来自沪江技术中心开发经理杨福强在LiveVideoStackCon 2017上的分享,并由LiveVideoStack整理而成。杨福强于2012年加入沪江,主要从事教学互动平台CCtalk的开发,今天他将为我们分享高品质教学平台的一些技术难点和解决方案。


文 / 杨福强

整理 / LiveVideoStack


关于CCtalk


CCtalk是沪江旗下的支持互动教育平台,它提供网师服务,支持老师签约入驻,拥有基于云,大数据和AI的个性化课程推荐,同时也支持社群化学习,可以通过课前预习,课后答疑和视频回放等来沉淀学习用户,而且还有非常丰富的教学工具,包括实时多向音视频服务,双向白板,屏幕分享,讲义,教学小工具等等。


今天我会从五个方面来给大家介绍:


1,主流直播方案介绍

2,客户端AV引擎

3,服务端架构演进

4,录制回顾以及旁路推流

5,高并发场景案例分析


1、主流直播方案


主流的直播方案,我把它分为四类:RTMP,HTTP-FLV,HLS和RTP

下面介绍一下各自的特点:


1)RTMP


640?wx_fmt=png


RTMP的优点是CDN加速成熟,成本低,可用的开源库,以及开源工具比较多,延迟一般在2到5秒。


2)HTTP-FLV


640?wx_fmt=png


HTTP-FLV的原理是服务器在响应HTTP请求时候,不返回Content-length字段,它使用HTTP协议来实现,不容易被防火墙拦截,延迟略低于RTMP,但都是秒级的。


3)HLS


640?wx_fmt=png


HLS的优点是CDN分发容易,成本低,可以在HTML5页面中直接打开观看,但它延迟一般大于12秒。


4)RTP


640?wx_fmt=png


RTP一般是各家自研,相比于传统的直播方案来讲,自研方案不支持CDN加速,且成本贵,延迟一般是200到800毫秒之间。


2、客户端AV引擎


教育直播-CCtalk是基于RTP协议自主研发的,它的传输层支持UDP和TCP两种方式,支持网师之间以及任意观众之间的连麦互动,连麦延迟和观众延迟都是毫秒级的,同时它支持PPT,白板笔,答题卡,文字等多种不同形式的教学互动。下面介绍CCtalk的软件架构图:


640?wx_fmt=png


从图中可以看到,所有的客户端与信令系统之间有一个TCP长连接,来实现PPT、白板笔、答题卡、文字聊天等等教学相关的小工具;所有的用户与媒体服务之间有一路TCP或UDP的连接,实现老师与学生之间的双向实时音视频互动,比如说老师上课的时候,将产生的实时音视频数据发送到媒体系统,媒体系统按照一定的路径将媒体数据发送到学生端;如果学生端也上麦了,那么学生端产生的音视频数据也会经过媒体系统转发到老师端,这样就完成了一个教学场景下的双向音视频互动。同时,媒体服务会旁路推流一路RTMP到CDN,学生端可以在HTML5网页里直接观看实时单向直播,这样就满足了在大型直播中网页传播的诉求。另外媒体服务器会将上课时产生的音视频数据发送一路到录制服务,同时信令系统会将上课时产生的PPT、白板笔以及文字聊天等内容发送一份到录制服务,录制服务收到所有上课内容后,将它们以元素的形式存储下来,存储下来的这个格式叫做OCS回顾,便于课后回顾。


因此教育直播架构须具有的以下特性才能满足需求:


640?wx_fmt=png


而CCtalk就是这么一个支持多种教学工具的实时大规模并发教学平台。在最开始实现这个平台的时候,我们采用了一些开源方案,如webrtc,但后来发现直接使用开源方案无法为完全满足教育直播的需求,因此我们自研发了一套客户端AV引擎:


640?wx_fmt=png


下面我会针对引擎的网络部分做一个简单的介绍,主要介绍用到的几个关键的技术。首先思考一个问题:当客户端在使用媒体引擎的服务时,需要做的第一件事是什么呢?


答:需要找一个网络质量较高的边缘节点接入。


640?wx_fmt=png


如上图所示,假如我们有一百个边缘节点,用户需要从这一百个里面选一个到他的网络质量较高,那么该如何选择呢?可能你首先想到的是DNS解析,但其实只靠DNS解析是不够的,我们还需要一套自动寻路机制,如下图所示:


640?wx_fmt=png


以小网络为例,它的每次DNS解析的结果可能是变化的,我们无法保证它寻到的结果一定是最优的。当用户接入到边缘节点之后,在使用过程中,用户的网络在不断变化的,因此我们还需要有一个动态检测的机制,如果引擎检测到网络波动较大的情况,那么需要再次启动自动寻路机制,再给它找一个网络质量较高的边缘节点接入。此外,由于网络一直在变化,为了适应这种不断变化的网络,我们还需要一套拥塞控制机制,在这里我推荐Google的GCC拥塞控制算法:


640?wx_fmt=png


这个拥塞控制可以分为发送端基于丢包的网络估计,以及接收端基于延迟的网络估计两部分,总结下来,就是根据丢包率以及延迟控制发送端的码率。除此之外,当我们的码率开始降低的时候,是不能一直降低下去的,因为码率降低意味着音视频质量的下降。我们还需要另外一套补充机制,叫做消峰处理:


640?wx_fmt=png


消峰处理的原理是将比较大的数据分成若干个包,在一定时间内发送出去。但这会带来延时的增大,因此需要控制发包的间隔大小。最后,当数据在传输当中由于误码等因素导致丢包时,我们还需要丢包重传的机制来进一步的提升网络的质量。总结下来,其实整个客户端引擎的网络部分,其实就是在做一件事:在实时性与质量之间权衡,而且这个权衡具有一定的自适应能力。


3、服务端架构演进


640?wx_fmt=png


这张图的上半部分在前面已经介绍过了,就是客户端的引擎部分,下半部分是对应的媒体服务器的一些功能。最初的CCtalk服务系统是由第三方提供的,开发简单,成本低,但确实存在一些问题。后来我们自主研发了一套服务端体系,架构如下:

 

640?wx_fmt=png


这个架构分为两大部分:信令系统和媒体系统,整个架构中的所有服务设计功能单一、结构简单,并且所有节点支持线性扩展,理论上它能承载的人数是没有上限的,你只要加机器就可以了,所有的节点支持失效自动转移,这套系统我们用了很长一段时间,但在使用的过程中还是发现了一些问题,以媒体系统为例,首先一个是问题是存在中心节点,这就意味着所有的数据都要先经过代理节点转发到中心节点,再发送到代理节点,最后发送到学生端,并且这个路径是固定的,所有的数据都要走这么长的路径,此外,系统之间有一定的耦合。为了解决这些问题,重新设计了新的媒体架构:


640?wx_fmt=png


首先,我们把信令系统与媒体系统之间解耦,也就是说他们之间相关的操作如加入房间,建立房间,全部放在客户端的AV引擎去实现;另外,我们去掉了中心节点,加入了转发节点的概念,所有的转发节点都是对等的,并且转发节点会将收到的音视频数据通过一个智能寻路算法自动找一条最优的路径。

整个媒体系统设计原则有两点:一是尽最大的可能找一条最优的路径,将数据尽快的发送到对端;二是在服务出现问题的时候,尽量的保证服务的可用性,并且让用户没有感知。


4、录制回顾以及旁路推流


下面讲一下录制回顾以及旁路推流,架构如下:


640?wx_fmt=png


具体如下,当 Server收到指令以及数据时,会将音视频数据发送到服务端的音视频引擎,服务端的音视频引擎会对这些数据做一些处理,压缩成一个大视频,将大视频存成MP4,并保存到云端,同时,将这个实时的视频流以RTMP的形式推到CDN,这样,HTML5页面就可以在线观看实时的网页直播;同时媒体录制服务器会将上课时产生的所有内容以元素集合的形式存储一份,我们把这个存储格式叫做OCS。下面就是直播或录播的流程图:

 

640?wx_fmt=png


录制OCS回顾视频过程如下:

 

640?wx_fmt=png


我们还有一套专门的OCS编辑器来帮助对OCS回顾进行二次编辑,编辑器可以将编辑之后的结果再次传到云端,这样学生就可以观看编辑之后的内容。

 640?wx_fmt=png


在这个过程中,我们使用的转码服务,前期用户量不大的情况下,我们使用CPU转码,单台16核的机器的并发数量可以达到40路,后面随着业务增长,对于转码集群的要求不断增大,所以我们改用了GPU转码,并发情况如下:


640?wx_fmt=png


5、高并发场景案例分析


高并发场景的案例分析,这一部分与实际的音视频没有太大的关系,但却存在教育场景当中不得不面对的一些问题,我首先举个例子,希望能够对大家有一定的启发。我们来想一个问题:同一个教室里,有20万人同时在听课,我们会遇到哪些问题,我们该如何解决这些问题?假设有20万人在同一个房间,每个人携带的数据量是30字节(例如:用户列表、用户ID、昵称等等),假设每台网关承载三千人,那么至少需要66台网关,正常情况下,假设每秒有800人进出房间,那么负载到每个网关上就是12人每秒的瞬间吞吐,所以算下来当有一个用户进房间,那么他拉取的这个数据量就是45Mb,他进房间的这一瞬间需要拉这么多的数据,每台网关承载的实时的吞吐量是554Mb,当出现异常时,比如说某台网关宕机或者脱离了核心服务,我们的负载均衡服务会将出现的问题的至少三千人负载到剩余的64台服务上,此时的网关负载增量是46.8人,异常时的网关瞬间流量是2Gb。总结下来存在的问题如下:


1)客户端带宽消耗太大

2)进入教室慢

3)服务并发处理量太大


那么,我们的应对策略是:


1) 精简信息+详细信息

2) 提供数据的版本机制,在一定范围内,只处理变化的数据。



640?wx_fmt=jpeg

相关文章
|
1月前
|
NoSQL Java Redis
【分布式技术专题】「分布式技术架构」手把手教你如何开发一个属于自己的分布式锁的功能组件(一)
【分布式技术专题】「分布式技术架构」手把手教你如何开发一个属于自己的分布式锁的功能组件
48 0
|
1月前
|
NoSQL Java Redis
【分布式技术专题】「分布式技术架构」手把手教你如何开发一个属于自己的分布式锁的功能组件(二)
【分布式技术专题】「分布式技术架构」手把手教你如何开发一个属于自己的分布式锁的功能组件
23 0
|
1月前
|
消息中间件 缓存 开发工具
一套分布式IM即时通讯系统的技术选型和架构设计
为了更好的理解分布式IM即时通讯系统的设计,我站在架构师的角度,在充分了解系统需求、业务流程和技术流程后,从全局视角为系统设定方案目标,对技术方案进行选型,对系统进行总体架构设计和分层架构设计,并梳理清楚发送消息的交互链路、单聊和群聊的交互链路。希望对你有帮助。
246 0
|
缓存 负载均衡 NoSQL
JD架构师告诉你亿级流量架构高性能、高可用、高扩展如何搭建的?
你们知道淘宝,京东这些购物商场吗?他们到了双11,双12为什么能支持全国14亿人口同时购物下单呢,因为他们的程序做到了高并发、高性能、高可用。那么你对程序员的三高了解多少呢?
|
开发者 微服务
语音直播源码开发,实现微服务架构的优势分析
语音直播源码开发,实现微服务架构的优势分析
|
消息中间件 运维 监控
业务开发转基础开发,这三种「高可用」架构你会么?
业务开发转基础开发,这三种「高可用」架构你会么?
|
存储 运维 NoSQL
开源OpenIM:高性能、可伸缩、易扩展的即时通讯架构
网上有很多关于IM的教程和技术博文,有亿级用户的IM架构,有各种浅谈原创自研IM架构,也有微信技术团队分享的技术文章,有些开发者想根据这些资料自研IM。理想很丰满,现实很骨感,最后做出来的产品很难达到商用标准。事实上,很多架构没有经过海量用户的考验,当然我们也不会评判某种架构的好坏,如果开发者企图根据网上教程做出一个商用的IM,可能有点过于乐观了。本文主要从我个人角度深度剖析100%开源的OpenIM架构。当然,世界上没有最完美的架构,只有最合适的架构,也没有所谓的通用方案,不同的解决方案都有其优缺点,只有最满足业务的系统才是一个好的系统。而且,在有限的人力、物力,综合考虑时间成本,通常需要做
1101 0
开源OpenIM:高性能、可伸缩、易扩展的即时通讯架构
|
弹性计算 缓存 负载均衡
云上高并发Web架构最佳实践
本文介绍云上高并发Web架构模型,以Wordpress应用为例,阐述云产品选择及架构部署、基础资源监控、应用实时监控、性能测试、应用防护的最佳实践。
云上高并发Web架构最佳实践
|
弹性计算 编解码 负载均衡
构建在线教育弹性高可用视频处理架构实战
对于负责建设视频处理系统的技术团队而言,这样的业务场景就留给了他们一系列的挑战。
1750 1
构建在线教育弹性高可用视频处理架构实战
|
存储 负载均衡 视频直播
短视频直播系统为什么需要分布式部署,浅谈分布式部署
短视频直播系统为什么需要用到分布式部署,了解这个问题之前,我们首先要理解,什么是分布式部署。分布式部署就是将数据分散的存储在多台独立的服务器上,采用可以扩展的系统结构,利用多台存储服务一起分担存储负荷,利用位置服务器定位存储信息。