摘要：本文系美圖架構(gòu)師麥俊生，在直聘主辦的直聘學(xué)院對話架構(gòu)師活動上的分享整理，介紹短視頻社交美拍架構(gòu)實(shí)踐的總結(jié)。目前每天美拍視頻日播放量在億以上，日視頻播放時長達(dá)到萬小時。

本文系美圖架構(gòu)師麥俊生，在Boss直聘主辦的直聘學(xué)院「對話架構(gòu)師」活動上的分享整理，介紹短視頻社交“美拍”架構(gòu)實(shí)踐的總結(jié)。

麥俊生，美圖架構(gòu)平臺深圳技術(shù)總監(jiān)，曾擔(dān)任新浪微博、奇虎360技術(shù)專家，從事高性能高可用架構(gòu)設(shè)計(jì)開發(fā)工作，參與建設(shè)微博的feed和私信im系統(tǒng)、負(fù)責(zé)rpc框架motan、cache service、 counter service、公用類庫等基礎(chǔ)建設(shè)，以及奇虎360存儲服務(wù)和基礎(chǔ)框架方面的建設(shè)。個人擅長性能調(diào)優(yōu)、高可用中間件、分布式存儲、IM等相關(guān)領(lǐng)域。

以下是分享實(shí)錄整理：《億級短視頻社交美拍架構(gòu)實(shí)踐》

一、短視頻市場的發(fā)展
近幾年來，短視頻應(yīng)用在國內(nèi)應(yīng)用市場引爆，美圖公司推出了美拍，GIF快手公司也推出了短視頻產(chǎn)品，以及微博投資的秒拍，還有微視、逗拍、玩拍等一系列短視頻產(chǎn)品也豐富了短視頻應(yīng)用市場。

短視頻的相繼爆發(fā)，與幾個因素有關(guān)：

1. 帶寬，隨著中國基礎(chǔ)網(wǎng)絡(luò)環(huán)境的發(fā)展，越來越多的2G移動網(wǎng)民開始轉(zhuǎn)向3G/4G網(wǎng)絡(luò)，從而提供更好的上傳下載帶寬和更穩(wěn)定的體驗(yàn)，目前3G/4G的移動用戶比例大概占比85%以上；同時隨著資費(fèi)的進(jìn)一步降低，月戶平均流量也達(dá)到了360M，甚至不少部分是GB甚至幾十GB的級別的流量，所以就一個普通的10s視頻而言大概不到1~2M甚至幾百K，帶寬流量的提升無疑會逐步降低用戶使用的門檻；此外，家用帶寬也隨之增加，目前10M甚至100M已經(jīng)成為家用帶寬的主流，從而為短視頻的發(fā)展提供了必要條件。

2.手機(jī)硬件配置的極大改進(jìn)，隨著像素的增加、手機(jī)硬件配置CPU、GPU、內(nèi)存等的升級，能夠讓手機(jī)更快的來處理和優(yōu)化視頻效果，從而能夠給手機(jī)視頻的處理帶來更多的創(chuàng)意空間。

3.傳統(tǒng)的文字和圖片的表達(dá)能力不夠豐富，所以無法滿足網(wǎng)民的需求，而短視頻帶來了足夠大的表現(xiàn)空間。

4.產(chǎn)品本身，提供了各種方式來降低用戶視頻的制作門檻，比如美拍提供了MV特效等，來提升了制作視頻的趣味性的同時，降低使用的門檻。同時產(chǎn)品的多樣化，也滿足了各種用戶的差異化需求，激發(fā)用戶自傳播。

二、美拍的發(fā)展
美拍在2014.05月發(fā)布，上線僅1天，即登入App Store免費(fèi)總榜第一，當(dāng)月下載量排名第一。在發(fā)布9個月的時候，用戶就突破1個億。目前每天美拍視頻日播放量在2.7億以上，日視頻播放時長達(dá)到183萬小時。

面臨這種用戶量爆發(fā)的增長，美拍也遇到了很多應(yīng)用起步之初那些年所遇到的甜蜜和苦澀的回憶，經(jīng)過1年多的架構(gòu)的演進(jìn)，美拍也積累了一定的經(jīng)驗(yàn)，形成了一套高可用高的架構(gòu)實(shí)踐。雖無法做到很華麗，卻會隨著架構(gòu)的不斷的演進(jìn)而不斷的完善。

