编者按
春节近在咫尺，回首即将过去的2015年，技术让大众的娱乐生活发生了翻天覆地的变化，其中，短视频应用领域上升迅速，成为大众娱乐的首选。在2015年度短视频App排名中，七牛客户美拍、秒拍、小咖秀、小影等表现突出，均跻身前十，成为大家最喜爱的应用。但产品的背后，是不少程序员的不辞辛劳与扎实的技术。值此新春之际，小七特为大家奉上实实在在的「牛小七送年（gan）货之短视频」系列分享，让您从短视频产品（以美拍为例）的技术架构开始，了解短视频技术的前世今生，后续也将对短视频产品打造的技术痛点进行分析并给出相应技术解决方案，敬请关注。
“在美拍的服务化过程中，主要基于 etcd 来实现我们的动态服务发现和配置服务，在 client 层面扩展实现了包含负载均衡、心跳、节点健康状态探测、etcd 节点挂掉的灾备等基础功能，同时会通过一些 metrics 埋点，以便跟踪内部的状态，用统一的 trace_id 来跟踪服务的链路调用情况。” ——美图架构平台深圳技术总监 麦俊生
在本文中，他将详细地为大家分享亿级短视频社交产品美拍的架构实战经验。
短视频市场的发展
近几年来，短视频应用在国内应用市场引爆，美图公司推出了美拍，相关的产品还有 GIF 快手、秒拍、微视、逗拍、玩拍等，一系列短视频产品的出现也丰富了短视频应用市场。
短视频的相继爆发，与几个因素有关：
带宽，随着中国基础网络环境的发展，越来越多的2G移动网民开始转向使用 3G/4G 网络，从而体验到更好的上传下载带宽和更稳定的网络, 目前 3G/4G 的移动用户比例大概占比 85% 以上；同时随着资费的进一步降低，月户平均流量也达到了 360M，存在不少是 GB 甚至几十 GB 级别流量的情况。一个普通的 10s 视频不到 1~2M ，甚至几百 K，带宽流量的提升无疑会逐步降低用户使用的门槛；此外，家用带宽也随之增加，目前 10M 甚至 100M 已经成为家用带宽的主流，从而为短视频的发展提供了必要条件。
手机硬件配置的极大改进，随着像素的增加、手机硬件配置 CPU、GPU、内存等的升级，让手机能够更快地处理和优化视频效果，从而给手机视频的处理带来更多的创意空间。
传统文字和图片的表达能力不够丰富，无法满足网民的需求，而短视频带来了足够大的表现空间。
视频产品本身，提供了各种方式降低用户视频的制作门槛，比如美拍提供了 MV 特效等。这些方式在提升制作视频趣味性的同时，也降低使用的门槛。而产品的多样化则满足了各种用户差异化的需求，激发用户的自传播。
美拍的发展
美拍于 2014.05 月发布，上线仅 1 天便登入 AppStore 免费总榜第一，当月下载量排名第一。在发布 9 个月的时候，用户突破 1 亿。目前美拍视频日播放量在 2.7 亿以上，日视频播放时长达到 183 万小时。
面临用户量爆发式的增长，美拍跟很多应用一样，有着甜蜜和苦涩的回忆。经过 1 年多的架构演进，美拍也积累了一定的经验，形成了一套高可用高可扩展的架构实践。虽无法做到很华丽，却会随着架构的不断演进而不断的完善。
相比于普通的文本社交类 App，一个短视频产品在技术架构层面，会面临哪些问题呢？
和通用的文本社交类产品一样，美拍有首页热门、好友动态（Feed 流）、评论服务、私信服务等基础功能。所以，在用户爆发增长后，美拍同样会面临应用层、数据库、缓存、接入层等方面的挑战。此外，短视频本身也会面临一些特定的领域性相关的问题。那么，如何做到低延迟、高可用呢？
短视频所面临的架构问题
短视频相比于文本数据而言，有着一些差异：
数据大小的差异
比如一条美拍，经过视频压缩和清晰度的权衡，10s的视频大小 1MB 多，而一条 5 分钟视频的美拍甚至要达到几十 M，相比与几十字节或者几百字节的文本要大得多。因为数据量要大得多，所以也会面临一些问题：如何上传、如何存放、以及如何播放的问题。
关于上传，要在手机上传这么一个视频，特别是弱网环境要上传这么一个文件，上传的成功率会比较低，晚高峰的时候，省际网络的拥塞情况下，要更为明显得多。所以针对上传，需要基于 CDN 走动态加速来优化网络链路（通过基调实测过对于提升稳定性和速度有一定帮助），同时对于比较大的视频需要做好分片上传，减少失败重传的成本和失败概率等来提升可用性。同时不同 CDN 厂商的链路状况在不同的运营商不同地区可能表现不一，所以也需要结合基调测试，选择一些比较适合自己的 CDN 厂商链路。
同时因为数据相对比较大，当数据量达到一定规模，存储容量会面临一些挑战，目前美拍的视频容量级别也达到 PB 级别的规模，所以要求存储本身能够具备比较强的线性扩展能力，并且有足够的资源冗余。而传统的 MySQL 等数据库比较难以支持这个场景，所以往往需要借助于专用的分布式对象存储。可以通过自建的服务或者云存储服务来解决。得益于近几年云存储的发展，目前美拍主要还是使用云存储服务来解决，并且选择的是国内比较靠谱的七牛。美拍自身的分布式对象存储主要用于解决一些内部场景，比如对于数据隐私性和安全性要求比较高的场景。
播放方面，因为文件比较大，也容易受到网络的影响，所以为了规避卡顿，一些细节也需要处理。比如对于 60s，300s 的视频，需要考虑到文件比较大，同时有拖动的需求，所以一般使用 http range 的方式，或者基于 HLS 的点播播放方式，基于前者比较简单粗暴，不过基于播放器的机制，也能够满足需求，也能实现点播拖动。而直接基于 HLS 的方式会更友好，特别是更长的一些视频，比如 5 分钟甚至更大的视频，不过这种需要单独的转码支持。之前美拍主要是短视频为主，所以更多使用 http range 的方式。而后续随着 5 分钟或者更大视频的场景，也在逐步做一些尝试。对于播放而言，在弱网环境下，可能也会面临一些问题，比如播放时卡顿的问题，这种一般通过网络链路优化；或者通过多码率的自适应优化，比如多路转码，然后根据特定算法模型量化用户网络情况进行选码率，网络差的用低码率的方式。
数据的格式标准差异
相比于文本数据，短视频本身是二进制数据，有比较固定的编码标准，比如 H.264、H.265 等，有着比较固定和通用的一些格式标准。
数据的处理需求
视频本身能够承载的信息比较多，所以会面临有大量的数据处理需求，比如水印、帧缩略图、转码等，当然，像七牛这样的云服务商，他们提供此类API可以直接使用。而视频处理的操作是非常慢的，会带来巨大的资源开销。
美拍对于视频的处理，主要分为两块：
客户端处理，视频处理尽量往客户端靠，利用现有强大的手机处理性能来减少服务器压力，同时这也会面临一些低端机型的处理效率问题，不过特别低端的机型用于上传美拍本身比较少数，所以问题不算明显。客户端主要是对于视频的效果叠加、人脸识别和各种美颜美化算法的处理，我们这边客户端有实验室团队，在专门做这种效果算法的优化工作。同时客户端处理还会增加一些必要的转码和水印的视频处理。目前客户端的视频编解码方式，会有软编码和硬编码的方式，软编码主要是兼容性比较好，编码效果好些，不过缺点就是能耗高且慢些。而硬编码借助于显卡等，能够得到比较低的能耗并且更快，不过兼容和效果要差一些，特别是对于一些低配的机型。所以目前往往采用结合的方式。
服务端的处理，主要是进行视频的一些审核转码工作，也有一些抽帧生成截图的工作等，目前使用 ffmpeg 进行一些处理。服务端本身需要考虑的一些点，就是因为资源消耗比较高，所以需要机器数会更多，所以在服务端做的视频处理操作，会尽量控制在一个合理的范围。同时因为美拍这种场景，也会遇到这些热点事件的突变峰值，所以转码服务集群本身需要具备可弹性伸缩和异步化消峰机制，以便来适应这种突增请求的场景。
为支持亿级用户，美拍架构所做的一些改进
随着用户和访问量的快速增长，美拍遇到不少的挑战
性能的挑战
可用性的挑战
突发热点的挑战
业务频繁迭代的挑战
在频繁的业务迭代的情况下，如何能够在海量请求下保证足够高的可用性，同时以一个比较好的用户体验和比较低的成本来提供服务成为我们努力的方向。以下是目前美拍整体架构全貌。
这个架构目前正在不断地演进中，除了一些基础服务组件的建设外，我们还着重在服务治理做一些相关工作，以保证整体服务的可用和稳定。
分而治之、化繁为简
规划整体架构，明确服务模块的单一职责，尽量保持足够内聚，服务模块之间做到解耦，这样就能够针对单一模块进行更精细化的优化工作，同时能够用适合的技术来解决适合的场景问题。
服务之间的交互和通讯，主要用两种方式：
基于 HTTP 的方式
基于 configservice + RPC 的方式
前者使用的方式比较简单，主要在跨团队、跨语言（比如 PHP 和 Golang 之类的）会使用，主要会在七层 nginx 层做一些工作，如负载均衡、节点探测、并发保护等。
第二种方式主要用于内部系统之间的一些交互。目前美拍主要基于 etcd 实现动态服务发现和配置服务，在 client 层面扩展实现了包含负载均衡、心跳、节点健康状态探测、etcd 节点挂掉的灾备等基础功能，同时会通过一些metrics埋点，以便跟踪内部的状态，用统一的 trace_id 来跟踪服务的链路调用情况。
开放扩展
主要针对下面几个点：
代码功能的可扩展性
交互协议的扩展性
数据存储格式的可扩展性
应用的可扩展性
资源的可扩展性
交互协议既针对交互接口，也针对 App 客户端和服务端的交互协议。特点是 app 客户端和服务端的交互协议，因为App 的升级较之服务端升级的时间久得多，比如你发布了一个客户端版本 V0.1，如果用户后面一直不升级，这个时间可能是几个月、半年甚至一年，那么就会引入一些兼容问题，所以在协议层面设计的关键点需要考虑这种情况的存在，需要保证协议能够向前兼容，预留好扩展点。
而关于数据存储格式的可扩展性，美拍第一个版本每个属性在数据库中为一个字段，并且为了保持一定的扩展性也多加了几个扩展字段。在发展过程中演化为所有属性字段序列化为 protocol buffer 数据的方式，这样能更好满足快速发展的业务需求。但是大家往往也更多关注在服务端，其实有时候比较坑的是在客户端。之前美拍就在客户端踩过坑，客户端上有个 id 字段的数据类型使用 int32，因为客户端基本很难做强升，一个这样小的事情最终需要很长时间来消化解决，并且为此还需要做一些兼容工作。所以针对这类事情，建议大家一开始多留意，尽量少为将来埋坑。
分级隔离
目前美拍主要通过以下几个维度进行一些隔离：
核心和非核心的隔离
单一集群的内部隔离
不同集群的外部物理资源隔离
不同集群的外部依赖资源的隔离
美拍在发展早期，跟多数发展早期的系统一样，也是多数接口部署在同一个集群中，包括也共用了一些资源（比如Memcached ），这样的好处是早期部署上足够的简单。在业务快速发展的过程中，业务复杂度也在逐步提升，接口调用量急剧增加，逐步就暴露出一些问题。美拍的发展过程也是实际的去验证了前面提到的分级隔离机制。
在发展早期，曾经有个调用量不小的非核心业务，在对存储数据结构做了调整后的上线过程中出现性能问题，导致整个集群服务都受到一定的影响。虽然通过降级策略和运维配套设施快速的解决了问题，但是也引发了我们的进一步思考。在架构上美拍会尽量保证在开发效率、系统架构、部署和运维成本等方面达到一定的平衡，以避免过度设计或者架构支撑不了业务。这到了需要做一些事情的时候，我们把核心业务和非核心业务在七层和应用层做了部署上的隔离。
做完上面的核心业务和非核心业务拆分之后，接口互相之间的依赖影响降低很多。但是还没有解决核心业务或者非核心业务内部接口之间的依赖影响问题。所以接下来也更进一步，针对部分场景也做了内部隔离，通过限定每个接口最多只能使用的固定处理线程数方式，来避免因为单个集群内某个接口的问题导致整个集群出问题的情况发生。
以上主要是在接口层面做隔离，而在依赖的资源及其外部服务方面，如果没有相应的隔离机制，也会有互相依赖影响的问题，比较典型的有 memcached slab calcification 问题等。所以我们也在 Memcached、MySQL 等核心资源层面做了拆分。
综合来看，分级隔离本质上是在解决服务之间依赖影响问题。
资源冗余
短视频是一个比较耗带宽的服务，因此在通用的应用自身资源冗余的情况下，还需要考虑到服务所依赖的外部资源，比如 CDN 和云存储服务本身的情况。对于 CDN 层面，可能还要考虑不同厂商在不同区域，不同运营商下的资源冗余情况。而依赖的云服务是一个可无限扩展的服务，通过扩展就能够满足性能需求，随着云技术的成熟，在资源隔离方面，云存储厂商做的也不错。
容灾
美拍的容灾主要分为自身服务容灾、CDN容灾、云存储容灾等。
自身服务容灾主要包含一些典型的容灾场景，比如 Cache 容灾，通过多级 Cache、Cache 的分片Hash 的方式、以及本地Cache 的方式来解决。目前美拍这边的容灾也借鉴了微博的多级Cache 机制，针对核心的 Cache 资源会有主备节点，避免单一节点挂掉后，穿透会压垮后端 DB，同时对于请求量特别大的场景，比如对于某个热点资源访问量很大的情况下，也会在之前增加一层 L1 的 LRU Cache 来规避和缓解这一问题。
CDN 容灾主要通过接入多家供应商进行互备，然后通过一些基调检测不同服务厂商的链路和服务状态，当发现服务有问题的时候，通过 DNS 进行区域的切换。但不同 CDN 厂商的服务表现不对等，所以在选型 CDN 厂商时，需要侧重关注可用性、节点布点和链路状况、回源量、资源冗余量、晚高峰的链路状况、以及对于多媒体是否有单独优化等等来评估靠谱性。
云存储容灾，目前美拍主要使用两家互备的方式，因为国内的网络链路状况容易导致个别上传服务失败，此外，云服务厂商服务挂掉的情况下美拍需要保证自己的服务可用。因此，目前的做法是上传优先走主的云服务，如果上传失败的话就启用备的云服务。服务端层面可以控制整体降级的方式，直接从主云服务直接降级读写备云服务。基于每天的统计来看，通过这个方式至少提升0.1% 以上的上传的可用性。在某些极端情况下，可能达到 1% 的可用性，当然这一块通过网络链路优化可能使得可用性情况没有数据中那么差。不过它的主要作用是在当某个云服务厂商节点服务出现短暂不可用或者长时间不可用的时候，我们也不会受太大影响。
后续的一些发展
随着短视频不断地发展，以及实时直播的崛起，带宽的压力会越来越大，所以能够结合着 P2P + CDN 的方式来缓解服务端的带宽压力，但 P2P 主要面临着防火墙的问题、以及节点网络质量的影响，同时也依赖与视频播放的热度，这种对于效果都会有一些影响，同时为了更好的播放流畅度，单一的 P2P 无法满足需求，需要基于 P2P 和 CDN 的辅助进行。
带宽的另外一个节省之道，就是通过更好的编码标准来进行优化，比如 H.265 的编码标准，通过这个能够节省一半的流量。不过目前 H.265 在硬编支持不是很好，只有个别手机机型支持。而软编码的方式相比于H.264，编解码速度要慢几倍，这种能耗消耗比较高，处理也比较慢，而在往 H.265 演化的过程中，解码的普及程度也将会比编码来得更早。因为在解码算法层面，现有开源的方案还有很大的优化空间，以现有的手机硬件配置，是存在可以通过算法优化达到可以支撑 H.265 的空间。所以随着解码算法的不断优化和硬件的不断升级，解码普及的时间点也应该会比大家预期的时间来得更早，届时也将会有更大比例的端能支持 H.265 的解码，对于 H.265 的普及奠定了很好的基础。
H.265 的普及理想情况是需要很大比例的端上设备在编码和解码层面都有支持，在解码更早普及的情况下，那么其实是有一种中间过渡方式：上传端上传 H.264 数据，服务端转为 H.265，播放端根据自身机器状况选择使用 H.264 或者 H.265 数据。这样的方案需要服务端需要额外做一次转码，并且存储成本也会提升。在有更大比例的端上支持 H.265 后，这样虽然有额外的成本开销，但是相比使用 H.265 带来的带宽成本的节省可能就越来越可以忽略掉。并且也可以根据访问热度情况做控制，取得两者更好的平衡。
另外一个方向，目前美拍会越多越多的把一些客户端的图片视频美化算法云端化，以服务的形式暴露给内部其他服务使用，以便能够支撑更多围绕“美”体系建设的产品生态链。这主要会面临的架构难点，就是资源消耗高。而这个的解决会依赖与两种方式，一种通过硬件 GPU、协处理器、CPU SIMD指令等来优化性能，同时还需要解决架构的视频处理集群的自动弹性调度的问题，同时对于一些场景，比如类似与 H5 的推广页面，会逐步通过结合公有云调度的方式来解决。
美拍从发布至今，已收获全球1.7亿用户，然而，在美拍快速成长的过程中，七牛作为其服务支撑者起到了不容忽视的作用。从早期开始，美拍便开始使用七牛短视频社交解决方案。然而，云服务究竟是如何解决短视频社交场景相关技术问题的呢？请看今日第二条微信内容《拜年干货盘点之短视频｜如何用云服务解决短视频社交产品锥心之痛》。
本文转载自高可用架构架构微信公众号「ArchNotes」。
麦俊生，美图架构平台深圳技术总监，曾担任新浪微博、奇虎 360 技术专家，从事高性能高可用架构设计开发工作，参与建设微博的 feed 和私信 IM 系统、负责 RPC 框架 motan、cache service、 counter service、公用类库等基础建设，以及奇虎 360 存储服务和基础框架方面的建设。个人擅长性能调优、高可用中间件、分布式存储、IM 等相关领域。