人均身价超 5 亿的 Instagram,如何用 3 个工程师支撑 1400 万用户
原文 https://read.engineerscodex.com/p/how-instagram-scaled-to-14-million
Instagram 是一款以图片和短视频分享为主的社交媒体平台,于 2010 年由 Kevin Systrom 和 Mike Krieger 创建。用户可以通过 Instagram 应用发布和编辑照片和视频,添加滤镜和标签,以及与朋友互动。以下故事发生在 Instagram 早期的快速增长阶段。
他们之所以能做到这一点,是因为遵循了 3 个关键原则并拥有可靠的技术栈。
Instagram 的指导原则
一切从简。 不要重复发明轮子。 尽可能使用经过验证的可靠技术。
早期 Instagram 的基础设施运行在 AWS 上,使用 EC2 和 Ubuntu Linux。为了方便起见,让我们通过用户会话(session) 的生命周期来描述整个技术栈。
前端
会话:用户打开 Instagram 应用程序。
Instagram 最初是在 2010 年作为 iOS 应用程序推出的。Instagram 是使用 Objective-C 以及对应的 UIKit 框架来写的
负载均衡
会话:打开应用后,抓取主 feed 照片的请求会被发送到后台,在那里会碰到 Instagram 的负载均衡器。
Instagram 使用 AWS 的 Elastic Load Balancer (ELB)。他们有 3 个 NGINX 实例,这些实例会根据其是否健康进行交换。
每个请求在路由到实际应用服务器之前都会首先到达 ELB。
后端
会话:ELB 将请求发送到应用服务器,应用服务器拥有正确处理请求的逻辑。
Instagram 的应用服务器使用了 Django,它是用 Python 编写的,Gunicorn 是他们的 WSGI 服务器。
作为复习,WSGI(Web Server Gateway Interface,网络服务器网关接口)将请求从网络服务器转发到网络应用程序。
Instagram 使用 Fabric 同时在多个实例上并行运行命令。这样就能在几秒钟内部署代码。
这些实例运行在超过 25 台 AWS CPU High-CPU Extra-Large 的机器上。由于服务器本身是无状态的,因此当他们需要处理更多请求时,可以添加更多机器。
通用数据存储
会话:应用服务器收到请求,这些请求需要主 feed 上数据。
最新的相关照片 ID 与这些照片 ID 匹配的实际照片 这些照片的用户数据
数据库:Postgres
会话:应用服务器从 Postgres 中获取最新的相关照片 ID。
41 位比特表示以毫秒为单位的时间(提供 41 年的 ID 和自定义纪元) 13 位比特表示逻辑分片 ID 10 位比特表示自动递增序列,模数为 1024。这意味着我们可以为每个分区每毫秒生成 1024 个 ID
照片存储:S3 和 Cloudfront
会话:然后,应用服务器通过快速 CDN 链接获取与这些照片 ID 匹配的实际照片,以便快速加载给用户。
缓存:Redis 和 Memcached
会话:为了从 Postgres 中获取用户数据,应用服务器(Django)使用 Redis 将照片 ID 与用户 ID 进行匹配。
会话:由于使用了 Memcached 进行高效缓存,从 Postgres 获取用户数据的速度非常快。
会话:用户现在能看到首页 feed 了,上面有他所关注的人的最新图片。
主从设置
推送通知和异步任务
会话:现在,假设用户关闭了应用,但又收到推送通知说朋友发布了一张照片。
会话:用户非常喜欢这张照片!所以他决定在 Twitter 上分享。
监控
会话:啊哦!Instagram 挂了,原因是服务器出错,发送了错误的响应。Instagram 的三名工程师立即收到了警报。