相比與普通的文本社交類APP，做這么一個短視頻產(chǎn)品在技術(shù)架構(gòu)層面，會面臨哪些問題呢？

和通用的文本社交類產(chǎn)品一樣，美拍有首頁熱門、好友動態(tài)(feed流)、評論服務(wù)、私信服務(wù)等基礎(chǔ)功能；所以在用戶爆發(fā)增長后，同樣會面臨應(yīng)用層、數(shù)據(jù)庫、緩存、接入層等方面的挑戰(zhàn)，那么如何做到低延遲、高可用呢。同時因?yàn)槭嵌桃曨l本身，也會面臨一些特定的領(lǐng)域性相關(guān)的問題。

三、短視頻所面臨的架構(gòu)問題

短視頻相比于文本數(shù)據(jù)而言，有著一些差異：

1. 數(shù)據(jù)大小的差異。

比如一條美拍，經(jīng)過視頻壓縮和清晰度的權(quán)衡，10s的視頻大小1MB多，而一條5分鐘視頻的美拍甚至要達(dá)到幾十M，相比與幾十字節(jié)或者幾百字節(jié)的文本要大得多。因?yàn)閿?shù)據(jù)量要大得多，所以也會面臨一些問題：如何上傳、如何存放、以及如何播放的問題。

關(guān)于上傳，要在手機(jī)上傳這么一個視頻，特別是弱網(wǎng)環(huán)境要上傳這么一個文件，上傳的成功率會比較低，晚高峰的時候，省際網(wǎng)絡(luò)的擁塞情況下，要更為明顯得多。所以針對上傳，需要基于CDN走動態(tài)加速來優(yōu)化網(wǎng)絡(luò)鏈路（通過基調(diào)實(shí)測過對于提升穩(wěn)定性和速度有一定幫助），同時對于比較大的視頻需要做好分片上傳，減少失敗重傳的成本和失敗概率等來提升可用性。同時不同CDN廠商的鏈路狀況在不同的運(yùn)營商不同地區(qū)可能表現(xiàn)不一，所以也需要結(jié)合基調(diào)測試，選擇一些比較適合自己的CDN廠商鏈路。

同時因?yàn)閿?shù)據(jù)相對比較大，當(dāng)數(shù)據(jù)量達(dá)到一定規(guī)模，存儲容量會面臨一些挑戰(zhàn)，目前美拍的視頻容量級別也達(dá)到PB級別的規(guī)模，所以要求存儲本身能夠具備比較強(qiáng)的線性擴(kuò)展能力，并且有足夠的資源冗余，而傳統(tǒng)的Mysql等數(shù)據(jù)庫比較難來支持這個場景，所以往往借助于專用的分布式對象存儲，通過自建的服務(wù)或者云存儲服務(wù)能夠解決，得益于近幾年云存儲的發(fā)展，目前美拍主要還是使用云存儲服務(wù)來解決。自身的分布式對象存儲主要用于解決一些內(nèi)部場景，比如對于數(shù)據(jù)隱私性和安全性要求比較高的場景。

關(guān)于對于播放，因?yàn)槲募容^大，也容易受到網(wǎng)絡(luò)的影響，所以為了規(guī)避卡頓，一些細(xì)節(jié)也需要處理。比如對于60s，300s的視頻，需要考慮到文件比較大，同時有拖動的需求，所以一般使用http range的方式，或者基于HLS的點(diǎn)播播放方式，基于前者比較簡單粗暴，不過基于播放器的機(jī)制，也能夠滿足需求，也能實(shí)現(xiàn)點(diǎn)播拖動。而直接基于HLS的方式會更友好，特別是更長的一些視頻，比如5分鐘甚至更大的視頻，不過這種需要多帶帶的轉(zhuǎn)碼支持。之前美拍主要是短視頻為主，所以更多使用http range的方式。而后續(xù)隨著5分鐘或者更大視頻的場景，也在逐步做一些嘗試。同時對于播放而言，在弱化環(huán)境下，可能也會面臨一些問題，比如播放時長卡頓的問題，這種一般通過網(wǎng)絡(luò)鏈路優(yōu)化；或者通過多碼率的自適應(yīng)優(yōu)化，比如多路轉(zhuǎn)碼，然后根據(jù)特定算法模型量化用戶網(wǎng)絡(luò)情況進(jìn)行選碼率，網(wǎng)絡(luò)差的用低碼率的方式。

