类INSTAGRAM服务的技术架构思考

类 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 封锁的账户，客户端需要翻墙才能够同步结论：不采纳客户端同步方式。客户端将相关请求传递给服务器，由服务器端来完成同步操作。2、由于类 Instagram 服务，图片是主要内容形式。因此需要重点考虑图片服务器的架构，尤其是海量图片的情况。比较现实的方案可以参考图片服务器选型方案 ，理想的方案可以参考借鉴 Facebook 的 haystack 。 另外由于涉及大量的缩略图处理，可以采纳 Gearman 分布式计算框架+GraphicsMagick 来做缩略图的处理。 3、由于涉及与相关 SNS 社区接口服务的同步，为保证系统的性能，应当将同步服务与核心服务分离开，核心服务在接收到客户端请求后，将需要同步的数据通过消息队列方式传递给同步服务器，由同步服务器异步完成相关接口服务的同步。 4、由于是内容导向的服务，因此可以采纳 Redis 等 NOSQL 来存放 oAuth Access Token、微博、用户注册信息等需要持久化的数据 5、翻墙问题 由于这些服务一般都提供与现有各种 SNS 社区服务同步的功能。在技术上相...