UDN-企业互联网技术人气社区

板块导航

浏览  : 1950
回复  : 0

[开发框架] 对话架构师:亿级短视频社交美拍架构实战

[复制链接]
爱飞的火车的头像 楼主
  对话架构师:亿级短视频社交美拍架构实战

  编者按:本文由麦俊生向「高可用架构」投稿,介绍在 BOSS 直聘主办的直聘学院「对话架构师」活动上的分享精华。转载请注明来自高可用架构公众号「ArchNotes」。

  麦俊生,美图架构平台深圳技术总监,曾担任新浪微博、奇虎 360 技术专家,从事高性能高可用架构设计开发工作,参与建设微博的 feed 和私信 IM 系统、负责 RPC 框架 motan、cache service、 counter service、公用类库等基础建设,以及奇虎 360 存储服务和基础框架方面的建设。个人擅长性能调优、高可用中间件、分布式存储、IM 等相关领域。

“在美拍的服务化过程中,主要基于 etcd 来实现我们的动态服务发现和配置服务,在 client 层面扩展实现了包含负载均衡、心跳、节点健康状态探测、etcd 节点挂掉的灾备等基础功能,同时会通过一些 metrics 埋点,以便跟踪内部的状态,用统一的 trace_id 来跟踪服务的链路调用情况。” —— 麦俊生

  一、短视频市场的发展

  近几年来,短视频应用在国内应用市场引爆,美图公司推出了美拍,相关的产品还有 GIF 快手、秒拍、微视、逗拍、玩拍等,一系列短视频产品的出现也丰富了短视频应用市场。

  短视频的相继爆发,与几个因素有关:

  1、带宽,随着中国基础网络环境的发展,越来越多的2G移动网民开始转向使用 3G/4G 网络,从而体验到更好的上传下载带宽和更稳定的网络, 目前 3G/4G 的移动用户比例大概占比 85% 以上;同时随着资费的进一步降低,月户平均流量也达到了 360M,甚至不少部分是 GB 甚至几十 GB 的级别的流量,所以就一个普通的 10s 视频而言大概不到 1~2M 甚至几百 K,带宽流量的提升无疑会逐步降低用户使用的门槛;此外,家用带宽也随之增加,目前 10M 甚至 100M `已经成为家用带宽的主流,从而为短视频的发展提供了必要条件。

  2、手机硬件配置的极大改进,随着像素的增加、手机硬件配置 CPU、GPU、内存等的升级,能够让手机更快的来处理和优化视频效果,从而能够给手机视频的处理带来更多的创意空间。

  3、传统的文字和图片的表达能力不够丰富,所以无法满足网民的需求,而短视频带来了足够大的表现空间。

  4、产品本身,提供了各种方式来降低用户视频的制作门槛,比如美拍提供了 MV 特效等,来提升了制作视频的趣味性的同时,降低使用的门槛。同时产品的多样化,也满足了各种用户的差异化需求,激发用户自传播。

  二、美拍的发展

  美拍在 2014.05 月发布,上线仅 1 天,即登入 App Store 免费总榜第一,当月下载量排名第一。在发布 9 个月的时候,用户就突破 1 个亿。目前每天美拍视频日播放量在 2.7 亿以上,日视频播放时长达到 183 万小时。

  面临这种用户量爆发的增长,美拍也遇到了很多应用起步之初那些年所遇到的甜蜜和苦涩的回忆,经过 1 年多的架构的演进,美拍也积累了一定的经验,形成了一套高可用高可扩展的架构实践。虽无法做到很华丽,却会随着架构的不断的演进而不断的完善。

  相比于普通的文本社交类 APP,做这么一个短视频产品在技术架构层面,会面临哪些问题呢?

  和通用的文本社交类产品一样,美拍有首页热门、好友动态(feed 流)、评论服务、私信服务等基础功能;所以在用户爆发增长后,同样会面临应用层、数据库、缓存、接入层等方面的挑战,那么如何做到低延迟、高可用呢。同时因为是短视频本身,也会面临一些特定的领域性相关的问题。

  三、短视频所面临的架构问题

  短视频相比于文本数据而言,有着一些差异:

  1、数据大小的差异

  比如一条美拍,经过视频压缩和清晰度的权衡,10s 的视频大小 1MB 多,而一条 5 分钟视频的美拍甚至要达到几十 M,相比与几十字节或者几百字节的文本要大得多。因为数据量要大得多,所以也会面临一些问题:如何上传、如何存放、以及如何播放的问题。

  关于上传,要在手机上传这么一个视频,特别是弱网环境要上传这么一个文件,上传的成功率会比较低,晚高峰的时候,省际网络的拥塞情况下,要更为明显得多。所以针对上传,需要基于 CDN 走动态加速来优化网络链路(通过基调实测过对于提升稳定性和速度有一定帮助),同时对于比较大的视频需要做好分片上传,减少失败重传的成本和失败概率等来提升可用性。同时不同 CDN 厂商的链路状况在不同的运营商不同地区可能表现不一,所以也需要结合基调测试,选择一些比较适合自己的 CDN 厂商链路。

  同时因为数据相对比较大,当数据量达到一定规模,存储容量会面临一些挑战,目前美拍的视频容量级别也达到 PB 级别的规模,所以要求存储本身能够具备比较强的线性扩展能力,并且有足够的资源冗余,而传统的 MySQL 等数据库比较难来支持这个场景,所以往往需要借助于专用的分布式对象存储。可以通过自建的服务或者云存储服务来解决。得益于近几年云存储的发展,目前美拍主要还是使用云存储服务来解决。自身的分布式对象存储主要用于解决一些内部场景,比如对于数据隐私性和安全性要求比较高的场景。

  播放方面,因为文件比较大,也容易受到网络的影响,所以为了规避卡顿,一些细节也需要处理。比如对于 60s,300s 的视频,需要考虑到文件比较大,同时有拖动的需求,所以一般使用 http range 的方式,或者基于 HLS 的点播播放方式,基于前者比较简单粗暴,不过基于播放器的机制,也能够满足需求,也能实现点播拖动。而直接基于 HLS 的方式会更友好,特别是更长的一些视频,比如 5 分钟甚至更大的视频,不过这种需要单独的转码支持。之前美拍主要是短视频为主,所以更多使用 http range 的方式。而后续随着 5 分钟或者更大视频的场景,也在逐步做一些尝试。同时对于播放而言,在弱网环境下,可能也会面临一些问题,比如播放时卡顿的问题,这种一般通过网络链路优化;或者通过多码率的自适应优化,比如多路转码,然后根据特定算法模型量化用户网络情况进行选码率,网络差的用低码率的方式。

  2、数据的格式标准差异

  相比于文本数据,短视频本身是二进制数据,有比较固定的编码标准,比如 H.264、H.265 等,有着比较固定和通用的一些格式标准。

  3、数据的处理需求

  视频本身能够承载的信息比较多,所以会面临有大量的数据处理需求,比如水印、帧缩略图、转码等。而视频处理的操作是非常慢的,会带来巨大的资源开销。

  美拍对于视频的处理,主要分为两块:

  客户端处理,视频处理尽量往客户端靠,利用现有强大的手机处理性能来减少服务器压力, 同时这也会面临一些低端机型的处理效率问题,不过特别低端的机型用于上传美拍本身比较少数,所以问题不算明显。客户端主要是对于视频的效果叠加、人脸识别和各种美颜美化算法的处理,我们这边客户端有实验室团队,在专门做这种效果算法的优化工作。同时客户端处理还会增加一些必要的转码和水印的视频处理。目前客户端的视频编解码方式,会有软编码和硬编码的方式,软编码主要是兼容性比较好,编码效果好些,不过缺点就是能耗高且慢些。而硬编码借助于显卡等,能够得到比较低的能耗并且更快,不过兼容和效果要差一些,特别是对于一些低配的机型。所以目前往往采用结合的方式。

  服务端的处理,主要是进行视频的一些审核转码工作,也有一些抽帧生成截图的工作等,目前使用 ffmpeg 进行一些处理。服务端本身需要考虑的一些点,就是因为资源消耗比较高,所以需要机器数会更多,所以在服务端做的视频处理操作,会尽量控制在一个合理的范围。同时因为美拍这种场景,也会遇到这些热点事件的突变峰值,所以转码服务集群本身需要具备可弹性伸缩和异步化消峰机制,以便来适应这种突增请求的场景。

  四、为支持亿级用户,美拍架构所做的一些改进

  随着用户和访问量的快速增长,美拍遇到不少的挑战
  • 性能的挑战
  • 可用性的挑战
  • 突发热点的挑战
  • 业务频繁迭代的挑战


  在频繁的业务迭代的情况下,如何能够在海量请求下保证足够高的可用性,同时以一个比较好的用户体验和比较低的成本的方式来提供服务成为我们努力的方向。

相关帖子

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

本版积分规则

关于我们
联系我们
  • 电话:010-86393388
  • 邮件:udn@yonyou.com
  • 地址:北京市海淀区北清路68号
移动客户端下载
关注我们
  • 微信公众号:yonyouudn
  • 扫描右侧二维码关注我们
  • 专注企业互联网的技术社区
版权所有:用友网络科技股份有限公司82041 京ICP备05007539号-11 京公网网备安1101080209224 Powered by Discuz!
快速回复 返回列表 返回顶部