對話架構師：億級短視頻社交「美拍」架構實戰

本文系美圖架構師麥俊生，在Boss直聘主辦的直聘學院「對話架構師」活動上的分享整理，介紹短視頻社交「美拍」架構實踐的總結。

麥俊生，美圖架構平臺深圳技術總監，曾擔任新浪微博、奇虎360技術專家，從事高性能高可用架構設計開發工做，參與建設微博的feed和私信im系統、負責rpc框架motan、cache service、 counter service、公用類庫等基礎建設，以及奇虎360存儲服務和基礎框架方面的建設。我的擅長性能調優、高可用中間件、分佈式存儲、IM等相關領域。

如下是分享實錄整理：《億級短視頻社交美拍架構實踐》

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

短視頻的相繼爆發，與幾個因素有關：

1. 帶寬，隨着中國基礎網絡環境的發展，愈來愈多的2G移動網民開始轉向3G/4G網絡，從而提供更好的上傳下載帶寬和更穩定的體驗，目前3G/4G的移動用戶比例大概佔比85%以上；同時隨着資費的進一步下降，月戶平均流量也達到了360M，甚至很多部分是GB甚至幾十GB的級別的流量，因此就一個普通的10s視頻而言大概不到1~2M甚至幾百K，帶寬流量的提高無疑會逐步下降用戶使用的門檻；此外，家用帶寬也隨之增長，目前10M甚至100M已經成爲家用帶寬的主流，從而爲短視頻的發展提供了必要條件。

2.手機硬件配置的極大改進，隨着像素的增長、手機硬件配置CPU、GPU、內存等的升級，可以讓手機更快的來處理和優化視頻效果，從而可以給手機視頻的處理帶來更多的創意空間。

3.傳統的文字和圖片的表達能力不夠豐富，因此沒法知足網民的需求，而短視頻帶來了足夠大的表現空間。

4.產品自己，提供了各類方式來下降用戶視頻的製做門檻，好比美拍提供了MV特效等，來提高了製做視頻的趣味性的同時，下降使用的門檻。同時產品的多樣化，也知足了各類用戶的差別化需求，激發用戶自傳播。

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

面臨這種用戶量爆發的增加，美拍也遇到了不少應用起步之初那些年所遇到的甜蜜和苦澀的回憶，通過1年多的架構的演進，美拍也積累了必定的經驗，造成了一套高可用高的架構實踐。雖沒法作到很華麗，卻會隨着架構的不斷的演進而不斷的完善。

相比與普通的文本社交類APP，作這麼一個短視頻產品在技術架構層面，會面臨哪些問題呢？

和通用的文本社交類產品同樣，美拍有首頁熱門、好友動態(feed流)、評論服務、私信服務等基礎功能；因此在用戶爆發增加後，一樣會面臨應用層、數據庫、緩存、接入層等方面的挑戰，那麼如何作到低延遲、高可用呢。同時由於是短視頻自己，也會面臨一些特定的領域性相關的問題。

3、短視頻所面臨的架構問題

短視頻相比於文本數據而言，有着一些差別：

1. 數據大小的差別。

好比一條美拍，通過視頻壓縮和清晰度的權衡，10s的視頻大小1MB多，而一條5分鐘視頻的美拍甚至要達到幾十M，相比與幾十字節或者幾百字節的文本要大得多。由於數據量要大得多，因此也會面臨一些問題：如何上傳、如何存放、以及如何播放的問題。

關於上傳，要在手機上傳這麼一個視頻，特別是弱網環境要上傳這麼一個文件，上傳的成功率會比較低，晚高峯的時候，省際網絡的擁塞狀況下，要更爲明顯得多。因此針對上傳，須要基於CDN走動態加速來優化網絡鏈路（經過基調實測過對於提高穩定性和速度有必定幫助），同時對於比較大的視頻須要作好分片上傳，減小失敗重傳的成本和失敗機率等來提高可用性。同時不一樣CDN廠商的鏈路情況在不一樣的運營商不一樣地區可能表現不一，因此也須要結合基調測試，選擇一些比較適合本身的CDN廠商鏈路。