2. 數(shù)據(jù)的格式標(biāo)準(zhǔn)差異

相比與文本數(shù)據(jù)，短視頻本身是二進(jìn)制數(shù)據(jù)，有比較固定的編碼標(biāo)準(zhǔn)，比如H.264、H.265等，有著比較固定和通用的一些格式標(biāo)準(zhǔn)。

3. 數(shù)據(jù)的處理需求

視頻本身能夠承載的信息比較多，所以會面臨有大量的數(shù)據(jù)處理需求，比如水印、幀縮略圖、轉(zhuǎn)碼等，以及短視頻鑒黃等。而視頻處理的操作是非常慢的，會帶來巨大的資源開銷。

美拍對于視頻的處理，主要分為兩塊：

客戶端處理，視頻處理盡量往客戶端靠，利用現(xiàn)有強(qiáng)大的手機(jī)處理性能來規(guī)避減少服務(wù)器壓力，同時這也會面臨一些低端機(jī)型的處理效率問題，不過特別低端的機(jī)型用于上傳美拍本身比較少數(shù)，所以問題不算明顯。客戶端主要是對于視頻的效果疊加、人臉識別和各種美顏美化算法的處理，我們這邊客戶端有實(shí)驗(yàn)室團(tuán)隊(duì)，在專門做這種效果算法的優(yōu)化工作。同時客戶端處理還會增加一些必要的轉(zhuǎn)碼和水印的視頻處理。目前客戶端的視頻編解碼方式，會有軟編碼和硬編碼的方式，軟編碼主要是兼容性比較好，編碼效果好些，不過缺點(diǎn)就是能耗高且慢些。而硬編碼借助于顯卡等，能夠得到比較低的能耗并且更快，不過兼容和效果要差一些，特別是對于一些低配的機(jī)型。所以目前往往采用結(jié)合的方式。

服務(wù)端的處理，主要是進(jìn)行視頻的一些審核轉(zhuǎn)碼工作，也有一些抽幀生成截圖的工作等，目前使用ffmpeg進(jìn)行一些處理。服務(wù)端本身需要考慮的一些點(diǎn)，就是因?yàn)橘Y源消耗比較高，所以需要機(jī)器數(shù)會多，所以在服務(wù)端做的視頻處理操作，會盡量控制在一個合理的范圍。同時因?yàn)榭赡苊琅倪@種場景，也會遇到這些熱點(diǎn)事件的突變峰值，所以轉(zhuǎn)碼服務(wù)集群本身需要具備可彈性伸縮和異步化消峰機(jī)制，以便來適應(yīng)這種突增請求的場景。

4. 審核問題

視頻內(nèi)容本身可以有任意多樣的表現(xiàn)形式，所以也是一個涉黃涉恐的多發(fā)地帶，而這是一個無法規(guī)避掉的需求，因?yàn)闆]有處理好，可能分分鐘被封站。

審核的最大的問題，主要是會面臨視頻時長過長，會帶來人力審核成本的提升。比如100萬個視頻，每個平均是30s的話，那么就3000W 秒，大概需要347人日。

通過技術(shù)手段可以做一些工作，比如：
1.接入一些比較好的第三方的視頻識別模塊，如果能夠過濾掉85%保證沒有問題的視頻的話，那么工作量會縮減到15%。不過之前在接入使用的時候，發(fā)現(xiàn)效果沒有達(dá)到預(yù)期，目前也在逐步嘗試些其他方案。
2.通過抽幀的方式，比如只抽取某幾幀的方式進(jìn)行檢查。
3.通過轉(zhuǎn)碼的方式，比如一個60s的美拍視頻，通過2倍速的方式，無聲，140 * 140的分辨率轉(zhuǎn)換，大概大小能夠在650kB左右，這樣加速了播放的過程的同時，還能夠減少審核帶寬的消耗，減少了下載過程。
4.基于大數(shù)據(jù)分析，分析一些高危地帶、用戶畫像等，然后通過一些黑名單進(jìn)行一些處理，或者對于某些潛在高危用戶進(jìn)行完整視頻的審核，而對于低危用戶進(jìn)行抽幀的方式等等。

