優(yōu)化篇-“移動(dòng)端”圖片上傳架構(gòu)的變遷

做互聯(lián)網(wǎng)應(yīng)用少不了圖片的支撐，圖片的上傳、瀏覽速度很大程度上決定著用戶的體驗(yàn)，甚至用戶去留，就因?yàn)槠渲匾?，所以，在任何時(shí)候，圖片的架構(gòu)和優(yōu)化都在進(jìn)行，不敢絲毫放松。

在以后幾個(gè)章節(jié)，會(huì)從后端圖片存儲(chǔ)、前端瀏覽、動(dòng)態(tài)瀏覽這些方面和大家分享一下我們一路過來的經(jīng)驗(yàn)。

經(jīng)過數(shù)據(jù)的觀察，APP、WAP的用戶量基本與PC端持平甚至超越，因此，應(yīng)移動(dòng)端用戶體驗(yàn)和訪問速度都被運(yùn)營方盯得緊緊。在2014年的時(shí)候已經(jīng)看到這個(gè)趨勢(shì)后，主動(dòng)監(jiān)測(cè)發(fā)現(xiàn)移動(dòng)端的跨運(yùn)營商訪問速度和穩(wěn)定性真不敢恭維。所以，在那個(gè)時(shí)候開始，我們已經(jīng)在尋找中國移動(dòng)的機(jī)房資源進(jìn)行部署加速節(jié)點(diǎn)，為移動(dòng)端用戶進(jìn)行加速；接著引入bgp機(jī)房；至此，總算解決了很大程度上用戶瀏覽圖片速度的問題；但在用戶圖片上傳方便還是在不停探索中，以下是一些走過的路子。

富客戶端想法

APP端代碼對(duì)圖片進(jìn)行壓縮、水印、裁剪、縮圖。缺點(diǎn)：耗費(fèi)用戶CPU和流量。這個(gè)方法只是解燃眉之急。

瘦客戶端

APP端對(duì)超一定大小的圖片進(jìn)行壓縮，然后直接上傳，服務(wù)端接收完圖片并做完轉(zhuǎn)圖操作后返回用戶上傳成功狀態(tài)。這方法一直沿用至今。

多點(diǎn)上傳 + 查詢系統(tǒng) + 同步系統(tǒng)

不同的運(yùn)營商用戶上傳圖片到所屬運(yùn)營商網(wǎng)絡(luò)節(jié)點(diǎn)，然后通過內(nèi)部同步系統(tǒng)進(jìn)行圖片資源同步，從而達(dá)到各機(jī)房數(shù)據(jù)的一致性。基于多點(diǎn)上傳會(huì)存在資源短暫不一致情況，（eg：A機(jī)房用戶上傳完并可以瀏覽的時(shí)候，資源還沒同步到其它機(jī)房，那其他機(jī)房的用戶就會(huì)存儲(chǔ)404），我們引入查詢系統(tǒng)。具體架構(gòu)

1.上傳：客戶端調(diào)用上傳接口進(jìn)行圖片上傳。

2.寫入：傳一條記錄到查詢系統(tǒng)中，該信息會(huì)在各機(jī)房的查詢系統(tǒng)共享，同步系統(tǒng)發(fā)現(xiàn)新文件后也會(huì)自動(dòng)執(zhí)行同步任務(wù)。

404：瀏覽用戶通過瀏覽系統(tǒng)進(jìn)行瀏覽圖片，當(dāng)發(fā)現(xiàn)本地圖片404后，會(huì)拿查詢系統(tǒng)信息，能得到對(duì)應(yīng)信息則能正常返回用戶圖片。

瘦客戶端 + 分片

隨著圖片和手機(jī)性能的提升，圖片大小大幅提升，但手機(jī)網(wǎng)絡(luò)的不穩(wěn)定性還是很普遍的情況，針對(duì)這情況，在原有的基礎(chǔ)上我們加入分片，把一張圖片分成若干的小片，然后再上傳，最后在服務(wù)端合并。