同時由於數據相對比較大，當數據量達到必定規模，存儲容量會面臨一些挑戰，目前美拍的視頻容量級別也達到PB級別的規模，因此要求存儲自己可以具有比較強的線性擴展能力，而且有足夠的資源冗餘，而傳統的Mysql等數據庫比較難來支持這個場景，因此每每藉助於專用的分佈式對象存儲，經過自建的服務或者雲存儲服務可以解決，得益於近幾年雲存儲的發展，目前美拍主要仍是使用雲存儲服務來解決。自身的分佈式對象存儲主要用於解決一些內部場景，好比對於數據隱私性和安全性要求比較高的場景。

關於對於播放，由於文件比較大，也容易受到網絡的影響，因此爲了規避卡頓，一些細節也須要處理。好比對於60s，300s的視頻，須要考慮到文件比較大，同時有拖動的需求，因此通常使用http range的方式，或者基於HLS的點播播放方式，基於前者比較簡單粗暴，不過基於播放器的機制，也可以知足需求，也能實現點播拖動。而直接基於HLS的方式會更友好，特別是更長的一些視頻，好比5分鐘甚至更大的視頻，不過這種須要單獨的轉碼支持。以前美拍主要是短視頻爲主，因此更多使用http range的方式。然後續隨着5分鐘或者更大視頻的場景，也在逐步作一些嘗試。同時對於播放而言，在弱化環境下，可能也會面臨一些問題，好比播放時長卡頓的問題，這種通常經過網絡鏈路優化；或者經過多碼率的自適應優化，好比多路轉碼，而後根據特定算法模型量化用戶網絡狀況進行選碼率，網絡差的用低碼率的方式。

2. 數據的格式標準差別

相比與文本數據，短視頻自己是二進制數據，有比較固定的編碼標準，好比H.26四、H.265等，有着比較固定和通用的一些格式標準。

3. 數據的處理需求

視頻自己可以承載的信息比較多，因此會面臨有大量的數據處理需求，好比水印、幀縮略圖、轉碼等，以及短視頻鑑黃等。而視頻處理的操做是很是慢的，會帶來巨大的資源開銷。

美拍對於視頻的處理，主要分爲兩塊：

客戶端處理，視頻處理儘可能往客戶端靠，利用現有強大的手機處理性能來規避減小服務器壓力，同時這也會面臨一些低端機型的處理效率問題，不過特別低端的機型用於上傳美拍自己比較少數，因此問題不算明顯。客戶端主要是對於視頻的效果疊加、人臉識別和各類美顏美化算法的處理，咱們這邊客戶端有實驗室團隊，在專門作這種效果算法的優化工做。同時客戶端處理還會增長一些必要的轉碼和水印的視頻處理。目前客戶端的視頻編解碼方式，會有軟編碼和硬編碼的方式，軟編碼主要是兼容性比較好，編碼效果好些，不過缺點就是能耗高且慢些。而硬編碼藉助於顯卡等，可以獲得比較低的能耗而且更快，不過兼容和效果要差一些，特別是對於一些低配的機型。因此目前每每採用結合的方式。

服務端的處理，主要是進行視頻的一些審覈轉碼工做，也有一些抽幀生成截圖的工做等，目前使用ffmpeg進行一些處理。服務端自己須要考慮的一些點，就是由於資源消耗比較高，因此須要機器數會多，因此在服務端作的視頻處理操做，會盡可能控制在一個合理的範圍。同時由於可能美拍這種場景，也會遇到這些熱點事件的突變峯值，因此轉碼服務集羣自己須要具有可彈性伸縮和異步化消峯機制，以便來適應這種突增請求的場景。

4. 審覈問題

視頻內容自己能夠有任意多樣的表現形式，因此也是一個涉黃涉恐的多發地帶，而這是一個沒法規避掉的需求，由於沒有處理好，可能分分鐘被封站。

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

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

四．爲支持億級用戶，美拍架構所作的一些改進

隨着用戶和訪問量的快速增加，美拍遇到很多的挑戰：
性能的挑戰
可用性的挑戰
突發熱點的挑戰
業務頻繁迭代的挑戰

在頻繁的業務迭代的狀況下，如何可以在海量請求下須要保證足夠高的可用性，同時以一個比較好的用戶體驗和比較低的成本的方式來提供服務成爲咱們努力的方向。

這個是目前美拍的總體架構全貌：

這一個架構目前也正在不斷的持續演進的過程，同時除了一些基礎服務組件的建設外，咱們還着重在服務治理作一些相關工做，來保證總體服務的可用和穩定。

分而治之、化繁爲簡

