专业 靠谱 的软件外包伙伴

您的位置:首页 > 新闻动态 > 大型直播视频APP软件开发设计方案分享!

大型直播视频APP软件开发设计方案分享!

2017-03-22 18:55:32

一直播产品是一下科技今年五月份刚上线的产品。得益于与微博的深度合作,以及与小咖秀、秒拍共同运营,一直播开始时就有一个很高的起点,短短半年内,达到同时在线用户百万级规模。以下是关于一直播千万级用户APP服务端架构设计和成长历程。

 

直播行业是今年最为火爆的行业,作为新兴的产品形态,直播产品最大的特点是:快。推流速度足够快,主播通过移动端快速推流,用户能快速看到直播场景,延迟需要足够低,而且移动端类型十分复杂、种类繁多,这是一个很大的挑战;首帧加载速度要足够快,用户打开直播页面时,能立即观看画面;支付也需要足够快,用户给主播送礼物时,保证直播时的互动效果;录制、转码、存储都需要足够快。

那么一直播是如何在短短半年内应对这些如此之快的要求呢?下面从业务结构、缓存、互动、调度四个方面为你揭开秘密。

业务结构——集群+模块化

f6979c3b973400438bd1d43ce6529fa44529aed2

一个优秀的互联网项目架构至少应该做到两点:第一点模块化拆分;第二点资源分层。将一个复杂的系统拆分成N个小系统,之后再对小系统进行功能优化。如上图所示,一直播平台架构的最前端是安全防护接入层,用于系统的安全防护;此后是URL路由,将流量从入口通过负载均衡按照用户请求URL下发到不同的模块上,再导流到后端不同的集群上,从源头上进行分流;URL路由之后是接口层,将后端的服务、功能模块的接口进行整合,之再后提供给前端用户。

下面具体看一下每个模块的功能与结构。

路由调度

879bfc296f8858d67d9301d7830039b29d4f6199

目前,一直播平台中采用二级域名+分层目录路由的方式进行URL分层,如member层、评论层、直播层等一级目录直接下发到不同集群上;二级目录做成对外的接口,如API、OpenAPI、Web层,再将其划分到内部接口、外接口或H5、PC上;第三层目录是真正处理的业务逻辑。

这样分层处理之后,后期的分集群优化就变得十分简单。

模块化拆分

e5d487926024676339b177b693a1ab3ccff40597

前端进行URL分层之后,后端需要按照业务功能进行模块拆分,将复杂的功能拆解,例如将用户系统拆解成一个独立的用户服务,再将用户服务拆分成用户注册、用户中心、关注关系等。模块化拆解之后,单模块资源共享,无交叉影响;同时,还可以将核心业务与非核心业务分开,核心业务放在核心资源池内,在突发流量到来时,可以优先保证核心业务的可用性,非核心业务进行降级或者关闭处理;此外,消息队列异步持久化,如图中所示的用户、缓存的后端持久化都是相互独立的,保证消息响应速度。

资源分层治理

a7ec8617b20e3bb3f596d4f7b443b60530523e43

接下来看一下资源分层治理,整个系统按照功能模块拆分后,各种资源分层之后,后期的资源治理就变得十分简单。在接入层,搜集全部日志资源,对所有的请求做分析,便于后期监控、数据分析等处理;在接口层,用户请求进来之后,下发到不同的接口集群上,接口集群对后端的服务进行组合封装。接口层承载了大量的压力,在预知大的活动发生前,可以在该层人工或系统自动扩容一批机器,例如在赵本山直播前,在该层将机器的数目增加一倍。服务层是真正的业务处理层,它包含了业务处理、缓存、数据持久化。服务层下侧是缓存和持久化层,之所以将二者分开,是因为缓存在互联网架构中的重要性不言而喻,在突发流量到来时,缓存至少可以承载系统80%-90%的压力。

数据库

8ffa0ad65aa6752790ee8fcdb5140965e89dbc10

一直播架构中按照模块、功能划分数据库,不同的数据库再分配到不同的物理机上,并非整个项目共用数据库。由于绝大数应用读远远大于写,因此,在该场景下可以对数据库进行读写分离,如Master-Slave、MySQL等方式;同时对数据库进行水平、垂直拆分。

缓存——多级缓存之演变

ece122d94f0aa09279f1551e209272ce16a5b497

基本的缓存模型如上图所示,服务层直接调用后端的缓存集群,但在一直播架构中增加了本地缓存。当某一大明星的直播开始时,在极短的时间内大量的粉丝会同时涌进一个直播间,此时主播的热度是非常高的,如果将全部请求都导入后端集群,势必给后端集群带来非常大的压力。当大量数据在短期内变化不是特别大时,可以在前端的业务层上本地缓存(可以采用Memcached、Reids等方式),通过在本地缓存3-5秒就可以承受80%-90%系统压力,瞬间化解后端缓存集群的压力。

