北美网备份站

标题: [转]Instagram 架构分析笔记 [打印本页]
作者: 小灵通    时间: 2015-10-13 14:40
标题: [转]Instagram 架构分析笔记
这是一篇旧文，值得一读， 就转来了：7 R2 M; E) N# X( `

* A/ c8 M2 K$ M$ u2012 年4月10日凌晨消息，Instagram 被 Facebook 以10亿美金收购。团队规模：13 人。
% Z. A% Z9 z+ V2 z: y, f8 j/ x& r1 ^0 L% ^; ~% {' s
Instagram 团队上个月才迎来第 7 名员工，是的，7个人的团队。作为 iPhone 上最火爆的图片类工具，instagram 用户数量已经超过 1400 万，图片数量超过 1.5 亿张。不得不说，这真他妈是个业界奇迹。
$ l! G. i4 W7 D( W4 x+ }9 w4 i% o' D$ z
几天前，只有三个人的 Instagram 工程师团队发布了一篇文章：What Powers Instagram: Hundreds of Instances, Dozens of Technologies，披露了 Instagram 架构的一些信息，足够勾起大多数人的好奇心。读罢做点笔记，各种线索还是有一定参考价值的。能打开原文的建议直接读原文。; c- Q1 U6 o" _' b) \& a4 _

  C1 F( r& L/ e6 EInstragram.png
# a7 }, H( }" C" j- ~& ]
  Q% t8 p$ f; f8 p8 c1 w- h Instagram 开发团队奉行的三个核心原则：
5 ^, T# s% y( Q* [$ Z1 D
: z5 `" o' k3 |; T8 Y/ }    Keep it very simple (极简主义)
! Y5 K4 `& A0 D9 {- Q; o/ M( F     Don't re-invent the wheel (不重复发明轮子)( D# p) D# e8 Z
     Go with proven and solid technologies when you can(能用就用靠谱的技术)" @3 f" H6 o  M

/ j. H' k6 M# G  fOS/主机9 H: I& r; V. t; l

8 D& S. c4 \9 ?8 M- M) b% Q 操作系统的选择，在Amazon EC2上跑 Ubuntu Linux 11.04 (Natty Narwhal) ，这个版本经过验证在 EC2 上够稳定。因为只有三名工程师，只有三名工程师，所以自己部署机器到 IDC 是不靠谱的事情。幸好有亚马逊。
. v4 t+ _/ ?, [9 H/ P8 f* s$ W
; H: e; X5 G# V, W( F0 j4 {5 s3 L 负载均衡
- H# E8 h  c5 Y1 q  ~" l2 x) `2 g$ h6 c
此前曾用过两台 Nginx 做 DNS 轮询承载前端请求，这样做会有副作用，现在已经迁移到Amazon的ELB(Elastic Load Balancer)，起了三个 Nginx 实例，在 ELB 层停掉了 SSL , 以缓解 CPU 压力。DNS 服务使用 Amazon Route53 服务。) c! U1 J5 E+ U

3 F0 X$ C; k  H( |& O 应用服务器: O4 e6 F) u- q/ v
, b; m1 V# Y) b* H" {) E
启用了 25 个 Django 实例，运行在 High-CPU Extra-Large 类型的服务器实例上，之所以用 High-CPU Extra-Large 实例是因为应用请求是 CPU 密集型而非 IO 密集型。
$ n3 I" T- V" y+ e
) _* _9 r( b3 x# j* E4 K 使用 Gunicorn 作为 WSGI 服务器。过去曾用过 Apache 下的 mod_wsgi 模块，不过发现 Gunicorn 更容易配置并且节省 CPU 资源。使用 Fabric 加速部署。6 c( N4 X& g& ^3 y
' X' ^8 i5 Q9 x0 F5 j
数据存储* S' n4 g# Q, N8 {$ A

+ g& O! H  z7 z! o" X- I- L- R 用户信息、图片元数据、标签等大部分数据存储在 PostgreSQL 中。主要的 Shard 数据库集群有 12个节点。+ B! K- o, z/ U7 n% M

; j, D2 R/ M" { 实践中发现 Amazon 的网络磁盘系统单位时间内寻道能力不行，所以有必要将数据尽量放到内存中。创建了软 RAID 以提升 IO 能力，使用的 Mdadm 工具进行 RAID 管理。' }6 v+ _& f, Z+ S* ]( v8 N6 W# ^/ s
1 o  @! U5 P; c, z7 r4 U5 N
管理内存中的数据，vmtouch 这个小工具值得推荐。
/ p0 i9 G! u1 ?, `; [& f; L
2 Q5 r/ N0 Q$ c' t9 d, ^PostgreSQL 设置为 Master-Replica 方式，流复制模式。利用 EBS 的快照进行数据库备份。使用 XFS 文件系统，以便和快照服务充分配合。 使用 repmgr 这个小工具做 PostgreSQL 复制管理器器。( V2 V( X) J: A  k# r& L1 `

& g; \3 F1 @' ]3 X. f, e/ E( r 连接池管理，用了 Pgbouncer。Christophe Pettus 的文章包含了不少 PostgreSQL 数据库的信息。
: G* Z5 x% H1 f( k! U/ B- m  O( ?
( ^1 o0 R) C$ f2 mTB 级别的海量图片存储在 Amazon S3 上，CDN 采用的也是 Amazon 的服务，CloudFront。
2 j8 }, @0 G1 N) T9 Y/ C1 r1 V: k9 P9 T! T* ^7 u2 J
Instagram 也是 Redis 的重度用户，Feed 以及 Session 信息都用 Redis 处理，Redis 也是以 Master-Replica 方式部署。在 Replica 节点上进行数据备份。  O. }, }" P4 n( i  `+ _* k. c6 G0 c
, s8 D4 o  w9 r( }& _  U1 J
使用了 Apache Solr 承担 Geo-search API 的工作，Solr 简单的 JSON 接口也不错。
# Z8 S9 Y+ ^. \) U! w$ Z5 C
0 x  Z& N) T4 s, S; M* R 缓存使用了 6 个 Memcached 实例，库使用 pylibmc 和 libmemcached。亚马逊也提供缓存服务－Elastic Cache service ，Instagram 也有尝试，不过不便宜。
4 G* t# A- a" t. l* t, a9 p% T' S- _+ r: ]/ U$ B5 A
任务队列/发布通知0 b; X+ w. G4 H! f
% U- W8 b# m/ i; h& r7 B: U
队列服务使用 Gearman ，通知系统则使用 pyapns 来实现。" p8 Z( @- b# _4 F9 T% v+ R8 n6 y