規劃總體架構，明確服務模塊的單一職責，儘可能保持足夠內聚，而服務模塊之間作到解耦，這樣就可以針對單一模塊進行更精細化的優化工做，同時可以適合合適技術解決合適的場景問題。

服務之間的交互和通信，咱們主要走了兩種方式：
基於http的方式
基於config service + rpc的方式

前者使用的方式比較簡單，目前咱們主要在跨團隊、跨語言（好比php和golang之類的）會使用，主要會在七層nginx層作一些工做，如負載均衡、節點探測、併發保護等。

而第二種方式，咱們主要用於內部系統之間的一些交互。目前咱們主要基於etcd來實現咱們的動態服務發現和配置服務，在client層面擴展實現了包含負載均衡、心跳、節點健康狀態探測、etcd節點掛掉的災備等基礎功能，同時會經過一些metrics埋點，以便跟蹤內部的狀態，用統一的trace_id來跟蹤服務的鏈路調用狀況。

開放擴展

主要針對下面幾個點：
代碼功能的可擴展性
交互協議的擴展性
數據存儲格式的可擴展性
應用的可擴展性
資源的可擴展性

好比，交互協議，既針對交互接口，也針對app客戶端和服務端的交互協議。特色是app客戶端和服務端的交互協議，由於app的升級較之服務端升級的時間久得多，好比你發佈了一個客戶端版本V0.1，若是用戶後面一直不升級，這個時間多是幾個月、半年甚至一年，那麼就會引入一些兼容問題，因此在協議層面設計的關鍵點須要考慮這種狀況的存在，須要保證協議可以向前兼容，預留好擴展點。

分級隔離

目前咱們主要經過這幾個維度進行一些隔離：
核心和非核心的隔離
單一集羣的內部隔離
不一樣集羣的外部物理資源隔離
不一樣集羣的外部依賴資源的隔離

美拍在發展早期，跟多數發展早期的系統同樣，也是多數接口部署在同一個集羣中，包括也共用了一些資源（好比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%的可用性，固然這一塊經過網絡鏈路優化可能使得可用性狀況沒有數據中那麼差。不過他的主要做用是在當某個雲服務廠商節點服務出現短暫不可用或者長時間不可用的時候，咱們也不會受太大影響。

5、後續的一些發展

隨着短視頻的不斷的發展，以及實時直播的崛起，帶寬的壓力會愈來愈大，因此可以結合着P2P+CDN的方式來緩解服務端的帶寬壓力，不過P2P主要會面臨着防火牆的問題、以及節點網絡質量的影響，同時也依賴與視頻播放的熱度，這種對於效果都會有一些影響，同時爲了更好的播放流暢度，單一的P2P沒法知足需求，須要基於P2P和CDN的輔助進行。而帶寬的另一個節省之道，就是經過更好的編碼標準來進行優化，好比H.265的編碼標準，經過這個可以節省1半的流量，只不過目前H.265在硬編支持不是很好，只有個別手機機型支持，而軟編碼的方式相比與H.264，編解碼速度要慢個幾倍，這種對於能耗消耗比較高，處理也比較慢，不過隨着硬件的不斷升級，H.265將會是後續的一個趨勢，同時依託與這個之上的一些圖片編碼標準也可以獲得有效的應用，從而來節省帶寬。

同時美拍會越多越多的把一些客戶端的圖片視頻美化算法雲端化，以服務的形式暴露給內部其餘服務使用，以便可以支撐更多圍繞「美」體系建設的產品生態鏈。這主要會面臨的架構難點，就是資源消耗高。而這個的解決會依賴與兩種方式，一種經過硬件GPU、協處理器、CPU SIMD指令等來優化性能，同時還須要解決架構的視頻處理集羣的自動彈性調度的問題，同時對於一些場景，好比相似與H5的推廣頁面，會逐步經過結合公有云調度的方式來解決。

[對話架構師] 是Boss直聘「直聘學院」旗下對話系列沙龍。聯合業內明星創業公司&合做夥伴聯合發起，爲架構師、運維、程序員、開發者等舉辦的技術沙龍，旨在經過大咖乾貨分享，構建純業內、純技術交流圈，共同推進技術進步。這次活動參與對象主要是CTO，架構師，運維和技術經理等。

主辦：Boss直聘（互聯網招聘第一APP）
特別支持社區：SegmentFault