从 0 到 1400 万用户，3 名工程师如何撑起 Instagram？
Instagram，是 Meta于 2010 年推出的一款免费提供在线图片及视频分享的社群应用软件。在推出短短一年的时间里，Instagram 迅速“蹿红”，它的用户数量从 0 增长到了 1400 万。而在这背后，只有三名工程师在支撑。
Instagram 的成功，成为很多软件产品学习的楷模，那么它究竟是怎么做到的？背后运用了哪些技术栈？近日，一篇文章初探了其中的秘密。
来源：https://engineercodex.substack.com/p/how-instagram-scaled-to-14-million
翻译工具 | ChatGPT 责编 | 苏宓
出品 | CSDN（ID：CSDNnews）
以下为译文：
从 2010 年 10 月到 2011 年 12 月，Instagram 在短短一年多的时间里，用户数量从 0 增长到了 1400 万。他们仅仅依靠 3 名工程师实现了这一壮举。
他们之所以能够做到这一点，是因为遵循了 3 个关键原则并采用了可靠的技术堆栈。
Instagram 的指导原则：
1. 保持极度简单。
2. 不要重新发明轮子。
3. 在可能的情况下使用经过验证的、稳定的技术。
Instagram 背后的技术堆栈
早期的 Instagram 基础设施在 AWS 上运行，使用了带有 Ubuntu linux 的 EC2。EC2 是亚马逊的一项服务，允许开发人员租用虚拟计算机。
为了简化说明，这里从工程师的角度来看用户会话的生命周期（下文标注为“Session：”），从而捋清楚 Instagram 所用到的一些技术。
前端
Session：用户打开 Instagram 应用。
Instagram 最初于 2010 年作为 IOS 应用推出。由于 Swift 于 2014 年发布，我们可以猜测 Instagram 是使用 Objective-C 以及其他如 UIKit 的组合技术来编写的。
负载均衡
Session：打开应用后，向后端发送请求以获取主要的动态照片，该请求将被发送到 Instagram 的负载均衡器。
Instagram 使用了亚马逊的弹性负载均衡器。工程师租用了3 个 Nginx 实例，并根据它们的健康状态进行交替切换。
每个请求首先会被发送到负载均衡器，然后再路由到实际的应用服务器。
后端
Session：负载均衡器将请求发送到应用服务器，应用服务器负责保存处理请求的逻辑。
Instagram 的应用服务器使用 Django 框架以及它是用 Python/ target=_blank class=infotextkey>Python 编程语言编写的，并选择 Gunicorn 作为他们的 WSGI 服务器。
值得一提的是，WSGI（Web 服务器网关接口）将请求从 Web 服务器转发到 Web 应用程序。
Instagram 使用 Fabric 在多个实例上并行运行命令。这允许他们在几秒内部署代码。
这些应用服务器运行在超过 25 台亚马逊高性能 CPU 大型服务器上。由于服务器本身是无状态的，当需要处理更多请求时，他们可以添加更多服务器。
通用数据存储
Session：应用服务器意识到请求需要主要动态数据。为此，让我们假设它需要：
- 最新相关的照片 ID
- 与这些照片 ID 匹配的实际照片
- 这些照片的用户数据。
数据库：Postgres
Session：应用服务器从 Postgres 中获取最新相关的照片 ID。
应用服务器会从存储了大部分 Instagram 数据的 PostgreSQL 中提取数据，包括用户和照片元数据。
Postgres 和 Django 之间的连接使用 Pgbouncer 进行连接池化管理。
由于 Instagram 收到的数据量很大（每秒超过 25 张照片和 90 个点赞），工程师对数据进行了分片。他们使用代码将数千个“逻辑”分片映射到少数物理分片上。
Instagram 面临并解决的一个有趣挑战是生成可以按时间排序的 ID。他们生成的可按时间排序的 ID 如下：
- 用 41 位表示毫秒级时间（使用自定义时期，可提供 41 年的 ID）
- 用 13 位表示逻辑分片 ID
- 用 10 位表示自动递增序列，模数为 1024。这意味着我们可以在每个分片中每毫秒生成 1024 个 ID
由于在 Postgres 中使用可按时间排序的 ID，应用服务器已成功接收到最新相关的照片 ID。
照片存储：S3 和 Cloudfront
Session：应用服务器获取与这些照片 ID 匹配的实际照片，并使用快速 CDN 链接，以便为用户快速加载这些照片。
数千字节的照片存储在 Amazon S3 中。这些照片通过 Amazon CloudFront 迅速提供给用户。
缓存：redis 和 Memcached
Session：为了从 Postgres 中获取用户数据，应用服务器（Django）使用 Redis 将照片 ID 与用户 ID 匹配。
Instagram 使用 Redis 存储了大约 3 亿张照片与创建它们的用户 ID 的映射，以便在获取主要动态数据、活动动态数据等时知道要查询哪个分片。所有的 Redis 都存储在内存中，以降低延迟，并分布在多台机器上。
通过一些巧妙的哈希处理，Instagram 成功地将 3 亿个键映射存储在不到 5GB 的空间中。
为了知道要查询哪个 Postgres 分片，需要这种 photoID 到 user ID 的键-值映射。
Session：由于最近已经缓存响应，通过高效的 Memcached 缓存获取用户数据，从 Postgres 获取数据的速度很快。
对于一般的缓存，Instagram 使用了 Memcached。那时他们有 6 个 Memcached 实例。在 Django 上使用 Memcached 相对简单。
有趣的事实：2 年后，即在 2013 年，Facebook 发布了一篇关于如何扩展 Memcached 以帮助他们处理每秒数十亿请求的重要论文。
Session：用户现在可以看到主页动态，其中包含他正在关注的人的最新照片。
主从设置
Postgres 和 Redis 都在主从设置下运行，并使用 Amazon EBS（弹性块存储）的快照功能来频繁备份系统。
推送通知和异步任务
Session：现在，假设用户关闭了应用，但后来收到了一个朋友发布了一张照片的推送通知。
这个推送通知是使用 pyapns 发送的，以及 Instagram 发送出的十亿多条其他推送通知。Pyapns 是一个开源的通用苹果推送通知服务（APNS）提供商。
Session：用户非常喜欢这张照片！所以他决定在 Twitter 上分享它。
在后端，这个任务被推送到 Gearman，这是一个任务队列，用于分配适合的机器来处理工作。Instagram 拥有大约 200 个 Python 工作程序来消耗 Gearman 任务队列。
Gearman 被用于多个异步任务，比如向所有用户的粉丝（称为粉丝传播）推送活动信息（比如发布新照片）。
监控
Session：糟糕！Instagram 应用程序崩溃了，因为服务器上出现了错误，并发送了错误的响应。三名 Instagram 工程师立即收到警报。
Instagram 使用 Sentry，一个开源的 Django 应用程序，实时监控 Python 错误。
Munin 用于绘制系统范围的指标和警告异常。Instagram 有很多自定义的 Munin 插件来跟踪应用级别的指标，比如每秒发布的照片数量。
Pingdom 用于外部服务监控，PagerDuty 用于处理事故和通知。
最终架构概述