4 C+ Y7 k1 w  T 监控
9 J& H: F$ \; [" `2 @
2 o- l# c6 b8 K7 D+ \ 前面提及的服务器实例数量加起来，的确有100多个，有效的监控是相当有必要的。使用 Munin 作为主要监控工具 , 也写了不少定制插件，外部监控用 Pingdom 的服务。通知服务使用PagerDuty。
5 p* g% x6 u5 [& M( r
- G3 g9 H3 f# H( k4 E+ \ 对于 Python 的错误报告，使用 Disqus 团队开源的 Sentry 来处理。
+ P0 g. m+ N. x$ T4 A; Q" s. b: H) M  V. F  q0 I
几个感想& H, P! I( L- J* |4 V

) `! `7 _' H1 G. ^( e6 k* G: [- V0）轻装上阵说起来容易，做起来非常难。这也是 Instagram 团队目前最令人着迷的地方；7 G$ @: ~) m, X  q0 L
9 Y  T1 b0 v+ f( ^
1）Python 社区已经足够成熟，各个环节上都已经有不错的解决方案了。4 X/ E2 u0 p# O( r
$ V$ f/ }: c/ f3 u
2）如果要问我最大的一个感慨，我要说：Amazon 真是一家伟大的公司，甚至比 Google 还伟大' u; s5 {+ q# P. ?$ |6 F! K




欢迎光临 北美网备份站 (http://beimeilife.duckdns.org/) Powered by Discuz! X3.2