轉(zhuǎn)載:對話架構(gòu)師：億級短視頻社交美拍架構(gòu)實踐
本文系麥俊生在BOSS直聘主辦的直聘學院「對話架構(gòu)師」活動上的精彩分享。
一涩咖、短視頻市場的發(fā)展
近幾年來，短視頻應用在國內(nèi)應用市場引爆，美圖公司推出了美拍，GIF快手公司也推出了短視頻產(chǎn)品及刻，以及微博投資的秒拍，還有微視竞阐、逗拍缴饭、玩拍等一系列短視頻產(chǎn)品也豐富了短視頻應用市場。
短視頻的相繼爆發(fā)骆莹，與幾個因素有關(guān)：
1.帶寬茴扁，隨著中國基礎(chǔ)網(wǎng)絡(luò)環(huán)境的發(fā)展豫喧，越來越多的2G移動網(wǎng)民開始轉(zhuǎn)向3G/4G網(wǎng)絡(luò)娶视，從而提供更好的上傳下載帶寬和更穩(wěn)定的體驗逢净，目前3G/4G的移動用戶比例大概占比85%以上；同時隨著資費的進一步降低智嚷，月戶平均流量也達到了360M，甚至不少部分是GB甚至幾十GB的級別的流量纺且，所以就一個普通的10s視頻而言大概不到1~2M甚至幾百K盏道，帶寬流量的提升無疑會逐步降低用戶使用的門檻；此外载碌，家用帶寬也隨之增加猜嘱，目前10M甚至100M已經(jīng)成為家用帶寬的主流，從而為短視頻的發(fā)展提供了必要條件嫁艇。
2.手機硬件配置的極大改進朗伶，隨著像素的增加、手機硬件配置CPU步咪、GPU论皆、內(nèi)存等的升級，能夠讓手機更快的來處理和優(yōu)化視頻效果，從而能夠給手機視頻的處理帶來更多的創(chuàng)意空間点晴。
3.傳統(tǒng)的文字和圖片的表達能力不夠豐富感凤，所以無法滿足網(wǎng)民的需求，而短視頻帶來了足夠大的表現(xiàn)空間粒督。
4.產(chǎn)品本身陪竿，提供了各種方式來降低用戶視頻的制作門檻，比如美拍提供了MV特效等屠橄，來提升了制作視頻的趣味性的同時族跛，降低使用的門檻。同時產(chǎn)品的多樣化仇矾，也滿足了各種用戶的差異化需求庸蔼，激發(fā)用戶自傳播。
二贮匕、美拍的發(fā)展
美拍在2014.05月發(fā)布姐仅，上線僅1天，即登入App Store免費總榜第一刻盐，當月下載量排名第一掏膏。在發(fā)布9個月的時候，用戶就突破1個億敦锌。目前每天美拍視頻日播放量在2.7億以上馒疹，日視頻播放時長達到183萬小時。
面臨這種用戶量爆發(fā)的增長乙墙，美拍也遇到了很多應用起步之初那些年所遇到的甜蜜和苦澀的回憶颖变，經(jīng)過1年多的架構(gòu)的演進，美拍也積累了一定的經(jīng)驗听想，形成了一套高可用高的架構(gòu)實踐腥刹。雖無法做到很華麗，卻會隨著架構(gòu)的不斷的演進而不斷的完善汉买。
相比與普通的文本社交類APP衔峰，做這么一個短視頻產(chǎn)品在技術(shù)架構(gòu)層面，會面臨哪些問題呢蛙粘？
和通用的文本社交類產(chǎn)品一樣垫卤，美拍有首頁熱門、好友動態(tài)(feed流)出牧、評論服務穴肘、私信服務等基礎(chǔ)功能；所以在用戶爆發(fā)增長后崔列，同樣會面臨應用層梢褐、數(shù)據(jù)庫旺遮、緩存、接入層等方面的挑戰(zhàn)盈咳，那么如何做到低延遲耿眉、高可用呢。同時因為是短視頻本身鱼响，也會面臨一些特定的領(lǐng)域性相關(guān)的問題鸣剪。
三、短視頻所面臨的架構(gòu)問題
短視頻相比于文本數(shù)據(jù)而言丈积，有著一些差異：
1. 數(shù)據(jù)大小的差異筐骇。
比如一條美拍，經(jīng)過視頻壓縮和清晰度的權(quán)衡江滨，10s的視頻大小1MB多铛纬，而一條5分鐘視頻的美拍甚至要達到幾十M，相比與幾十字節(jié)或者幾百字節(jié)的文本要大得多唬滑。因為數(shù)據(jù)量要大得多告唆，所以也會面臨一些問題：如何上傳、如何存放晶密、以及如何播放的問題擒悬。
關(guān)于上傳，要在手機上傳這么一個視頻稻艰，特別是弱網(wǎng)環(huán)境要上傳這么一個文件懂牧，上傳的成功率會比較低，晚高峰的時候尊勿，省際網(wǎng)絡(luò)的擁塞情況下僧凤，要更為明顯得多。所以針對上傳元扔，需要基于CDN走動態(tài)加速來優(yōu)化網(wǎng)絡(luò)鏈路（通過基調(diào)實測過對于提升穩(wěn)定性和速度有一定幫助）拼弃，同時對于比較大的視頻需要做好分片上傳，減少失敗重傳的成本和失敗概率等來提升可用性摇展。同時不同CDN廠商的鏈路狀況在不同的運營商不同地區(qū)可能表現(xiàn)不一，所以也需要結(jié)合基調(diào)測試溺忧，選擇一些比較適合自己的CDN廠商鏈路咏连。
同時因為數(shù)據(jù)相對比較大，當數(shù)據(jù)量達到一定規(guī)模鲁森，存儲容量會面臨一些挑戰(zhàn)祟滴，目前美拍的視頻容量級別也達到PB級別的規(guī)模，所以要求存儲本身能夠具備比較強的線性擴展能力歌溉，并且有足夠的資源冗余垄懂，而傳統(tǒng)的Mysql等數(shù)據(jù)庫比較難來支持這個場景骑晶，所以往往借助于專用的分布式對象存儲，通過自建的服務或者云存儲服務能夠解決草慧，得益于近幾年云存儲的發(fā)展桶蛔，目前美拍主要還是使用云存儲服務來解決。自身的分布式對象存儲主要用于解決一些內(nèi)部場景漫谷，比如對于數(shù)據(jù)隱私性和安全性要求比較高的場景仔雷。
關(guān)于對于播放，因為文件比較大舔示，也容易受到網(wǎng)絡(luò)的影響碟婆，所以為了規(guī)避卡頓，一些細節(jié)也需要處理惕稻。比如對于60s竖共，300s的視頻，需要考慮到文件比較大俺祠，同時有拖動的需求公给，所以一般使用http range的方式，或者基于HLS的點播播放方式锻煌，基于前者比較簡單粗暴妓布，不過基于播放器的機制，也能夠滿足需求宋梧，也能實現(xiàn)點播拖動匣沼。而直接基于HLS的方式會更友好，特別是更長的一些視頻捂龄，比如5分鐘甚至更大的視頻释涛，不過這種需要單獨的轉(zhuǎn)碼支持。之前美拍主要是短視頻為主倦沧，所以更多使用http range的方式唇撬。而后續(xù)隨著5分鐘或者更大視頻的場景，也在逐步做一些嘗試展融。同時對于播放而言窖认，在弱化環(huán)境下，可能也會面臨一些問題告希，比如播放時長卡頓的問題扑浸，這種一般通過網(wǎng)絡(luò)鏈路優(yōu)化；或者通過多碼率的自適應優(yōu)化燕偶，比如多路轉(zhuǎn)碼喝噪，然后根據(jù)特定算法模型量化用戶網(wǎng)絡(luò)情況進行選碼率，網(wǎng)絡(luò)差的用低碼率的方式指么。
2. 數(shù)據(jù)的格式標準差異
相比與文本數(shù)據(jù)酝惧，短視頻本身是二進制數(shù)據(jù)榴鼎，有比較固定的編碼標準，比如H.264晚唇、H.265等巫财，有著比較固定和通用的一些格式標準。
3. 數(shù)據(jù)的處理需求
視頻本身能夠承載的信息比較多缺亮，所以會面臨有大量的數(shù)據(jù)處理需求翁涤，比如水印、幀縮略圖萌踱、轉(zhuǎn)碼等葵礼，以及短視頻鑒黃等。而視頻處理的操作是非常慢的并鸵，會帶來巨大的資源開銷鸳粉。
美拍對于視頻的處理，主要分為兩塊：
客戶端處理园担，視頻處理盡量往客戶端靠届谈，利用現(xiàn)有強大的手機處理性能來規(guī)避減少服務器壓力，同時這也會面臨一些低端機型的處理效率問題弯汰，不過特別低端的機型用于上傳美拍本身比較少數(shù)艰山，所以問題不算明顯∮缴粒客戶端主要是對于視頻的效果疊加曙搬、人臉識別和各種美顏美化算法的處理，我們這邊客戶端有實驗室團隊鸽嫂，在專門做這種效果算法的優(yōu)化工作纵装。同時客戶端處理還會增加一些必要的轉(zhuǎn)碼和水印的視頻處理。目前客戶端的視頻編解碼方式据某，會有軟編碼和硬編碼的方式橡娄，軟編碼主要是兼容性比較好，編碼效果好些癣籽，不過缺點就是能耗高且慢些挽唉。而硬編碼借助于顯卡等，能夠得到比較低的能耗并且更快筷狼，不過兼容和效果要差一些橱夭，特別是對于一些低配的機型。所以目前往往采用結(jié)合的方式桑逝。
服務端的處理，主要是進行視頻的一些審核轉(zhuǎn)碼工作俏让，也有一些抽幀生成截圖的工作等楞遏，目前使用ffmpeg進行一些處理茬暇。服務端本身需要考慮的一些點，就是因為資源消耗比較高寡喝，所以需要機器數(shù)會多糙俗，所以在服務端做的視頻處理操作，會盡量控制在一個合理的范圍预鬓。同時因為可能美拍這種場景巧骚，也會遇到這些熱點事件的突變峰值，所以轉(zhuǎn)碼服務集群本身需要具備可彈性伸縮和異步化消峰機制格二，以便來適應這種突增請求的場景劈彪。
4. 審核問題
視頻內(nèi)容本身可以有任意多樣的表現(xiàn)形式，所以也是一個涉黃涉恐的多發(fā)地帶顶猜，而這是一個無法規(guī)避掉的需求沧奴，因為沒有處理好，可能分分鐘被封站长窄。
審核的最大的問題滔吠，主要是會面臨視頻時長過長，會帶來人力審核成本的提升挠日。比如100萬個視頻疮绷，每個平均是30s的話，那么就3000W 秒嚣潜，大概需要347人日冬骚。
通過技術(shù)手段可以做一些工作，比如：
接入一些比較好的第三方的視頻識別模塊郑原，如果能夠過濾掉85%保證沒有問題的視頻的話唉韭，那么工作量會縮減到15%。不過之前在接入使用的時候犯犁，發(fā)現(xiàn)效果沒有達到預期属愤，目前也在逐步嘗試些其他方案。
通過抽幀的方式酸役，比如只抽取某幾幀的方式進行檢查住诸。
通過轉(zhuǎn)碼的方式，比如一個60s的美拍視頻涣澡，通過2倍速的方式贱呐，無聲，140 * 140的分辨率轉(zhuǎn)換入桂，大概大小能夠在650kB左右奄薇，這樣加速了播放的過程的同時，還能夠減少審核帶寬的消耗抗愁，減少了下載過程馁蒂。
基于大數(shù)據(jù)分析呵晚，分析一些高危地帶、用戶畫像等沫屡，然后通過一些黑名單進行一些處理饵隙，或者對于某些潛在高危用戶進行完整視頻的審核，而對于低危用戶進行抽幀的方式等等沮脖。
四．為支持億級用戶金矛，美拍架構(gòu)所做的一些改進
隨著用戶和訪問量的快速增長，美拍遇到不少的挑戰(zhàn)：
性能的挑戰(zhàn)
可用性的挑戰(zhàn)
突發(fā)熱點的挑戰(zhàn)
業(yè)務頻繁迭代的挑戰(zhàn)
在頻繁的業(yè)務迭代的情況下勺届，如何能夠在海量請求下需要保證足夠高的可用性驶俊，同時以一個比較好的用戶體驗和比較低的成本的方式來提供服務成為我們努力的方向。
這個是目前美拍的整體架構(gòu)全貌：
這一個架構(gòu)目前也正在不斷的持續(xù)演進的過程涮因，同時除了一些基礎(chǔ)服務組件的建設(shè)外废睦，我們還著重在服務治理做一些相關(guān)工作，來保證整體服務的可用和穩(wěn)定养泡。
分而治之嗜湃、化繁為簡
規(guī)劃整體架構(gòu)，明確服務模塊的單一職責澜掩，盡量保持足夠內(nèi)聚购披，而服務模塊之間做到解耦，這樣就能夠針對單一模塊進行更精細化的優(yōu)化工作肩榕，同時能夠適合合適技術(shù)解決合適的場景問題刚陡。
服務之間的交互和通訊，我們主要走了兩種方式：
基于http的方式
基于grpc+etcd的方式
前者使用的方式比較簡單株汉，目前我們主要在跨團隊筐乳、跨語言（比如php和golang之類的）會使用，主要會在七層nginx層做一些工作乔妈，如負載均衡蝙云、節(jié)點探測、并發(fā)保護等路召。
而第二種方式勃刨，我們主要用于內(nèi)部系統(tǒng)之間的一些交互。目前我們主要基于etcd來實現(xiàn)我們的動態(tài)服務發(fā)現(xiàn)和配置服務股淡，在client層面擴展實現(xiàn)了包含負載均衡身隐、心跳、節(jié)點健康狀態(tài)探測唯灵、etcd節(jié)點掛掉的災備等基礎(chǔ)功能贾铝，同時會通過一些metrics埋點，以便跟蹤內(nèi)部的狀態(tài)，用統(tǒng)一的trace_id來跟蹤服務的鏈路調(diào)用情況垢揩。
開放擴展
主要針對下面幾個點：
代碼功能的可擴展性
交互協(xié)議的擴展性
數(shù)據(jù)存儲格式的可擴展性
應用的可擴展性
資源的可擴展性
比如大脉，交互協(xié)議，既針對交互接口水孩，也針對app客戶端和服務端的交互協(xié)議。特點是app客戶端和服務端的交互協(xié)議琐驴，因為app的升級較之服務端升級的時間久得多俘种，比如你發(fā)布了一個客戶端版本V0.1，如果用戶后面一直不升級绝淡，這個時間可能是幾個月宙刘、半年甚至一年，那么就會引入一些兼容問題牢酵，所以在協(xié)議層面設(shè)計的關(guān)鍵點需要考慮這種情況的存在悬包，需要保證協(xié)議能夠向前兼容，預留好擴展點馍乙。
分級隔離
目前我們主要通過這幾個維度進行一些隔離：
核心和非核心的隔離
單一集群的內(nèi)部隔離
不同集群的外部物理資源隔離
不同集群的外部依賴資源的隔離
美拍在發(fā)展早期布近，跟多數(shù)發(fā)展早期的系統(tǒng)一樣，也是多數(shù)接口部署在同一個集群中丝格，包括也共用了一些資源（比如memcached）撑瞧，這樣的好處是早期部署上足夠的簡單。在發(fā)展的過程中显蝌，業(yè)務在快速發(fā)展预伺，業(yè)務復雜度也在逐步提升，接口調(diào)用量也急劇增加曼尊，逐步就暴露出一些問題酬诀。美拍的發(fā)展過程也是實際的去驗證了前面提到的分級隔離機制。
在發(fā)展早期骆撇，曾經(jīng)有個調(diào)用量不小的非核心的業(yè)務瞒御，在對存儲數(shù)據(jù)結(jié)構(gòu)做了調(diào)整后的上線過程中出現(xiàn)性能問題，導致整個集群服務都受到一定的影響艾船。雖然通過降級策略和運維配套設(shè)施快速的解決了問題葵腹，但是也引發(fā)了我們的進一步思考。在架構(gòu)上我們會盡量保證在開發(fā)效率屿岂、系統(tǒng)架構(gòu)践宴、部署和運維成本等方面達到一定的平衡，以避免過度設(shè)計或者架構(gòu)支撐不了業(yè)務爷怀。這到了需要做一些事情的時候阻肩，我們把核心業(yè)務和非核心業(yè)務在七層和應用層做了部署上的隔離。
做完上面的核心業(yè)務和非核心業(yè)務拆分之后，接口互相之間的依賴影響降低很多烤惊。但是還沒有解決核心業(yè)務或者非核心業(yè)務內(nèi)部接口之間的依賴影響問題乔煞。所以接下來也更進一步，針對部分場景也做了內(nèi)部隔離柒室，通過限定每個接口最多只能使用的固定處理線程數(shù)方式渡贾，來避免因為單個集群內(nèi)某個接口的問題導致整個集群出問題的情況發(fā)生。
以上主要是在接口層面做隔離雄右，而在依賴的資源及其外部服務方面空骚，如果沒有相應的隔離機制，也會有互相依賴影響的問題擂仍，比較典型的有memcached slab calcification問題等囤屹。所以我們也在memcached、mysql等核心資源層面做了拆分逢渔。
綜合來看肋坚，分級隔離本質(zhì)上也是在解決服務之間依賴影響問題。
資源冗余
因為短視頻是一個比較耗帶寬的服務肃廓，因此在通用的應用自身資源冗余的情況下智厌，還需要考慮到服務所依賴的外部資源，比如CDN和云存儲服務本身的情況亿昏。對于CDN層面峦剔，可能還要考慮不同廠商在不同區(qū)域不同運營商下的資源冗余情況。而依賴的云服務等角钩，這些服務本身從對外角度看是一個可無限擴展的服務吝沫，理論上通過擴展就能夠滿足性能需求，但是在使用往往會受限于實現(xiàn)递礼，因為內(nèi)部不一定是一個完全隔離的場景惨险，比如說和別的企業(yè)服務混跑，同時可能只會分配對應的資源池脊髓，但這個資源超過性能預期的時候辫愉，不是一個可自動動態(tài)伸縮調(diào)度的場景。
容災
自身服務容災主要包含一些典型的容災場景将硝，比如cache容災恭朗，通過多級cache、cache的分片hash的方式依疼、以及本地cache的方式來解決痰腮。目前我們這邊的容災也借鑒了微博的多級cache機制的機制，針對核心的cache資源會有主備節(jié)點律罢，避免單一節(jié)點掛掉后膀值，穿透會壓垮后端DB，同時對于請求量特別大的場景，比如對于某個熱點資源訪問量很大的情況下沧踏，也會在之前增加一層L1的LRU cache來規(guī)避和緩解這一問題歌逢。
CDN容災主要通過接入多家供應商進行互備，然后通過一些基調(diào)檢測不同服務廠商的鏈路和服務狀態(tài)翘狱，當發(fā)現(xiàn)服務有問題的時候秘案，通過DNS進行區(qū)域的切換。不過不同CDN廠商的服務表現(xiàn)不對等潦匈，所以在選型CDN廠商的話踏烙，需要側(cè)重關(guān)注可用性、節(jié)點布點和鏈路狀況历等、回源量、資源冗余量辟癌、晚高峰的鏈路狀況寒屯、以及對于多媒體是否有單獨優(yōu)化等等來評估靠譜性。
云存儲容災黍少，目前美拍也主要使用兩家互備的方式寡夹，因為國內(nèi)的網(wǎng)絡(luò)鏈路狀況容易發(fā)生問題容易導致個別上傳服務失敗，以及云服務廠商服務掛掉的情況我們需要保證我們的服務可用厂置。目前的做法是上傳優(yōu)先走主的云服務菩掏，如果上傳失敗的話，那么就會啟用備的云服務昵济。然后服務端層面也可能控制整體降級的方式智绸，可以直接從主云服務直接降級讀些備云服務》梅蓿基于每天的統(tǒng)計來看瞧栗，通過這個方式至少提升上傳的0.1%以上的可用性，在某些極端情況下海铆，可能達到1%的可用性迹恐，當然這一塊通過網(wǎng)絡(luò)鏈路優(yōu)化可能使得可用性情況沒有數(shù)據(jù)中那么差。不過他的主要作用是在當某個云服務廠商節(jié)點服務出現(xiàn)短暫不可用或者長時間不可用的時候卧斟，我們也不會受太大影響殴边。
五、后續(xù)的一些發(fā)展
隨著短視頻的不斷的發(fā)展珍语，以及實時直播的崛起锤岸，帶寬的壓力會越來越大，所以能夠結(jié)合著P2P+CDN的方式來緩解服務端的帶寬壓力廊酣，不過P2P主要會面臨著防火墻的問題蛤吓、以及節(jié)點網(wǎng)絡(luò)質(zhì)量的影響那先，同時也依賴與視頻播放的熱度狼纬，這種對于效果都會有一些影響拴念，同時為了更好的播放流暢度，單一的P2P無法滿足需求舷手，需要基于P2P和CDN的輔助進行。而帶寬的另外一個節(jié)省之道，就是通過更好的編碼標準來進行優(yōu)化栗恩，比如H.265的編碼標準，通過這個能夠節(jié)省1半的流量洪燥，只不過目前H.265在硬編支持不是很好磕秤，只有個別手機機型支持，而軟編碼的方式相比與H.264捧韵，編解碼速度要慢個幾倍市咆，這種對于能耗消耗比較高，處理也比較慢再来，不過隨著硬件的不斷升級蒙兰，H.265將會是后續(xù)的一個趨勢，同時依托與這個之上的一些圖片編碼標準也能夠得到有效的應用芒篷，從而來節(jié)省帶寬搜变。
同時美拍會越多越多的把一些客戶端的圖片視頻美化算法云端化，以服務的形式暴露給內(nèi)部其他服務使用针炉，以便能夠支撐更多圍繞“美”體系建設(shè)的產(chǎn)品生態(tài)鏈挠他。這主要會面臨的架構(gòu)難點，就是資源消耗高篡帕。而這個的解決會依賴與兩種方式殖侵，一種通過硬件GPU、協(xié)處理器镰烧、CPU SIMD指令等來優(yōu)化性能愉耙，同時還需要解決架構(gòu)的視頻處理集群的自動彈性調(diào)度的問題，同時對于一些場景拌滋，比如類似與H5的推廣頁面朴沿，會逐步通過結(jié)合公有云調(diào)度的方式來解決。
近期文章（可直接點擊閱讀）
創(chuàng)業(yè)型公司如何做好監(jiān)控報警