后端的缓存集群的常规设计有两种:

  • 第一种是将大数据通过HASH模式分拆到后端不同机器上,加大可承载的数据量,这种方式的缺点是:当无法进行本地缓存只能采用远程集群时,如果过HASH模式将某Key下发到后端的某个节点上,会瞬间给该节点带来较大的压力,一旦该节点挂掉,前端的接口层和业务层会出现卡顿现象,进而导致整个系统瘫痪为了应对这种情况;
  • 第二种方式是目前一直播架构中采用的方式,在前端挂一层HASH模式,通过HASH将Key分布开,后端通过主从模式,做成一主多从的模式,进而解决热点key读取量大的难题。

在缓存中,还有一点需要注意的是:重点数据单独布署。如果对所有的集群全部按照第二种方式搭建,成本势必很高。由于大量的主播访问量并不是很高,如果进行主从部署时也会导致资源的大量浪费,因此对于大明星、网红等重点主播的Key可采取单独部署的方式,以节约资本。

互动——百万在线聊天室搭建

0b19082e27b542f44e53068dd461682d38d46046

谈到移动直播,互动必然是绕不开的话题。移动直播聊天室和传统的聊天室不同,他主要具有以下几个特点:

  • 用户集中在热点直播间
  • 热点直播消息量巨大
  • 消息实时性强
  • 用户进出直播间随机性大

刘烨和本山大叔的直播,单个直播间有百万级别的用户实时在线聊天、送礼互动。

a98093097f94fc34bbda0c63e9e5ba0f314d3a2c

那么支撑如此庞大用户的聊天室架构是如何设计的呢?如上图所示,一直播的聊天室架构主要分为接入层、路由层,其中接入层又分为连接保持层和业务逻辑处理层。通过在接入层保持用户的连接;路由层进行消息中转;业务层对接入层传入的消息进行处理。该架构需要保障可用性、扩展性和低延迟,首先接入层需要扩展,因为接入层需要挂在全平台在线的用户,所有消息的下发都是通过接入层处理;在路由层,消息量反而减小。

b54abbdae5128ebf85c6ce6fffc1443efb7de7c6

上图是平台消息的流转图。客户端上行消息之后,通过接入层接入业务逻辑处理;由于整个直播平台是构建在阿里云ECS上,而ECS单机挂载的用户量有限,因此消息经业务逻辑处理之后需要进入本地队列,将请求平滑后进行业务处理,平滑的过程取决于后端的处理线程,根据平台规模动态调整线程数量,保持消息队列中消息数目最少,从而保证消息到达的及时性。

业务逻辑层对消息进行处理后,将消息转发给后端的路由层;路由层根据消息的信号记录,通过路由层的索引规则发给其他路由节点;其它路由节点下发给自身挂载的接入节点;接入节点收到消息之后,同样进入消息队列,线程处理方式同上,对消息进行判断,如果是单方向的消息直接转发,多方向的消息循环转发给节点用户。

e3fd54a940c66ef518b0d04ca73a7afe49039a5d

对于大型直播间,由于移动端资源有限,对所有消息全部转发是不可能实现的,因此需要对消息进行限流。流控原则第一种方式式根据消息类型,如果将用户评论全部转发给客户端,则会出现滚屏现象,导致信息无法识别,这时需要对消息按时间维度进行管控(一分钟内下发定量消息);第二种方式是按照在线人数,将在线人数分区(几万个用户为一区),各分区间消息互通;第三种方式根据用户特征,对级别较低的用户和刚注册的用户的发言进行适当屏蔽。

调度——推流+播放

调度主要包括推流调度和播放调度。移动端和传统秀场直播不同,传统秀场通过PC端进行推流,移动端的网速、性能相比于PC端都存在一定的差距,因此移动端的推流受限于用户的设备和地理位置的不确定性,例如在一直播平台上,明星主播或网络红人的位置非常随机,有可能在非洲或者在巴西奥运会现场亦或是偏僻的山区,在这些场景下如果本地调度出现偏差,推流的质量就会非常差。

bf4d743a8d3fd6bd5f1a4d82cc0435e2b624e02e

目前一直播平台在推流和播放的调度方面采用的是第三方的CDN。如上图所示,用户需要推流,首先到调度中心获取离他最近的推流节点;用户将流上传到推流节点后,该节点将流分发到流控中心;流控中心再将流分发到内部的CDN网络上,内部的CDN网络再将该流下发到各个节点上。当用户需要播放直播时,首先到最近的调度节点上获取最近的播放节点,获取播放节点之后播放即可。目前播放协议上行支持RTMP;下行时Http/flv和M3U8效果更好,在H5上一般采用M3U8,移动端、PC端采用Http/flv。

 

关于:中科研拓

深圳市中科研拓科技有限公司专注提供软件外包、app开发、智能硬件开发、O2O电商平台、手机应用程序、大数据系统、物联网项目等开发外包服务,通过IT技术实现创造客户和社会的价值,成为优秀的软件公司,通过客户需求导向、开放式创新、卓越运营管理等战略的实施,全面打造公司的核心竞争力。优秀软件外包公司、软件开发公司,联系电话400-0316-532,邮箱sales@zhongkerd.com,网址www.zhongkerd.com


  上一篇   [返回首页] [打印] [返回上页]   下一篇