三个中国程序员 vs三个美国程序员,不得不承认,差距太大了!

开发 前端
国内市场也没有很好的云服务作为基础设施,当时李彦宏表示,云计算只不过是新瓶装旧酒,15年来没有新东西,马化腾则认为云计算要像水电一样用还为时尚早。

大概是2009年,我和两个好哥们聊天,觉得智能手机可能是风口,商量着要弄一个照片分享网站。

用户可以用手机把随手拍的照片放到网上分享,名称都起好了,叫InstantPost。

可是我们的执行力太差了,聚了两次,做了一点儿技术验证,就没有下文了。

过了几年,我看到美国一个叫Instagram的火了,不由地一拍大腿:卧槽!这不就是我们当年要做的事儿吗?!

图片图片

后来我看到Instagram初期的故事,他们也是三个程序员,从2010年10月到2011年12月,在一年多的时间内,就把用户数量从0增长到了1400万!

看完他们的架构设计,我就释然了,抛开执行力,在2009年那个时间点,我们确实不行。

Instagram制定的架构指导准则是:

1.保持简单

2.不要重新发明轮子

3.尽可能使用经过验证的可靠技术

所以早期的Instagram跑在云上,使用EC2和Ubuntu Linux 11.04(“Natty Narwhal”)。

接下来,站在一个用户会话(Session)的角度,来看看Instagram的处理过程。

前端

Session:用户打开了Instagram APP。

2010年,Instagram开发了一个iOS app,正式推出。

因为这时候Swift还没有发布,他们用了Objective-C,UIKit等技术。

图片图片

负载均衡

Session:打开App后,会向后端发起一个请求(获取主界面的“信息流”),这个请求会首先到达Instagram的负载均衡。

Instagram 最早使用2个Nginx并在它们之间进行DNS Round-Robin,这种方法的缺点是,如果某一个机器出现故障,DNS的更新需要时间。

后来他们选择了Amazon的Elastic Load Balancer,这里有三个NGINX实例,可以换入换出。

图片图片

后端

Session:负载均衡会把请求转发给应用服务器

Instagram用Django作为后端服务,运行在 Amazon High-CPU Extra-Large 上,因为这三个程序员发现,后端服务是CPU密集型的。

用Gunicorn做WSGI Server。

图片图片

应用运行在超过25台亚马逊虚拟机中,这些应用都是无状态的,可以在需要的时候进行扩展。

为了在多台机器上运行命令(例如部署代码),Instagram使用了Fabric,它有一个很好用的并行模式,部署只需要几秒钟。

数据存储

Session: 用户请求到达了应用服务器,接下来它需要获得这些数据:

1.最新的Photo IDs

2.这些Photo ID对应的实际照片

3.这些照片的用户数据

Database: PostgreSQL

Session: 应用服务器从PostgreSQL获取最新的Photo ID,这里保存着用户和照片的元数据。

大部分的数据,如用户,照片元数据,标签等都保存在PostgreSQL数据库中。

因为数据量不小,每秒钟有25个照片上传,并且有90个赞,Instagram对数据做了分片。

分片系统由数千个逻辑分片组成,这些分片在代码中被映射到少得多的物理分片,用这种办法,可以从少量的数据库开始,扩展到更多的数据库。

当扩展时,只需要把逻辑分片从一个数据库“指向”另外一个即可,无需挪动任何数据。

一个挑战是:Instagram如何解决Photo ID问题,因为需要能按时间排序,而无需获得有关照片的更多信息,理想情况下,ID应该是64位的。

后来的解决方案是这样的:

41位:记录毫秒时间

13位:逻辑分片ID

10位:自动增长的序列,模数1024,这意味着每毫秒,每个分片可以生成1024个ID

最终结果是个64为整数,可以被PostgreSQL排序,找到最新的照片。

照片的存储:S3 和Cloudfront

Session: 获取了Photo ID以后,应用服务器要获取真正的照片,快速发给用户

照片保存在Amazon S3中 ,存储了几个TB的数据,通过使用CDN(Amazon CloudFront ),照片可以快速分发给世界各地的用户(例如日本,是Instagram第二大受欢迎的国家)

缓存

