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

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

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

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

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

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

????? 除oAuth接口之外的接口如果采用客戶端同步的一些問題：
??????? 1）、如果要同步的SNS社區多，則客戶端要針對不同的SNS社區同步，效率不高，尤其是要占用較大的帶寬流量
??????? 2）、如果SNS社區的接口稍有變動，需要客戶端升級，很麻煩
??????? 3）、對Twitter這樣被G.F.W封鎖的賬戶，客戶端需要Fangqiang才能夠同步???????
??????? 結論：不采用客戶端同步方式。客戶端將相關請求傳遞給服務器，由服務器端來完成同步操作。
?? 2、由于類Instagram服務，圖片是主要內容形式。因此需要重點考慮圖片服務器的架構，尤其是海量圖片的情況。比較現實的方案可以參考 圖片服務器選型方案 ，理想的方案可以參考借鑒 Facebook的haystack 。

??? 另外由于涉及大量的縮略圖處理，可以采用Gearman分布式計算框架+GraphicsMagick來做縮略圖的處理。

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

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

?? 5、fang qiang問題

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

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

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

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

???? 客戶端對諸如照片預處理（例如適當降低分辨率）、多線程并發分片傳輸、斷點續傳處理；

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

???? 客戶端并發請求圖片服務器、業務服務器（不同域名），提高并發處理效率

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

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

類Instagram服務的技術架構思考