作者：冯大辉
Instagram 团队上个月才迎来第 7 名员工，是的，7个人的团队。作为 iPhone 上最火爆的图片类工具，instagram 用户数量已经超过 1400 万，图片数量超过 1.5 亿张。不得不说，这真他妈是个业界奇迹。
几天前，只有三个人的 Instagram 工程师团队发布了一篇文章：What Powers Instagram: Hundreds of Instances, Dozens of Technologies，披露了 Instagram 架构的一些信息，足够勾起大多数人的好奇心。读罢做点笔记，各种线索还是有一定参考价值的。能打开原文的建议直接读原文。
Instagram 开发团队奉行的三个核心原则：
- Keep it very simple (极简主义)
- Don’t re-invent the wheel (不重复发明轮子)
- Go with proven and solid technologies when you can(能用就用靠谱的技术)
OS/主机
操作系统的选择，在Amazon EC2上跑 Ubuntu Linux 11.04 (Natty Narwhal) ，这个版本经过验证在 EC2 上够稳定。因为只有三名工程师，只有三名工程师，所以自己部署机器到 IDC 是不靠谱的事情。幸好有亚马逊。
负载均衡
此前曾用过两台 Nginx 做 DNS 轮询承载前端请求，这样做会有副作用，现在已经迁移到Amazon的ELB(Elastic Load Balancer)，起了三个 Nginx 实例，在 ELB 层停掉了 SSL , 以缓解 CPU 压力。DNS 服务使用 Amazon Route53 服务。
应用服务器
启用了 25 个 Django 实例，运行在 High-CPU Extra-Large 类型的服务器实例上，之所以用 High-CPU Extra-Large 实例是因为应用请求是 CPU 密集型而非 IO 密集型。
使用 Gunicorn 作为 WSGI 服务器。过去曾用过 Apache 下的 mod_wsgi 模块，不过发现 Gunicorn 更容易配置并且节省 CPU 资源。使用 Fabric 加速部署。
数据存储
用户信息、图片元数据、标签等大部分数据存储在 PostgreSQL 中。主要的 Shard 数据库集群有 12个节点。
实践中发现 Amazon 的网络磁盘系统单位时间内寻道能力不行，所以有必要将数据尽量放到内存中。创建了软 RAID 以提升 IO 能力，使用的 Mdadm 工具进行 RAID 管理。
管理内存中的数据，vmtouch 这个小工具值得推荐。
PostgreSQL 设置为 Master-Replica 方式，流复制模式。利用 EBS 的快照进行数据库备份。使用 XFS 文件系统，以便和快照服务充分配合。 使用 repmgr 这个小工具做 PostgreSQL 复制管理器器。
连接池管理，用了 Pgbouncer。Christophe Pettus 的文章包含了不少 PostgreSQL 数据库的信息。
TB 级别的海量图片存储在 Amazon S3 上，CDN 采用的也是 Amazon 的服务，CloudFront。
Instagram 也是 Redis 的重度用户，Feed 以及 Session 信息都用 Redis 处理，Redis 也是以 Master-Replica 方式部署。在 Replica 节点上进行数据备份。
使用了 Apache Solr 承担 Geo-search API 的工作，Solr 简单的 JSON 接口也不错。
缓存使用了 6 个 Memcached 实例，库使用 pylibmc 和 libmemcached。亚马逊也提供缓存服务－Elastic Cache service ，Instagram 也有尝试，不过不便宜。
任务队列/发布通知
队列服务使用 Gearman ，通知系统则使用 pyapns 来实现。
监控
前面提及的服务器实例数量加起来，的确有100多个，有效的监控是相当有必要的。使用 Munin 作为主要监控工具 , 也写了不少定制插件，外部监控用 Pingdom 的服务。通知服务使用 PagerDuty。
对于 Python 的错误报告，使用 Disqus 团队开源的 Sentry 来处理。
几个感想
0）轻装上阵说起来容易，做起来非常难。这也是 Instagram 团队目前最令人着迷的地方；
1）Python 社区已经足够成熟，各个环节上都已经有不错的解决方案了。
2）如果要问我最大的一个感慨，我要说：Amazon 真是一家伟大的公司，甚至比 Google 还伟大。
