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

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

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

　　一、短視頻市場(chǎng)的發(fā)展

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

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

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

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

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

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

二、美拍的發(fā)展

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

4. 審核問(wèn)題

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

審核的最大的問(wèn)題，主要是會(huì)面臨視頻時(shí)長(zhǎng)過(guò)長(zhǎng)，會(huì)帶來(lái)人力審核成本的提升。比如100萬(wàn)個(gè)視頻，每個(gè)平均是30s的話，那么就3000W 秒，大概需要347人日。

通過(guò)技術(shù)手段可以做一些工作，比如：

l 接入一些比較好的第三方的視頻識(shí)別模塊，如果能夠過(guò)濾掉85%保證沒(méi)有問(wèn)題的視頻的話，那么工作量會(huì)縮減到15%。不過(guò)之前在接入使用的時(shí)候，發(fā)現(xiàn)效果沒(méi)有達(dá)到預(yù)期，目前也在逐步嘗試些其他方案。

l 通過(guò)抽幀的方式，比如只抽取某幾幀的方式進(jìn)行檢查。

l 通過(guò)轉(zhuǎn)碼的方式，比如一個(gè)60s的美拍視頻，通過(guò)2倍速的方式，無(wú)聲，140 * 140的分辨率轉(zhuǎn)換，大概大小能夠在650kB左右，這樣加速了播放的過(guò)程的同時(shí)，還能夠減少審核帶寬的消耗，減少了下載過(guò)程。

l 基于大數(shù)據(jù)分析，分析一些高危地帶、用戶畫(huà)像等，然后通過(guò)一些黑名單進(jìn)行一些處理，或者對(duì)于某些潛在高危用戶進(jìn)行完整視頻的審核，而對(duì)于低危用戶進(jìn)行抽幀的方式等等。

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

隨著用戶和訪問(wèn)量的快速增長(zhǎng)，美拍遇到不少的挑戰(zhàn)：

l 性能的挑戰(zhàn)

l 可用性的挑戰(zhàn)

l 突發(fā)熱點(diǎn)的挑戰(zhàn)

l 業(yè)務(wù)頻繁迭代的挑戰(zhàn)

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

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

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

　　分而治之、化繁為簡(jiǎn)

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

服務(wù)之間的交互和通訊，我們主要走了兩種方式：

l 基于http的方式

l 基于config service + rpc的方式

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

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

　　開(kāi)放擴(kuò)展

主要針對(duì)下面幾個(gè)點(diǎn)：

l 代碼功能的可擴(kuò)展性

l 交互協(xié)議的擴(kuò)展性

l 數(shù)據(jù)存儲(chǔ)格式的可擴(kuò)展性

l 應(yīng)用的可擴(kuò)展性

l 資源的可擴(kuò)展性

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

分級(jí)隔離

目前我們主要通過(guò)這幾個(gè)維度進(jìn)行一些隔離：

l 核心和非核心的隔離

l 單一集群的內(nèi)部隔離

l 不同集群的外部物理資源隔離

l 不同集群的外部依賴資源的隔離

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

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

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

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

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

資源冗余

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

容災(zāi)

美拍的容災(zāi)主要分為自身服務(wù)容災(zāi)、CDN容災(zāi)、云存儲(chǔ)容災(zāi)等。

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

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

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

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

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

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

2016年最值得關(guān)注的女性創(chuàng)業(yè)者評(píng)選：尋找女性商業(yè)力量的代表；在全民創(chuàng)業(yè)的熱潮中，她們敢于亮出自己，有想法、有主張，又有執(zhí)行力。