Tag Archives: Arch

Instagram 架构分析笔记

Updated: 2012 年4月10日凌晨消息，Instagram 被 Facebook 以10亿美金收购。团队规模：13 人。

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 还伟大。

–EOF–

Get Architecture Done -《分布式Java应用：基础与实践》

按：承蒙林昊( @Bluedavy )看得起，嘱托我为他的大作《分布式Java应用：基础与实践》写序，倍感荣幸之余也颇有压力。读完本书的绝大部分章节后，这相信这会是我今年要向朋友们推荐的关于架构的图书。毕竟我在阿里系工作有年，对几家子公司的技术还算有所了解，内容有没有料还是可以一目了然的分辨的出来的。下文是推荐序。

提起诸如”高性能”、”高可用”、”大规模并发”、”可扩展性”这些词汇，我相信多数技术人的心情都是激动而稍有点复杂的，当然，也或许是不屑一顾。毕竟不是谁都有机会面对这些富有挑战的技术场景，也不是每个架构师在面对这些挑战之前都能做好技术上的准备。那些意外故障总是不期而至，疲于奔命的解决问题的场景回顾起来对架构师来说犹如一场噩梦。

本书阐述当一个面向数以亿计用户的网站经过几年高速发展，技术团队不得不面临大规模、高并发、高扩展性等挑战带来的技术困境的时候，一个出色的架构师经过多年一线实践后累积的经过时间考验的解决方案以及宝贵的实战经验。在这本书里，你会看到作者在解决一些关乎Web应用问题的指导原则、实践方法、多重工具的综合运用以及作者本人的感悟。要强调的是，本书讲述的内容是一个Web应用从小到大过程中遇到的棘手问题的解决之道，并非宏观解析，亦非屠龙之技。无论您面对的站点是大是小，皆会有参考作用，毕竟大站点会越来越复杂，而小站点总有一天也将变大。

如今到计算机书店里走一下，会发现Java架构相关的技术图书业已不少，但仍有理由相信本书内容填补了在Java架构实战方面的空白。在互联网应用大行其道的今天，有些名义上主题为Java架构的图书，要么单从Java本身阐述，缺乏整体应用的大局观；要么是高屋建瓴，从编程思想的高度坐而论道，缺乏实践性；要么是闭门造车之作，缺乏验证性。本书作者林昊多年来致力于推动OSGi在国内的发展，不乏理论技术功底，而后加盟淘宝网 (Taobao.com)的几年间奋战在架构一线，爬摸滚打积累了丰富的实践心得。所以，本书是一本不折不扣的”理论结合实践“之作。

考虑国内的技术图书出版环境以及必须尽力迎合读者的预期，写书本身是一件费力不讨好的事情，但将知识传递给更多人无疑是让人快乐的。现在，经过作者近两年的梳理与总结，这本书即将出版，相信您在研读本书之后有所收获并运用到您所面对的Web应用上，也期待将来有更多朋友能够分享架构实践经验，不亦快哉！

–EOF–
　　

从 Reddit 学到的经验

最近有一些比较有价值的文章似乎没引起太多人注意，比如 Steve Huffman 分享创建 Reddit 过程中的经验这篇文章，在 Twitter 上的中文技术圈子似乎没有被提及。 150px-Reddit_logo.svg.png

作为社会化新闻站点，国内似乎关注 Reddit 的人并不多，我只知道少数 Geek 是其死忠粉丝。Reddit 在 2005 年 6 月由 Steve Huffman 与 Alexis Ohanian 创建，之后在 2007 年被 Condé Nast 收购。到现在看 Alexa 排名在 300 名之内。

根据维基百科的介绍(refer)：Reddit 最早是用 Common Lisp 开发，随之用 Python 进行了重写(2005年底完成)。著名的Python 框架 Web.py 就是 Reddit 当时的员工 Aaron Swartz 开发的，现在 Reddit 的 Web 框架则使用了 Pylons 。在 2009 年 11 月，Reddit 迁移到 Amazon 的云计算平台。前端框架现在用的是 jQuery。或许你早就知道，Reddit 网站程序现在已经开源，如果你感兴趣的话，不妨下载研究。

严格来说，Steve 的这个演讲其实并没有涉及多深入的技术信息，只是这几条经验的确可以作为通用规则与大家分享。

