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亿美元买到了什么……