四．為支持億級用戶，美拍架構(gòu)所做的一些改進(jìn)

隨著用戶和訪問量的快速增長，美拍遇到不少的挑戰(zhàn)：
?性能的挑戰(zhàn)
?可用性的挑戰(zhàn)
?突發(fā)熱點(diǎn)的挑戰(zhàn)
?業(yè)務(wù)頻繁迭代的挑戰(zhàn)

在頻繁的業(yè)務(wù)迭代的情況下，如何能夠在海量請求下需要保證足夠高的可用性，同時以一個比較好的用戶體驗(yàn)和比較低的成本的方式來提供服務(wù)成為我們努力的方向。

這個是目前美拍的整體架構(gòu)全貌：

這一個架構(gòu)目前也正在不斷的持續(xù)演進(jìn)的過程，同時除了一些基礎(chǔ)服務(wù)組件的建設(shè)外，我們還著重在服務(wù)治理做一些相關(guān)工作，來保證整體服務(wù)的可用和穩(wěn)定。

分而治之、化繁為簡

規(guī)劃整體架構(gòu)，明確服務(wù)模塊的單一職責(zé)，盡量保持足夠內(nèi)聚，而服務(wù)模塊之間做到解耦，這樣就能夠針對單一模塊進(jìn)行更精細(xì)化的優(yōu)化工作，同時能夠適合合適技術(shù)解決合適的場景問題。

服務(wù)之間的交互和通訊，我們主要走了兩種方式：
?基于http的方式
?基于config service + rpc的方式

前者使用的方式比較簡單，目前我們主要在跨團(tuán)隊(duì)、跨語言（比如php和golang之類的）會使用，主要會在七層nginx層做一些工作，如負(fù)載均衡、節(jié)點(diǎn)探測、并發(fā)保護(hù)等。

而第二種方式，我們主要用于內(nèi)部系統(tǒng)之間的一些交互。目前我們主要基于etcd來實(shí)現(xiàn)我們的動態(tài)服務(wù)發(fā)現(xiàn)和配置服務(wù)，在client層面擴(kuò)展實(shí)現(xiàn)了包含負(fù)載均衡、心跳、節(jié)點(diǎn)健康狀態(tài)探測、etcd節(jié)點(diǎn)掛掉的災(zāi)備等基礎(chǔ)功能，同時會通過一些metrics埋點(diǎn)，以便跟蹤內(nèi)部的狀態(tài)，用統(tǒng)一的trace_id來跟蹤服務(wù)的鏈路調(diào)用情況。

開放擴(kuò)展

主要針對下面幾個點(diǎn)：
?代碼功能的可擴(kuò)展性
?交互協(xié)議的擴(kuò)展性
?數(shù)據(jù)存儲格式的可擴(kuò)展性
?應(yīng)用的可擴(kuò)展性
?資源的可擴(kuò)展性

比如，交互協(xié)議，既針對交互接口，也針對app客戶端和服務(wù)端的交互協(xié)議。特點(diǎn)是app客戶端和服務(wù)端的交互協(xié)議，因?yàn)閍pp的升級較之服務(wù)端升級的時間久得多，比如你發(fā)布了一個客戶端版本V0.1，如果用戶后面一直不升級，這個時間可能是幾個月、半年甚至一年，那么就會引入一些兼容問題，所以在協(xié)議層面設(shè)計(jì)的關(guān)鍵點(diǎn)需要考慮這種情況的存在，需要保證協(xié)議能夠向前兼容，預(yù)留好擴(kuò)展點(diǎn)。

分級隔離

目前我們主要通過這幾個維度進(jìn)行一些隔離：
?核心和非核心的隔離
?單一集群的內(nèi)部隔離
?不同集群的外部物理資源隔離
?不同集群的外部依賴資源的隔離

美拍在發(fā)展早期，跟多數(shù)發(fā)展早期的系統(tǒng)一樣，也是多數(shù)接口部署在同一個集群中，包括也共用了一些資源（比如memcached），這樣的好處是早期部署上足夠的簡單。在發(fā)展的過程中，業(yè)務(wù)在快速發(fā)展，業(yè)務(wù)復(fù)雜度也在逐步提升，接口調(diào)用量也急劇增加，逐步就暴露出一些問題。美拍的發(fā)展過程也是實(shí)際的去驗(yàn)證了前面提到的分級隔離機(jī)制。