經(jīng)過幾輪的折騰，看數(shù)據(jù)情況可以。

我們想著能頂個(gè)一段時(shí)間，大概過了一年半，運(yùn)營報(bào)障有網(wǎng)友反饋慢。

在app中進(jìn)行埋點(diǎn)收集用戶數(shù)據(jù)；結(jié)合數(shù)據(jù)初步判斷，發(fā)現(xiàn)主要兩個(gè)問題：1.服務(wù)端轉(zhuǎn)圖慢，因?yàn)榻?jīng)過一定時(shí)間的業(yè)務(wù)發(fā)現(xiàn)，需要轉(zhuǎn)的圖片種類越來越多。2.移動(dòng)網(wǎng)絡(luò)地域之間，網(wǎng)友移動(dòng)網(wǎng)絡(luò)到我們移動(dòng)網(wǎng)絡(luò)機(jī)房之間都存在慢的情況（歸納到同運(yùn)營商間的地域問題）。

解決問題一：實(shí)時(shí)轉(zhuǎn)圖系統(tǒng)的引入（后面介紹）。

解決問題二：1.自建，投入更多的資金建立上傳邊緣節(jié)點(diǎn)。2.利用現(xiàn)有的圖片云服務(wù)，公有云能提供更多地區(qū)地就近接入，上傳邊緣節(jié)點(diǎn)。經(jīng)過評(píng)估我們嘗試走圖片云服務(wù)。

測(cè)試對(duì)象：

1. 七牛；2.阿里云；3.騰訊云。（云對(duì)象存儲(chǔ)服務(wù)）

2. 
   

調(diào)研后，其實(shí)三大廠家提供的api接口和功能組成差不多，今次選擇主要是根據(jù)技術(shù)支持服務(wù)決定，選用七牛為主，阿里云為輔助（如果七牛整個(gè)掛了，上傳服務(wù)自動(dòng)轉(zhuǎn)移阿里云）。

引入云圖片服務(wù)后架構(gòu)變?yōu)椋?/p>

上傳的流程

1.APP向“UPC云“（是我們內(nèi)部的一個(gè)上傳認(rèn)證系統(tǒng)）申請(qǐng)上傳的身份驗(yàn)證，帶著身份信息向云端上傳圖片。

2.通知后端需要進(jìn)行資源的同步和實(shí)時(shí)轉(zhuǎn)圖的格式。

3.向資源同步系統(tǒng)中傳遞信息導(dǎo)（異步）。

瀏覽的流程

（因?yàn)槲覀冇凶约?a title="cdn" target="_blank" href="http://www.kemok4.com/cdn/">cdn，另外和cdn廠商合作非常順利，從成本考慮，我們還是保留出圖走自己的cdn或cdn廠商）

4.用戶查詢請(qǐng)求先到cdn。

5.cdn 404回源請(qǐng)求。

6.img前端（圖片瀏覽服務(wù)）如果不存在該圖片，則把請(qǐng)求派送到云資源同步系統(tǒng)中。

7.云資源同步系統(tǒng)的前端nginx（內(nèi)嵌了一段代碼），進(jìn)行資源查找，如果資源還沒到本地機(jī)房，則進(jìn)行對(duì)云資源請(qǐng)求按邏輯轉(zhuǎn)化，然后進(jìn)行請(qǐng)求，最后把獲取的圖片資源返回給img前端，同時(shí)把同步任務(wù)發(fā)送到云資源同步系統(tǒng)內(nèi)的同步功能模塊。

通過線上實(shí)踐，這種方式又比原來方式穩(wěn)定和提速不少。

以上只是結(jié)合實(shí)際需求產(chǎn)生出的上傳體系，歡迎大家指出錯(cuò)誤。

更多信息請(qǐng)關(guān)注微信訂閱號(hào)：輕量運(yùn)維