Instagram 需要将大约 3 亿张照片(ID)和创建它们的用户ID的映射保存起来,以便知道查询那个分片。

他们选择了Redis后发现,为了保存这些映射,Redis需要21GB内存,这已经大于 Amazon EC2 上的 17GB 实例类型。

后来他们向Redis的核心开发人员Pieter Noordhuis求助,Pieter建议使用Redis Hash,最终通过巧妙的设计,这些映射仅需不到5G的内存。

对于其他缓存(如session),Instagram使用Memcached,当时有6个实例。

图片图片

数据备份

无论是PostGreSQL还是Redis,都会使用Amazon EBS经常性进行数据备用

通知和异步任务

Session: 用户关闭了App,但是朋友发送了一张照片,需要发送一个通知。

Instagram的推送服务用的是 pyapns, 这是一个开源的、通用的苹果推送服务提供商,运行非常稳定,为Instagram处理了超过10亿条推送通知。

Session:用户非常喜欢这张照片! 他决定在Twitter何Facebook上分享。

在后台, 任务被推送到了Gearman, 这个任务队列会保存任务,Instagram有大约200 Python workers 来处理这些任务。

图片图片

监控

Session: Uh oh! 服务器端发生了错误,Instagram崩溃了,那三个程序员需要收到告警,马上进行处理。

Instagram 使用 Sentry这个开源的应用来实时监控Python错误。

使用Munin来绘制各种系统指标的图表,如果有任何情况超出正常范围,就会向程序员发出异常告警。Instagram 有一堆自定义 Munin 插件来跟踪应用程序级别的指标,例如每秒发布的照片、每分钟注册人数等。 

对于外部服务的监控,使用了Pingdom ,PagerDuty 用于处理事件和通知。

最终的架构

图片图片

反思

2009年,我们三个都在比较传统的软件公司,互联网技术用得比较少。

像负载均衡、分库分表、缓存也是刚刚开始接触,还没有在生产系统中大规模使用的经验。

iPhone还没在国内上市,我们仨手头都没有,还在用诺基亚的“智能机”做测试。

国内市场也没有很好的云服务作为基础设施,当时李彦宏表示,云计算只不过是新瓶装旧酒,15年来没有新东西,马化腾则认为云计算要像水电一样用还为时尚早。

如果执行力强的话,InstantPost应该能做出来,但肯定会遇到很多的坑,想取得一年1000多万用户肯定是痴心妄想。 

当然,这仅仅说明是我们三个比较菜,不是中国程序员不行,中国程序员在互联网时代也创造了很多优秀的产品,甚至杀到了美国大本营。

我想说的是,很多看起来是风口的东西,我们是抓不住的,因为:

我们不是局内人。

参考资料:

https://engineercodex.substack.com/p/how-instagram-scaled-to-14-million (本文主体内容的来源)

https://instagram-engineering.com/what-powers-instagram-hundreds-of-instances-dozens-of-technologies-adf2e22da2ad

https://instagram-engineering.com/sharding-ids-at-instagram-1cf5a71e5a5c

责任编辑:武晓燕 来源: 码农翻身
相关推荐

2011-12-20 10:41:36

程序员

2013-04-10 09:35:22

程序员

2022-02-24 17:32:38

程序员互联网公司离职率

2018-01-26 14:22:31

程序员发展连接

2011-09-30 09:29:19

TechCruch创业2010年

2010-01-19 09:14:46

.NET编码习惯

2022-08-08 11:13:35

API接口前端

2018-05-02 12:58:19

2012-03-06 09:22:46

程序员

2018-04-27 14:25:27

程序员专业展现

2019-10-23 08:54:38

程序员CPUALU

2012-05-10 13:31:48

程序员开发者

2015-04-08 15:38:17

程序员程序员差距

2021-07-05 07:28:14

程序员菜鸟技术

2019-01-02 16:31:33

程序员技术互联网

2022-09-14 08:57:24

JavaNASA程序员

2020-10-05 21:13:37

程序员技能开发者

2020-06-28 14:36:27

程序员技能开发者

2011-10-20 09:31:25

程序员

2015-03-12 14:38:13

程序员女程序员美国的女程序员
点赞
收藏

51CTO技术栈公众号