https://www.jianshu.com/p/b73dcd2c03e7

本文系麥俊生在BOSS直聘主辦的直聘學(xué)院「對(duì)話架構(gòu)師」活動(dòng)上的精彩分享。

?

一、短視頻市場(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ì)逐步降低用戶使用的門檻；此外，家用帶寬也隨之增加，目前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)降低用戶視頻的制作門檻，比如美拍提供了MV特效等，來(lái)提升了制作視頻的趣味性的同時(shí)，降低使用的門檻。同時(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è)熱門、好友動(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)銷。

美拍對(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ì)，在專門做這種效果算法的優(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ù)手段可以做一些工作，比如：

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

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

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

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

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

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

性能的挑戰(zhàn)

可用性的挑戰(zhàn)

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

業(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ù)之間的交互和通訊，我們主要走了兩種方式：

基于http的方式

基于grpc+etcd的方式

前者使用的方式比較簡(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)：

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

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

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

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

資源的可擴(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)行一些隔離：

核心和非核心的隔離

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

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

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

美拍在發(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)

自身服務(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ù)。基于每天的統(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)解決。

作者：meng_philip123
鏈接：https://www.jianshu.com/p/b73dcd2c03e7
來(lái)源：簡(jiǎn)書(shū)
著作權(quán)歸作者所有。商業(yè)轉(zhuǎn)載請(qǐng)聯(lián)系作者獲得授權(quán)，非商業(yè)轉(zhuǎn)載請(qǐng)注明出處。

轉(zhuǎn)載于:https://www.cnblogs.com/davidwang456/articles/8360155.html

總結(jié)

以上是生活随笔為你收集整理的亿级短视频社交美拍架构实践的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。