千万级用户直播APP——服务端结构设计和思考

转载 2017年01月03日 15:15:25

摘要: 在2016杭州云栖大会的“开发者技术峰会”上,来自一下科技的技术副总裁张华伟给大家解密了一直播千万级用户服务端架构设计和成长历程。

一直播产品是一下科技今年五月份刚上线的产品。得益于与微博的深度合作,以及与小咖秀、秒拍共同运营,一直播开始时就有一个很高的起点,短短半年内,达到同时在线用户百万级规模。在2016杭州云栖大会的“开发者技术峰会”上,来自一下科技的技术副总裁张华伟给大家解密了一直播千万级用户服务端架构设计和成长历程。

以下内容根据演讲PPT及现场分享整理。


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

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

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

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。


火爆背后的挑战:直播平台的高并发架构设计

兴起及现状 日常生活用手机来看视频的次数越来越多,时间越来越长,看的内容也是种类越来越多。包括最近从3月份美国开始火起来之后,国内也在火的移动视频社交类。这个也是我们现在在重点切的一个垂类,这个垂类...
  • zz_coder
  • zz_coder
  • 2016年07月01日 17:35
  • 5939

QQ视频直播架构及原理

作者:王宇(腾讯音视频高级架构师) 自我介绍下,毕业以来加入腾讯,一直从事客户端研发,身处互联网公司,踏着互联网的浪潮,一直在浪尖行走,从最早的PC QQ,到移动时代的手Q,再到...
  • wishfly
  • wishfly
  • 2016年11月04日 15:07
  • 6882

聊天室项目(一)框架搭建

聊天室项目框架搭建 经过不短的时间对Linux c 的学习,包括基本的c,系统编程,网络编程,数据库等,准备完成聊天室项目。 基本功能: 1.      采用Client/Server架构 2.   ...
  • ky_heart
  • ky_heart
  • 2016年11月08日 19:45
  • 1153

直播平台的数据库架构演变

摘要:在阿里云数据库技术峰会上,特邀嘉宾映客直播架构师王振涛分享了映客直播作为创业公司从0至日活千万的数据库架构变迁,数据库在直播中的经典应用场景,数据库存储的优化思路,以及如何构建一个高可用数据库架...
  • lihuixin_
  • lihuixin_
  • 2017年09月14日 13:59
  • 623

周梁伟:聊天室架构 如何跳出传统思维来设计?

周梁伟 现任网易云信 IM云服务器端开发负责人,浙江大学计算机学院硕士。2011年加入网易,先后担任网易后台技术中心与网易大数据平台资深开发工程师,负责即时通讯领域的产品开发与应用服务器与大数据领域战...
  • heua5555
  • heua5555
  • 2016年12月15日 20:29
  • 201

一种移动APP统计平台的架构方案(适用于千万级用户的应用)

(本文原创,转载好歹给个注明或者链接。。。。) http://lengyueblog.eicp.net/?p=33 移动互联网现在在飞速的发展,而移动APP也越来越多,当一个应用的用户...
  • lengyue318
  • lengyue318
  • 2012年08月23日 23:12
  • 6857

直播平台整体架构

转载地址:http://www.cnblogs.com/wintersun/p/5860437.html 直播平台整体架构 视频直播链路 视频流转换成不同清晰...
  • l_215851356
  • l_215851356
  • 2017年08月20日 23:36
  • 3047

从一个直播APP开发的流媒体系统的技术架构及应用进行总结

第一篇章 流媒体原理1.1 流媒体概念 1.2 流式传输特点 1.3 流媒体系统构成 1.4 流媒体涉及技术 1.5 流媒体应用 1.6 国内外大型流媒...
  • ccit0519
  • ccit0519
  • 2017年04月10日 13:04
  • 1056

互联网直播平台架构案例一

直播平台整体架构 视频直播链路 视频流转换成不同清晰度 不同的端,不同的网络环境,需要不同码率,以保流畅 播放器的基本实现 SDK在播放器上做层管理 ...
  • GV7lZB0y87u7C
  • GV7lZB0y87u7C
  • 2017年10月23日 00:00
  • 3371

直播平台的高并发架构设计3-方案

这个是我们这边的系统架构图。最下层是依托金山的云服务,因为我们已经有了很好的平台,提供了我们计算资源,提供了存储,提供了很多自建的节点,当然还不够多,我们还是个融合CDN,然后提供了数据分析的能力。我...
  • chengdupanda
  • chengdupanda
  • 2016年07月06日 16:38
  • 1632
内容举报
返回顶部
收藏助手
不良信息举报
您举报文章:千万级用户直播APP——服务端结构设计和思考
举报原因:
原因补充:

(最多只允许输入30个字)