存档

文章标签 ‘Python’

Instagram: 2年10亿美元背后的技术架构

2015年7月3日 没有评论

转自:Archfan

参考:Instagram的技术探索

Instagram是一款免费照片分享移动应用,目前支持IOS和Android。在1年多的时间里,Instagram发展到140万个用户,1.5亿张图片(几个TB),仅有3个工程师,以10亿美元的天价被Facebook收购。不得不说,Instagram是业界的一个神话。今天我们就来看看到底是什么样的技术架构支撑着这个10亿美元的公司。

Instagram团队之前发表过一篇文章:What Powers Instagram:Hundreds of Instances,Dozens of Technologies。这篇文章中提到的技术架构堪称经典,很适合初创项目的快速启动。

这个小团队使用了很多不同的技术和策略,保证他们能轻松的应付快速增长带来的压力。他们混合使用SQL、NoSQL,一堆开源项目,和云服务;云服务他们选择了Amazon,他们认为Amazon要比他们自己部署IDC更有优势;用异步队列来串联组件;系统架构在众多的对外API和内部Services之上;数据存储在内存和云端;大部分代码是动态语言;等等等等。非常时髦的一个架构,基于这个架构之上他们得以快速前进,并且保持精简。

那篇文章非常值得一读,有兴趣的同学可以直接看原文。这里我列出一些要点:

  • 架构原则:1.保持简单;2.不重复造轮子;3.尽量使用成熟稳定的技术
  • 3个工程师
  • 大量使用Amazon服务,工程师不用耗费时间自己维护服务器
  • 100+个EC2实例用于各种用途
  • Ubuntu Linux 11.04(“Natty Narwhal”),他们认为这个版本更加稳定
  • Amazon的ELB(Elastic Load Balancer)路由请求,ELB后面起了3个Nginx实例
  • ELB上关闭了SSL,因为它降低了CPU的使用率
  • DNS使用Amazon的Route53
  • 25+个Django应用服务运行在High-CPU Extra-Large类型的机器上
  • CPU使用比内存使用更加容易达到边界值,所以使用High-CPU Extra-Large的实例来平衡内存和CPU
  • Gunicorn是他们的WSGI服务器。Apache更难配置,更耗CPU
  • Fabric被用来在所有机器上并行执行命令。部署花费更少的时间。
  • PostgreSQL(存储用户,照片元数据,标签等)运行在12个Quadruple Extra-Large Memory实例上
  • 12个PostgreSQL副本运行在不同的节点上
  • PostgreSQL的Master-Replica使用流复制模式,利用EBS的快照来频繁备份
  • EBS部署在软件RAID上,使用mdadm以获取适当的IO
  • 将所有工作中的数据集存储在内存中,因为EBS每秒磁盘寻道次数有限
  • Vmtouch(轻量级的文件系统缓存诊断工具)被用来管理内存数据,尤其是当故障转移时目标机器没有足够空余的内存
  • 用XFS做文件系统,保证数据快照时RAID阵列上数据的一致性
  • Pgbouncer用作PostgreSQL的连接池
  • 有几个TB的照片存在Amazon S3上
  • 用Amazon CloudFront做CDN
  • Redis用来支撑feed,活动消息,session系统和其它服务
  • Redis运行在几台Quadruple Extra-Large Memory实例上,偶尔也会做下切分
  • Redis也是Master-Replica,副本持久化到磁盘上,并由EBS通过快照备份(这么搞是因为他们发现直接在Master上做dump相当吃力)
  • Geo-Search使用Solr,Solr提供的JSON接口也很简单易用
  • 6个memcached实例做缓存,因为Amazon Elastic Cache服务并不便宜,mmc客户端使用pylibmc和libmemcached
  • Gearman用做:向Twitter,Facebook等平台异步分享照片;新照片发布的通知;feed的反送
  • 200个Python进程处理Gearman的任务队列
  • Pyapns处理超过10亿条Apple的push通知,异常稳定
  • Munin用做监控和系统度量工具,用Python-Munin写了很多图表插件,如每分钟注册人数,每秒钟图片发表数等等
  • Pingdom做内部服务的监控
  • PagerDuty用来处理通知和事件
  • Sentry用来做Python的错误报告

以上就是Instagram的博文里面提到的技术要点,怎么样,准备好构建下一个10亿美元的应用了么?

Scaling Django Web Apps

2009年8月17日 1 条评论

Django Web Apps 开发者注意了: 伸缩性是大家一定要持续关注的核心问题.

分类: Python 标签: , ,

Python驱动的ERP/CRM解决方案: Open ERP

2009年8月15日 没有评论

Open ERP 使用Python语言开发,数据库采用PostgreSQL,系统以GNU GPL开源协议发布。

系统提供较灵活的模块架构,常用模块包括:采购管理,销售管理,库存管理,财务管理,货品管理,营销管理,客户关系管理,生产管理,人事管理,服务支持等等。用户可以直接从模块库中选择安装适用模块,或进行模块卸载,升级的管理操作。

客户端用户界面是基于GTK的,同时支持Linux和Windows平台。目前还有基于TurboGears的eTiny Web客户端,在后续版本会放弃TurboGears,而采用性能更高的CherryPy3 + Mako

Open ERP 很有创新的项目是 Open Object, 它是一个基于 Python 的企业应用快速开发框架, 这可能是Open ERP最吸引人和最大的亮点。

服务端的 Web Services 设计, 使其支持 SOAP, XML-RPC, NET-RPC , 这样未来能更好的支持 SOA 体系结构。

服务端工作流引擎的提供使其未来对BPM的支持有更多的期待。

看来 Open ERP 未来会朝 SOA + BPM 大踏步迈进, Open ERP + SOA + BPM = Agility Business, Open Business

Open ERP 值得期待 :)

Launchpad.net 公开源代码

2009年7月27日 没有评论

launchpad.net 是一个代码主机托管和软件协作平台,  目前已开放整个平台源代码, 基于AGPLv3许可协议发布.

launchpad.net 基于 Python, Zope, PostgreSQL 构建, 运行在Ubuntu上.

其中, 核心部分使用了 Zope 的 zope.interface 用于Interfaces , zope.component 用于 Adapters 和 Utilities, Storm 用于对象-数据库的ORM.

更多技术细节请访问此PDF文件.

相关链接:

啄木鸟 Python 开源社区的奋起宣言!

2006年5月28日 3 条评论

啄木鸟 Python 开源社区的奋起宣言:

// 每日至少抽一刻钟
解答邮件列表中初学者的问题,
// 每周至少抽两小时
整理新学知识将体验发表/分享出去,
通过Blog/Wiki/BBS/mailist……
// 每旬至少抽四个小时
来翻译自个儿喜爱的自由软件的文档,
// 每月至少抽八小时
快乐的编程,推进自个儿的项目,
// 每年至少参加一次
自由软件的活动,传播自由软件思想,
发展一名“自由人”……只要我们每个人都坚持下去……
10年!就足以改变中国软件的整体风貌!

更多人这样的坚持下去, 中国软件的未来就会更有希望 :)

分类: Python 标签: