優化篇-“移動端”圖片上傳架構的變遷

做互聯網應用少不了圖片的支撐，圖片的上傳、瀏覽速度很大程度上決定著用戶的體驗，甚至用戶去留，就因為其重要，所以，在任何時候，圖片的架構和優化都在進行，不敢絲毫放松。

在以后幾個章節，會從后端圖片存儲、前端瀏覽、動態瀏覽這些方面和大家分享一下我們一路過來的經驗。

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

富客戶端想法

APP端代碼對圖片進行壓縮、水印、裁剪、縮圖。缺點：耗費用戶CPU和流量。這個方法只是解燃眉之急。

瘦客戶端

APP端對超一定大小的圖片進行壓縮，然后直接上傳，服務端接收完圖片并做完轉圖操作后返回用戶上傳成功狀態。這方法一直沿用至今。

多點上傳 + 查詢系統 + 同步系統

不同的運營商用戶上傳圖片到所屬運營商網絡節點，然后通過內部同步系統進行圖片資源同步，從而達到各機房數據的一致性。基于多點上傳會存在資源短暫不一致情況，（eg：A機房用戶上傳完并可以瀏覽的時候，資源還沒同步到其它機房，那其他機房的用戶就會存儲404），我們引入查詢系統。具體架構

1.上傳：客戶端調用上傳接口進行圖片上傳。

2.寫入：傳一條記錄到查詢系統中，該信息會在各機房的查詢系統共享，同步系統發現新文件后也會自動執行同步任務。

404：瀏覽用戶通過瀏覽系統進行瀏覽圖片，當發現本地圖片404后，會拿查詢系統信息，能得到對應信息則能正常返回用戶圖片。

瘦客戶端 + 分片

隨著圖片和手機性能的提升，圖片大小大幅提升，但手機網絡的不穩定性還是很普遍的情況，針對這情況，在原有的基礎上我們加入分片，把一張圖片分成若干的小片，然后再上傳，最后在服務端合并。

經過幾輪的折騰，看數據情況可以。

我們想著能頂個一段時間，大概過了一年半，運營報障有網友反饋慢。

在app中進行埋點收集用戶數據；結合數據初步判斷，發現主要兩個問題：1.服務端轉圖慢，因為經過一定時間的業務發現，需要轉的圖片種類越來越多。2.移動網絡地域之間，網友移動網絡到我們移動網絡機房之間都存在慢的情況（歸納到同運營商間的地域問題）。

解決問題一：實時轉圖系統的引入（后面介紹）。

解決問題二：1.自建，投入更多的資金建立上傳邊緣節點。2.利用現有的圖片云服務，公有云能提供更多地區地就近接入，上傳邊緣節點。經過評估我們嘗試走圖片云服務。

測試對象：

1. 七牛；2.阿里云；3.騰訊云。（云對象存儲服務）

2. 
   

調研后，其實三大廠家提供的api接口和功能組成差不多，今次選擇主要是根據技術支持服務決定，選用七牛為主，阿里云為輔助（如果七牛整個掛了，上傳服務自動轉移阿里云）。

引入云圖片服務后架構變為：

上傳的流程

1.APP向“UPC云“（是我們內部的一個上傳認證系統）申請上傳的身份驗證，帶著身份信息向云端上傳圖片。

2.通知后端需要進行資源的同步和實時轉圖的格式。

3.向資源同步系統中傳遞信息導（異步）。

瀏覽的流程

（因為我們有自己cdn，另外和cdn廠商合作非常順利，從成本考慮，我們還是保留出圖走自己的cdn或cdn廠商）

4.用戶查詢請求先到cdn。

5.cdn 404回源請求。

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

7.云資源同步系統的前端nginx（內嵌了一段代碼），進行資源查找，如果資源還沒到本地機房，則進行對云資源請求按邏輯轉化，然后進行請求，最后把獲取的圖片資源返回給img前端，同時把同步任務發送到云資源同步系統內的同步功能模塊。

通過線上實踐，這種方式又比原來方式穩定和提速不少。

以上只是結合實際需求產生出的上傳體系，歡迎大家指出錯誤。

更多信息請關注微信訂閱號：輕量運維