[架构百家]短视频社交APP-美拍架构解读
2016-02-16 本文已影响1090人
skywalker
架构永远是为业务服务,良好的架构易于快速开发迭代试错,利于服务的快速扩展部署。这也是互联网架构和传统IT架构的不同。我希望通过一些公开的产品架构文章和抓包工具总结出互联网上典型的架构场景对应的技术方案。平时多想想如果我做这个产品后端会怎么设计,对比学习就会不断提高。
本篇总结分析下“美拍”APP的后端架构设计
- 背景
- 文字和图片不能满足社交需求,视频和直播类的需求
- 带宽提升和3G/4G不断普及
- 手机硬件不断升级
- 根据官网,估值20亿美金,业务的独特性来自于覆盖数亿用户的社区
- 业务需求
- 手机端录像,特效滤镜,如:樱花,百老汇等等
- 视频上传,cdn服务,内容较大,成功率要高
- 标签,评论,好友系统,分享插件等
-
直播业务
需求对应架构模块全景图
-
业务对应的架构
美拍后端架构全景图
-
视频数据的上传和下载
Paste_Image.png
使用了七牛的云存储服务(使用其他厂商云服务作为备份),上传使用分片来减少延迟,七牛上传API说明
文件的大小如下图所示:
视频数据42秒12.93MB
视频的下载播放使用http range 的方式实现 -
视频的手机端处理
如水印、帧缩略图、转码(H264 MP4)、视频的效果叠加、人脸识别和各种美颜美化算法的处理等需求,尽量使用手机端资源完成处理以降低服务器集群的成本 -
视频的服务器端处理
针对播放端不同硬件配置和网络进行转码,使用开源ffmpeg实现 -
视频的编码
手机端使用H264编码后上传,服务端同时支持H264和H265根据手机端不同的配置和网络情况进行适配 -
后端服务相互调用的实现
基于http的微服务:优点:支持多种语言并行开发
基于tcp的服务:优点:性能高,基于grpc实现(对应的还有:thrift和百度的pbrpc)。负载均衡的策略写在了调用端 -
直播业务的实现
根据web端数据分析,使用基于flash的技术实现,主要瓶颈会出现在带宽的费用,需要使用p2p和cdn的技术优化(如:webrtc)。具体实现细节不详,但是可以参考这个【知乎flash直播技术选型】 -
总体分析
- 业务的难点
多种多样手机端视频读取,处理以及播放
服务端带宽,存储,和低延迟直播的实现
- 业务的难点