在發(fā)展早期，曾經(jīng)有個調(diào)用量不小的非核心的業(yè)務(wù)，在對存儲數(shù)據(jù)結(jié)構(gòu)做了調(diào)整后的上線過程中出現(xiàn)性能問題，導(dǎo)致整個集群服務(wù)都受到一定的影響。雖然通過降級策略和運(yùn)維配套設(shè)施快速的解決了問題，但是也引發(fā)了我們的進(jìn)一步思考。在架構(gòu)上我們會盡量保證在開發(fā)效率、系統(tǒng)架構(gòu)、部署和運(yùn)維成本等方面達(dá)到一定的平衡，以避免過度設(shè)計(jì)或者架構(gòu)支撐不了業(yè)務(wù)。這到了需要做一些事情的時候，我們把核心業(yè)務(wù)和非核心業(yè)務(wù)在七層和應(yīng)用層做了部署上的隔離。

做完上面的核心業(yè)務(wù)和非核心業(yè)務(wù)拆分之后，接口互相之間的依賴影響降低很多。但是還沒有解決核心業(yè)務(wù)或者非核心業(yè)務(wù)內(nèi)部接口之間的依賴影響問題。所以接下來也更進(jìn)一步，針對部分場景也做了內(nèi)部隔離，通過限定每個接口最多只能使用的固定處理線程數(shù)方式，來避免因?yàn)閱蝹€集群內(nèi)某個接口的問題導(dǎo)致整個集群出問題的情況發(fā)生。

以上主要是在接口層面做隔離，而在依賴的資源及其外部服務(wù)方面，如果沒有相應(yīng)的隔離機(jī)制，也會有互相依賴影響的問題，比較典型的有memcached slab calcification問題等。所以我們也在memcached、mysql等核心資源層面做了拆分。

綜合來看，分級隔離本質(zhì)上也是在解決服務(wù)之間依賴影響問題。

資源冗余

因?yàn)槎桃曨l是一個比較耗帶寬的服務(wù)，因此在通用的應(yīng)用自身資源冗余的情況下，還需要考慮到服務(wù)所依賴的外部資源，比如CDN和云存儲服務(wù)本身的情況。對于CDN層面，可能還要考慮不同廠商在不同區(qū)域不同運(yùn)營商下的資源冗余情況。而依賴的云服務(wù)等，這些服務(wù)本身從對外角度看是一個可無限擴(kuò)展的服務(wù)，理論上通過擴(kuò)展就能夠滿足性能需求，但是在使用往往會受限于實(shí)現(xiàn)，因?yàn)閮?nèi)部不一定是一個完全隔離的場景，比如說和別的企業(yè)服務(wù)混跑，同時可能只會分配對應(yīng)的資源池，但這個資源超過性能預(yù)期的時候，不是一個可自動動態(tài)伸縮調(diào)度的場景。

容災(zāi)

美拍的容災(zāi)主要分為自身服務(wù)容災(zāi)、CDN容災(zāi)、云存儲容災(zāi)等。
自身服務(wù)容災(zāi)主要包含一些典型的容災(zāi)場景，比如cache容災(zāi)，通過多級cache、cache的分片hash的方式、以及本地cache的方式來解決。目前我們這邊的容災(zāi)也借鑒了微博的多級cache機(jī)制的機(jī)制，針對核心的cache資源會有主備節(jié)點(diǎn)，避免單一節(jié)點(diǎn)掛掉后，穿透會壓垮后端DB，同時對于請求量特別大的場景，比如對于某個熱點(diǎn)資源訪問量很大的情況下，也會在之前增加一層L1的LRU cache來規(guī)避和緩解這一問題。

CDN容災(zāi)主要通過接入多家供應(yīng)商進(jìn)行互備，然后通過一些基調(diào)檢測不同服務(wù)廠商的鏈路和服務(wù)狀態(tài)，當(dāng)發(fā)現(xiàn)服務(wù)有問題的時候，通過DNS進(jìn)行區(qū)域的切換。不過不同CDN廠商的服務(wù)表現(xiàn)不對等，所以在選型CDN廠商的話，需要側(cè)重關(guān)注可用性、節(jié)點(diǎn)布點(diǎn)和鏈路狀況、回源量、資源冗余量、晚高峰的鏈路狀況、以及對于多媒體是否有多帶帶優(yōu)化等等來評估靠譜性。

