这几天的媒体充斥着Facebook十亿美元收购Instagram的消息，Facebook究竟买了些什么?几千万的用户?以及不断流行的图片分享习惯?13人的团队?或者消灭了一个潜在的竞争对手(如果被Google收购，那是Facebook最不愿意看到的)?除了这些，还有什么，这就是你阅读这篇文章的价值所在。来自highscalability的文章对 Instagram的架构列出了详细清单，CSDN对其做了编译，我们也非常希望国内的公司和团队多做类似分享，贡献于社区的同时，更能提升自身的江湖地位，对招聘、业务发展都好处多多。欢迎通过@CSDN云计算的微博向我们投稿。
Instagram是一个在iPhone上基于社交网络的图片分享服务，创立之初的一年多时间就吸引了1400万用户，目前已经用户达到3000万。截至到去年八月，Instagram上总共有1.5亿张图片，所有的数据都建立在Amazon stack上。
Instagram的团队曾经撰文《Instagram：数百的实例大量的技术》披露了其架构。
Instagram混杂了不同的技术和策略。团队虽然很小，但经验快速增长让他们赶上了社交和移动互联网大潮。他们采用了混合的SQL和 NoSQL技术，这里有大量的开源项目，并选择了云服务，Amazon的服务提供了很高的杠杆率，这比他们自己建设要高的多，可靠性完全可用，按时间顺序异步的将组件链接起来，系统包含了足够多的服务，包括API和外部服务，这些都不用工程师重新开发。数据保存在内存中和云端，多数代码为动态语言，从新开发的后台传输服务将所有服务链接在一起，代码更新很快并保持简短。一个非常现代的架构。
我们将Instagram的详细架构列在这里，总结很到位，很有价值。以下是所有要点：
Instagram告诉我们：1)保持简单 2)利用现成的一切 3)采用被证明稳定成熟的技术
3名工程师(最新的报道称已经增加到13名，这只是暂时的数据)
Amazon商店。他们采用了大量Amazon的服务。曾经只有3名工程师，你可以想象他们根本没有时间照看服务器。
超过100个Amazon EC2实例，用于各种目的。
Ubuntu Linux 11.04(“敏捷独角鲸”)。非常稳定，其它版本的Ubuntu也包含在其中。
Amazon的Elastic Load Balancer路由请求服务以及背后的3个nginx接口
安全套接层在Elastic Load Balancer终止，可减少nginx占用的CPU资源
DNS采用Amazon Route53
超过25个Django应用服务器，集成在高性能CPU和超大号的机器上
通信对CPU的要求比内存的要求高，因此高性能CPU的大型机器带来更好的平衡
网关接口采用Gunicorn。Apache调试更困难而且对CPU要求更高。
Fabric用于输入所有机器控制指令。部署任务只需要以秒计。
PostgreSQL(用于存储用户信息、图片说明，tag以及其它)数据库，运行在12个四重超大内存的机器上。
12个PostgreSQL的备份
PostgreSQL的主镜像通过复制分发内容。Amazon EBS提供快照服务，并频繁的备份。
Amazon EBS配置了软件RAID。使用mdadm命令获得适当的I/O
所有这些工作存储在内存中。Amazon EBS不能提供足够高的磁盘寻址服务。
Vmtouch命令(文件系统缓存诊断)用于内存中的数据，特别是当数据从一台机器传输到另一台机器失败的时候
采用XFS文件系统。保证快照的一致性。
Pgbouncer用于连接池链接到PostgreSQL
数TB的图片存储在Amazon S3上
CDN服务采用Amazon CloudFront
Redis提供feed、进程和其它服务支持
Redis运行在几个四重超大内存机器上。
Redis运行在主镜像上，副本不断的存储在磁盘上。Amazon EBS备份数据库倾倒的信息。在主镜像上备份十分困难。
Apache的Solr提供geo-search的API。就像一个JSON的接口。
6个内存缓存实例，通过pylibmc和libmemcached链接。Amazon Elastic Cache并不便宜。
Gearman用于：异步的将图片分享到Twitter、Facebook及其它网站;实时的发布订阅者的新图片;
200个Python工作分派任务进入Gearman的任务队列
Pyapns(Apple通知服务)控制上十亿的通知发布，岩石般的稳定。
Munin绘制系统警报图表，开发了许多定制插件用于Python-Munin绘图，包括每秒的注册数、每秒图片发送数等等
Pingdom用于服务的外部监控
PagerDuty控制通知和事件。
Sentry用于Python的错误报告
现在，你终于知道了10亿美元买到了什么……
相关阅读：
