類INSTAGRAM服務的技術架構思考

當下移動互聯網照片分享及輕博客類服務極度紅火。類Instagram的照片分享服務,國外的服務包括Instagram、Color、Path、Picplz、Foodspotting等;國內的類Instagram包括推圖、圖釘、隨拍、丁仔、樂麼樂麼、冒泡拍拍等。而國外的輕博客類服務包括Tumblr、Zpad、Posterous等,國內的輕薄博客服務包括點點、推他等。

除了對這些服務的產品及業務模式感興趣外,對後端的技術架構也很感興趣。只不過即使像highscalability.com這樣專注架構的網站對於此類新服務的技術架構似乎沒有太多的描述,沒有太多可以參考的。

此類服務在技術上主要涉及海量照片處理、客戶端與服務器端通信、與其他服務同步等,簡單畫個系統部署架構圖。

instagram,技術架構,移動互聯網

從技術架構角度來看,這些服務需要處理如下一些典型技術挑戰:

1、與其他SNS社區服務同步是採用客戶端同步還是服務器端同步?

由於現在Basic認證接口逐漸被淘汰掉,像Twitter、新浪微博等大部分服務基本都採用oAuth接口,需要客戶端主動發起授權操作,不能由服務器端發起。

除oAuth接口之外的接口如果採用客戶端同步的一些問題:

1)、如果要同步的SNS社區多,則客戶端要針對不同的SNS社區同步,效率不高,尤其是要佔用較大的帶寬流量

2)、如果SNS社區的接口稍有變動,需要客戶端升級,很麻煩

3)、對Twitter這樣被GFW封鎖的賬戶,客戶端需要翻牆才能夠同步

結論:不採用客戶端同步方式。客戶端將相關請求傳遞給服務器,由服務器端來完成同步操作。

2、由於類Instagram服務,圖片是主要內容形式。因此需要重點考慮圖片服務器的架構,尤其是海量圖片的情況。比較現實的方案可以參考圖片服務器選型方案,理想的方案可以參考借鑒Facebook的haystack

另外由於涉及大量的縮略圖處理,可以採用Gearman分佈式計算框架+GraphicsMagick來做縮略圖的處理。

3、由於涉及與相關SNS社區接口服務的同步,為保證系統的性能,應當將同步服務與核心服務分離開,核心服務在接收到客戶端請求後,將需要同步的數據通過消息隊列方式傳遞給同步服務器,由同步服務器異步完成相關接口服務的同步。

4、由於是內容導向的服務,因此可以採用Redis等NOSQL來存放oAuth Access Token、微博、用戶註冊信息等需要持久化的數據

5、翻牆問題

由於這些服務一般都提供與現有各種SNS社區服務同步的功能。在技​​術上相對容易,只需要一個一個搞定各服務提供商所提供的接口,即使現成的接口不完善,也可以通過抓接口報文模擬搞定。

但如果需要將用戶上傳的圖片與Twitter、Facebook等國外服務的賬號同步,由於這些服務被牆掉了,如果服務器本身放在國內,可以在國外放一台同步代理服務器來與國內服務器同步,然後由這台服務器完成與國外服務的同步。如果服務器放在國外,倒是相對省心,但也要考慮在服務有點知名度後,服務本身被牆掉的可能性。

6、客戶端與服務器端間通信相關技術實現

客戶端與服務器端的通信協議數據壓縮傳輸;

客戶端對諸如照片預處理(例如適當降低分辨率)、多線程並發分片傳輸、斷點續傳處理;

客戶端本地存儲、緩存,對離線狀態下編輯數據與服務器端同步處理問題;

客戶端並發請求圖片服務器、業務服務器(不同域名),提高並發處理效率

7、搜索引擎服務除了要對文本內容搜索外,還涉及地理位置信息的搜索、實時搜索問題,而Lucene和Solr對此支持相對於Sphinx等搜索引擎更好,因此採用Solr或Lucene。

服務本身如果要對外提供接口服務,倒是可以考慮PubSubHubBub協議。

來源:http://www.yeeach.com

特別注意:本站所有轉載文章言論不代表本站觀點,本站所提供的攝影照片,插畫,設計作品,如需使用,請與原作者聯繫,文章轉自alibuybuy

Comments are closed.