云存儲容災(zāi)，目前美拍也主要使用兩家互備的方式，因?yàn)閲鴥?nèi)的網(wǎng)絡(luò)鏈路狀況容易發(fā)生問題容易導(dǎo)致個別上傳服務(wù)失敗，以及云服務(wù)廠商服務(wù)掛掉的情況我們需要保證我們的服務(wù)可用。目前的做法是上傳優(yōu)先走主的云服務(wù)，如果上傳失敗的話，那么就會啟用備的云服務(wù)。然后服務(wù)端層面也可能控制整體降級的方式，可以直接從主云服務(wù)直接降級讀些備云服務(wù)。基于每天的統(tǒng)計(jì)來看，通過這個方式至少提升上傳的0.1%以上的可用性，在某些極端情況下，可能達(dá)到1%的可用性，當(dāng)然這一塊通過網(wǎng)絡(luò)鏈路優(yōu)化可能使得可用性情況沒有數(shù)據(jù)中那么差。不過他的主要作用是在當(dāng)某個云服務(wù)廠商節(jié)點(diǎn)服務(wù)出現(xiàn)短暫不可用或者長時間不可用的時候，我們也不會受太大影響。

五、后續(xù)的一些發(fā)展

隨著短視頻的不斷的發(fā)展，以及實(shí)時直播的崛起，帶寬的壓力會越來越大，所以能夠結(jié)合著P2P+CDN的方式來緩解服務(wù)端的帶寬壓力，不過P2P主要會面臨著防火墻的問題、以及節(jié)點(diǎn)網(wǎng)絡(luò)質(zhì)量的影響，同時也依賴與視頻播放的熱度，這種對于效果都會有一些影響，同時為了更好的播放流暢度，單一的P2P無法滿足需求，需要基于P2P和CDN的輔助進(jìn)行。而帶寬的另外一個節(jié)省之道，就是通過更好的編碼標(biāo)準(zhǔn)來進(jìn)行優(yōu)化，比如H.265的編碼標(biāo)準(zhǔn)，通過這個能夠節(jié)省1半的流量，只不過目前H.265在硬編支持不是很好，只有個別手機(jī)機(jī)型支持，而軟編碼的方式相比與H.264，編解碼速度要慢個幾倍，這種對于能耗消耗比較高，處理也比較慢，不過隨著硬件的不斷升級，H.265將會是后續(xù)的一個趨勢，同時依托與這個之上的一些圖片編碼標(biāo)準(zhǔn)也能夠得到有效的應(yīng)用，從而來節(jié)省帶寬。

同時美拍會越多越多的把一些客戶端的圖片視頻美化算法云端化，以服務(wù)的形式暴露給內(nèi)部其他服務(wù)使用，以便能夠支撐更多圍繞“美”體系建設(shè)的產(chǎn)品生態(tài)鏈。這主要會面臨的架構(gòu)難點(diǎn)，就是資源消耗高。而這個的解決會依賴與兩種方式，一種通過硬件GPU、協(xié)處理器、CPU SIMD指令等來優(yōu)化性能，同時還需要解決架構(gòu)的視頻處理集群的自動彈性調(diào)度的問題，同時對于一些場景，比如類似與H5的推廣頁面，會逐步通過結(jié)合公有云調(diào)度的方式來解決。

[對話架構(gòu)師] 是Boss直聘「直聘學(xué)院」旗下對話系列沙龍。聯(lián)合業(yè)內(nèi)明星創(chuàng)業(yè)公司&合作伙伴聯(lián)合發(fā)起，為架構(gòu)師、運(yùn)維、程序員、開發(fā)者等舉辦的技術(shù)沙龍，旨在通過大咖干貨分享，構(gòu)建純業(yè)內(nèi)、純技術(shù)交流圈，共同推動技術(shù)進(jìn)步。此次活動參與對象主要是CTO，架構(gòu)師，運(yùn)維和技術(shù)經(jīng)理等。

主辦：Boss直聘（互聯(lián)網(wǎng)招聘第一APP）
特別支持社區(qū)：SegmentFault