轉：美拍的短視頻架構說明

編者按：本文做者爲美圖架構平臺深圳技術總監麥俊生，文章介紹了其在 BOSS 直聘主辦的直聘學院「對話架構師」活動上的分享精華，36 氪經受權轉載自微信公衆號高可用架構「ArchNotes」。

在美拍的服務化過程當中，主要基於 etcd 來實現咱們的動態服務發現和配置服務，在 client 層面擴展實現了包含負載均衡、心跳、節點健康狀態探測、etcd 節點掛掉的災備等基礎功能，同時會經過一些 metrics 埋點，以便跟蹤內部的狀態，用統一的 trace_id 來跟蹤服務的鏈路調用狀況。

1、短視頻市場的發展

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

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

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

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

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

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

2、美拍的發展

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

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

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

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

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

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

一、數據大小的差別

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

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

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

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

二、數據的格式標準差別

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

三、數據的處理需求

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

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

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

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

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

隨着用戶和訪問量的快速增加，美拍遇到很多的挑戰

• 性能的挑戰
• 可用性的挑戰
• 突發熱點的挑戰
• 業務頻繁迭代的挑戰

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

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

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

分而治之、化繁爲簡

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

服務之間的交互和通信，咱們主要走了兩種方式：

• 基於 HTTP 的方式
• 基於 config service + 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% 的可用性，固然這一塊經過網絡鏈路優化可能使得可用性狀況沒有數據中那麼差。不過他的主要做用是在當某個雲服務廠商節點服務出現短暫不可用或者長時間不可用的時候，咱們也不會受太大影響。

5、後續的一些發展

隨着短視頻的不斷的發展，以及實時直播的崛起，帶寬的壓力會愈來愈大，因此可以結合着 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 的推廣頁面，會逐步經過結合公有云調度的方式來解決。

本文來自讀者投稿，不表明36氪立場，如若轉載，請註明出處：http://36kr.com/p/5042461.html「看完這篇還不夠？若是你也在創業，並但願本身的項目被報道，請戳這裏告訴咱們！」