宕机是家常便饭(Crash Often)
可能很多人会认为一些 Startup 的创建人都是天才，其实也未必。两个22岁的初出茅庐的大学毕业生写的程序会好到哪里？网站起步的时候，频繁的宕机让他们吃尽了苦头。其实 Twitter 以及最近热火的 FourSquare 在初期的稳定性也不怎么样，但是仍然能对用户产生足够的吸引力。这是很多创业者需要细思量之处。
服务分离( Separation of Services)
现在已经超过 20 台数据库，每个数据库只处理一种特定类型的数据，原因无他，更为简化。另外，Reddit 得到的一个经验是不要使用 Python 的线程，而是用多进程的方式。
开放 Schema（Open Schema）
个人觉得，应该叫 Key-Value 更恰当。
无状态处理请求(Keep it Stateless)
“无状态”意味着横向扩展更为容易。单节点服务器向多台扩展，或许这是第一个要考虑的问题。否则，背的包袱就会越来越重。
Memcached
除了尽可能的利用 Memcached 加速用户对数据的访问速度，在 Memcached 中存储了大量预生成的页面内容，另外，也在适当的场景使用了 MemcacheDB 以满足数据持久化的需要。
存储冗余数据（Store Redundant Data）
让站点变得更慢的一个”好办法”就是遵循范式设计数据库。除了在 RDBMS 中存储数据外，在上一条提到的 MemcacheDB 中也存储了大量数据，和收益相比，冗余的成本并不高。前提是数据一致性要能得到有效保证。
脱机工作(Work Offline)
尽可能的异步处理用户操作，对计算量比较大的功能利用离线计算的模式。消息队列用用 RabbitMQ(Rabbit Technologies Ltd.已经被 SpringSource 收购) ，采用了 AMQP 协议。

或许还有意犹未尽之处，各位自己顺着文章来源分析吧。Reddit 就像一个技术标本，仔细琢磨下去还会有很多有趣的地方，相信也会对你有帮助。

–EOF–

编程语言的选择并非无关紧要

且说前一段时间听淘宝的黄裳讲解淘宝网站架构发展的时候，说起 2004 年底淘宝为何从 PHP 向 Java 转移的事情。为何转换，他阐述了几个理由，其中一个是非常有趣的：当时的 PHP 缺少一个 IDE。而合适的 IDE 能够有效提升规模化软件开发的效率。

我们知道 eBay 在 2002 年的时候也在 Sun 技术团队的帮助下，将整个应用架构从 C++ 迁移到 J2EE 。也就是 eBay 内部所说的 V3 版本(refer)。

最近一件有趣的事情是，据说腾讯的财付通在招聘 Java 方面的高手，”参与系统架构选型”，要把底层架构从 C/C++ 迁移到 Java 架构上来。另外，百付宝的后台技术据说也是基于 C++ 的(最开始的时候只是一两个人写核心代码）。我相信，现在百付宝或许规模还比较小，总有一天，也要面临向 Java 的迁移。这和阿姆达尔定律有点类似，要得到更大的计算能力，就要尽量减少整个系统中的非并行的环节。只是一两个人能搞定的地方，再加入更多的开发人员也是无济于事的，除非，改变协作的模式。

去年接触到的一些国内的电子商务公司，有些已经在进行技术架构上的变迁，当然，多数是从 Windows 平台迁移到 LAMP 平台，究其原因，也无非是成本与效率，而后者，更为大家所看重。当然，也有一些顽固派，比如京东，仍然固守原来的手工作坊技术模式。

如果单兵作战的话，很多程序高手会说，”用什么语言都是无所谓的”。但是如果是团队协作开发的话，用什么语言，影响则是不一样的。对于电子商务网站来说，语言的选择意味着不同的架构路线、不同的开发框架、不同的测试框架、不同的部署流程，最后更为主要的是不同的开发效率，意味着可以把更多的开发资源并入到当前的环节中。

事实上，对于一个高速发展中的网站，每隔18 或 36 个月，几乎总要有一次架构上变革的阵痛。没有这种变革的勇气，意味着以后也不会有人敢做这个尝试。没有这种阵痛，就不会有成长。

变化的节奏最后影响一切。编程语言的选择并非无关紧要，短期看来似乎影响不大，从长期来看，决定最终的竞争结果。这就是我要说的。

–EOF–