最具影响力的数字化技术在线社区

168大数据

 找回密码
 立即注册

QQ登录

只需一步,快速开始

1 2 3 4 5
开启左侧

亿级短视频应用秒拍的架构实践

[复制链接]
发表于 2017-1-22 10:58:08 | 显示全部楼层 |阅读模式

马上注册,结交更多数据大咖,获取更多知识干货,轻松玩转大数据

您需要 登录 才可以下载或查看,没有帐号?立即注册

x
近几年来,各种短视频应用在国内应用市场火爆登场,微博投资,以优质拍摄体验著称的短视频应用秒怕,更是短视频应用中的佼佼者。本期贾朝藤为我们揭开秒拍亿级短视频架构的神秘面纱,以及秒拍是如何在复杂网络环境下保证优质用户体验的。

秒拍的系统架构
产品的演进、用户量的增长推动了技术的变革,下面是秒拍的技术架构图。
最上面 Web 和 App 是直接面对用户的,还有微博和其他合作方的合作也是在最上面一层。直接面向服务的是业务逻辑的 API,比如一些活动和视频的列表展现和用户的一些列表展现,都是在 API 里面有提供。这些 API 视频和用户分为用户服务和视频服务,现在已经在划分了。用户服务和视频服务他们依赖于很多底层服务,比如说用户关系、计数、搜索、Push、推荐、敏感词过滤、Feed、存储等。
用什么写业务
一开始秒拍是用 Java 加 Mongodb 做的,之后因为 PHP 平台开发效率很高,再加上 Mongodb 写的一些限制,所以我们迁移到了 PHP、Redis、Memcache、Mysql 等典型的后端语言和基础设施。我们的机房部署主要是新浪私有云平台,还有一些业务放在阿里云。
大并发、大数据量下的一些小问题
去年小咖秀突然火起来,秒拍和小咖秀的视频和用户量爆增,暴露出了业务中的一些问题,比如 Web Server 大爆503,体现在业务中大范围不可用,主要是联通机房,503报警频繁。直接原因主要是 PHP 连接时间过长,导致 PHP 超连接数,根本原因是因为 Mysql 业务需求变更,新来的需求加个索引,如果这个表里面没有数据,会与其它表连表查,这样就会导致问题积累,table连接过多,子表查询也太多。还有很多 count(*)计数,count(*)计数本身是非常耗 DB 的 CPU 的,统计频繁会导致 DB 的 CPU 压力过大,返回时间过长。PHP 这边写业务主要是因为它快,它处理完后,快速结束,快速释放资源,它如果堵塞时间过长的话,Server 这边等待连接过多,就会有频繁的503。另外一个问题就是 Mysql 断连。因为 DB 列表肯定需要设置一些 timeout ,防止连接超时时你的 sql 不释放连接,一直卡在 DB 这边。所以如果业务查询压力过大,或者是表连接过长,或是表格的复杂操作,超过 timeout 时间就会导致断连。因为业务中没有兼容,500就会突然增多。解决方案是我们这边 count 查询统一走计数器,计数器迁移出来作为一个基础微服务。同时,我们把数据表结构,重新进行了 review,把不合理的字段重新划分,相应的索引进行划分,还有一些不合理的产品需求也进行了更改,还有就是部分字段进行了冗余存储,因为查询一次写之后它基本上就是不会变更了,然后就进行冗余存储。优化结果是503、500基本上没有了,业务查询 SQL 更简洁,查询效率也很高,开发人员写起来也比较爽。
还有一个问题就是 mysql 这边因为历史数据堆积,历史数据没有进行拆库拆表,单库、单表的容量很大,DDL 操作成本会很大。增减一个表的字段或者加索引的话,很容易影响主从同步,还会会拖慢业务请求。同时 DBA 这边心理压力也比较大,因为新加一个字断,改一个字断,加一个索引,会影响业务,投诉会很多。这样可能会表的修改会拖慢,查询性能也会下降。mysql 这边有些数据是放在 redis 这边,redis 这边主要的问题集中在实例过少,还有就是数据分布不均匀。因为你的业务不能用到实例就去连一下,另外一个业务用的另外一个实例又去连一下,业务它的用量可能分布不均匀,就会导致数据分布不均匀。关键就在于有的业务一个 key 里面存放了大量的数据,然后它如果有一个复杂操作,Redis 这边又不太兼容,就会影响到其它的服务。解决方案也就是比较常见的,就是进行拆库,拆表。然后我们这边也划分了核心业务和非核心业务,根据业务属性,拆分数据库,核心业务与非核心业务互不干扰。Redis 这边也根据业务类型、操作复杂度,划分了 Redis 实例,业务、服务之前互不干扰,离线计算不影响在线业务。
我们还做了其他业务优化,比如说耗时在线逻辑异步离线处理。缓存治理是优化不合理缓存、复用缓存、减少不必要字段查询、降低网络传输延时。还有一个是功能模块服务化,比如说关系服务。请求合并与压缩是正在做的,业务逻辑 API 一层直接提供客户端,但是它的内部可能会分成很多的子模块,传统方式是一个子模块一个子模块,一个子服务一个子服务地去请求,出问题以后重试一次。我们这边做的是获取服务的数据,降低网络延迟。视频上传完之后,在业务层要做处理,比如说消息 fanout,通知后端服务,后续处服务进行异步化。
核心业务上传和播放
秒拍是短视频,每个视频大小基本是两三兆以内,我们是直接用了 HTTP 协议进行播放和上传处理的。上传流程可以简单看一下,如下图。
客户端向业务逻辑服务器申请上传,然后业务逻辑服务器告诉它使用哪个上传点上传,之后它可以选择七牛或者是新浪 S3存储上传分片,传完之后进行合并,七牛云服务器会通知业务服务器,它已经长传完了,之后业务服务器去做视频传完之后状态的更新,然后再到客户端,处理完成。接下来进行转码和截图服务,转码和截图服务很多是依赖第三方的服务,比如七牛、新浪 S3。其实上传工作我们这做了很多优化,比如特效预览、特效处理我们是放在手机端处理,如果放在业务服务器或者是业务服务里面,它会承受很多转码处理的压力,然后客户端资源是闲置的。而且手机端它需要处理完之后预览,用户未必说选择这个特效之后就不用另外一个特效了。再加上手机端的功能现在已经比较强大了,所以视频处理可以先在客户端做好转码压缩之后,再向业务服务器进行上传。
接下来讲播放,播放流程最简化的就是客户端先去请求资源地址,因为是 http协议,它下载了之后,直接播就行。这是最简单的,但是我们一开始不是提供的源文件地址,而是走我们的一个调度服务器,然后调度服务器去请求播放。它的视频有可能被审核删除了,它会去请求我们的这个服务器,然后我们的调度服务器给他验证他视频的状态。
还有一个是我们这边做了一个 GSLB 的播放调度,对用户按地区的播放情况,进行实时分析,然后预算结果放在调度上面,客户端请求的时候会直接拿到播放的最优的 CDN。我们在第三方 CDN 之上也做了一层播放数量统计和分析调度。我们是通过 Nginx Lua,它请求之后,根据它的上网信息然后快速返回给它调度的 CDN。请求完之后,快速给用户想要的,轻量又高效。
上传完成后续处理
视频上传完之后,它在业务接口里面只是改了一下状态,用户可以正常播,然后后续处理是异步来做的。比如说 Feed、审核、Push、封面图处理、还有其他服务。这些消息 fanout 成多份,然后通知其它的服务。
Feed 是基于好友关系的视频列表,Feed业界比较常用的数据更新模式一个是推,一个是拉。推的话就是一个用户上传完视频之后,把我们的视频信息推到每个用户的个人 Feed 列表里面。然后是请求完之后,我去取一下看看我关注的人是不是更新视频了,再对之进行排序展示。我们这边针对大粉丝用户,粉丝Feed其实是采用拉的方式,然后部分用户采用推的方式。推的时候也要基于用户粉丝活跃度进行推送,因为他粉丝有一些事僵尸粉,或者是一些不活跃的,这些就不给他推。
这主要是 Feed 流程,用户发布一个视频,然后它自己增加一条 Feed 记录之后,Feed 服务会根据用户关系更新好友粉丝的 Feed 列表,如果好友想看一下我关注的人发了什么内容,很快的可以看到。
然后是封面图审核和处理。虽然是视频处理尽量往客户端走,但是客户端处理审核截图本来就是不太合理的,一个是传输它需要往服务端传,这个和用户的正常使用其实是没有多大关系的。我们这边审核服务是对视频帧进行抽取的,生成审核截图提供给审核员使用。现在我们也有使用第三方的服务,比如说图谱。所以现在的审核机制就是自有审核 图谱分析 人工审核。还有就是我们秒拍跟其它合作方合作,可能会生成各种不同尺寸的封面图,这也是一个独立的子服务。
核心业务的一些高可用设计
因为上传和播放属于我们的核心业务,如果一个区域或者 APP 不能上传,会影响到整个公司的业务,播放也一样。针对于这些核心业务,我们做了一些措施。上传高可用,主要是我们采用的多云的方式,主要是新浪 S3和七牛,可以多源站备份。假如说七牛或者是新浪出现问题,我们可以在上传这一步,业务服务可以让他选择从哪个节点上传,出现了问题之后我们可以直接切换过去。前段时间新浪 S3出现问题,新浪内网中断,直接就不能用了,直接就进行切换,不影响业务服务。播放高可用。调度这块除了对播放情况收集外,还做了可用性检测。如果这个节点频繁出问题的话,我们可以不给他调度返回相应的 CDN 的地址。然后 CDN 这边如果优先选了一个源,如果一个源不存在的话,或者出问题的话,它会切换到另外一个源进行播放。
其它核心组件
除此之外还有视频不相关的一些核心服务,比如说 Push。IOS 有自建 APNS 通信通道和新浪内部基础服务。安卓主要是它需要和服务方、设备方维持连接,成本关系采用的是新浪基础服务+第三方合作服务,基本可以保证Push保证秒级可达,成本可控。
搜索引擎。搜索我们是基于 ELASTICSEARCH 的分布式搜索引擎,相对于其它搜索引擎来说,处理索引要实时,实时搜索、稳定、可靠、快速扩容、性能保障、提供搜索。搜索服务也是一个独立的服务提供给业务方。
敏感词过滤。我们是基于分词加布隆过滤器的敏感词过滤服务。
海量日志分析和监控
日志的构成主要有:serveraccess log、error log、service log、app log、用户 log 等。
相信大家都有这些痛点:日志量太大,业务出现问题时不能知道各服务的状态,不能快速定位问题,查不出来,问题相关的人都会收到通知一块去查看,查到之后却已经拖了很长时间了;grep/awk 只可以单机运行,大日志搜索难以满足;日志形态不可视。
对此,秒拍当前做了基于ELK实时日志分析系统,业务日志来了之后就可以对它进行分析,可以图表化快速反馈各项服务状态和一些统计信息,出问题了可以很快的感知,同时还有基于ELK的服务监控。


楼主热帖
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

关闭

站长推荐上一条 /1 下一条

关于我们|小黑屋|Archiver|168大数据 ( 京ICP备14035423号|申请友情链接

GMT+8, 2024-3-29 03:28

Powered by BI168大数据社区

© 2012-2014 168大数据

快速回复 返回顶部 返回列表