Instagram 早期技术架构，你了解了吗？ _架构

想必大家都听说过 Instagram ，它是全球最受欢迎的社交媒体平台之一，拥有数十亿的活跃用户
Instagram 诞生于 2010 年，上线一周就坐拥 10 万注册用户，一年之内就拥有了 1400 万用户，可见扩张趋势突飞猛进。
Instagram 诞生的时候只有 3 个工程师，想必大家对【他们怎么设计后端架构，使用了什么技术来支持这么多用户】很感兴趣吧
那么今天我们就来了解一下 Instagram 是如何在只有 3 名工程师的情况下扩展到 1400 万用户
原文：https://engineercodex.substack.com/p/how-instagram-scaled-to-14-million

文章插图
图片
从 2010 年 10 月到 2011 年 12 月，Instagram 的用户在一年多的时间里从 0 增加到1400万，关键是他们只有 3 个工程师
这听起来是不是很不可思议。据 Instagram 工程师透露，他们通过遵循下面 3 个关键原则并拥有可靠的技术栈来做到这一点：

让事情变得非常简单
不要重复造轮子
尽可能使用经过验证的可靠技术

技术栈Instagram 早期的基础设施运行在 AWS 上，使用 EC2 和 Ubuntu linux
EC2 是 Amazon 的云服务，它允许开发人员租用虚拟机

前端 App

Instagram 最初在 2010 年作为 IOS 应用程序推出。由于 Swift 在 2014 年才发布，那 Instagram 应该是使用 Objective-C 和 UIKit 等其他语言的组合来编写的

负载均衡

Instagram 使用了 Amazon 的 Elastic 负载均衡器（Load Balancer）。他们有 3 个 Nginx 实例， Nginx 之间会进行健康检查以此保证服务高可用
当用户请求到来时，每个请求会先经过负载均衡器，然后才被转发到后端实际服务器

文章插图
图片

后端服务

文章插图
图片
Instagram 的应用程序服务器使用了 Django 框架，它是由 Python/ target=_blank class=infotextkey>Python 编写的，而 Gunicorn 是它们的 WSGI 服务器
WSGI （Web Server Gateway Interface）全称 web 服务器网关接口，它会将请求从 web 服务器转发到 web 应用程序
在批量管理和自动运维方面，Instagram 通过 Fabric 同时在多个实例上面并行运行命令，做到几秒钟内部署代码
Fabric 是 Python 的一个模块，基于 SSH 提供了丰富的交互接口，可以用来在本地或远程机器上自动化的执行 Shel l命令，非常适合用来做应用的远程部署及系统维护
这些实例在超过25台 Amazon High-CPU Extra-Large 机器上运行。由于服务器本身是无状态的，如果需要处理更多请求时，便可以添加更多的机器

一般数据存储

Instagram 使用了 PostgreSQL 来存储数据，应用程序服务器将从 PostgreSQL 中提取数据， PostgreSQL 存储了 Instagram 的大部分数据，例如用户和照片元数据
PostgreSQL 和 Django 之间的连接通过 pgbouncer
pgbouncer 是一个 PostgreSQL 连接池
任何目标应用程序都可以像连接 PostgreSQL 服务器一样连接到 pgbouncer，并且 pgbouncer 将创建到实际服务器的连接，或者重用其现有的连接
Instagram 对用户的数据进行了分片，即使用代码将几千个“逻辑”碎片映射到几个物理碎片，因为收到的数据量很大(每秒超过 25 张照片和 90 个赞)
但是在将数据写入这组服务器之前，Instagram 必须解决如何为数据库中的每条数据分配ID(唯一标识符)的问题
下面则是 Instagram 中每条数据 ID 包含的内容：