类Instagram服务的技术架构思考

    当下移动互联网照片分享及轻博客类服务极度红火。类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协议。