整理 | 云昭
策划 | 言征
出品 | 51CTO技术栈（微信号：blog51cto）
2010 年 10 月 6 日，旧金山。当人们还沉浸在拥有更强大摄像头的 iPhone 4 的激动心情时，一款名为“ Instagram ” 的 iOS 照片分享应用出现在应用商店中。
当天就收获了 2.5 万首批用户，一周之后，下载量攀升到 10 万，从 2010 年 10 月到 2011 年 12 月，Instagram在短短一年多的时间里，用户数量从 0 增长到 1400 万。
而他的创始人， Kevin Systrom 这期间用了 3 名工程师就做到了这一点。这就让我们回到那个奇幻的时刻，从工程师的角度思考，一探他们是如何做到的。
简单来说，他们通过如下遵循 3 个关键指导原则并拥有可靠的技术堆栈来做到这一点：让事情变得非常简单、不要重新发明轮子、尽可能使用经过验证的可靠技术。
一、早期基础配置
早期 Instagram 的基础设施，是在 AWS 上运行的，使用 EC2 和 Ubuntu Linux。作为参考，EC2 是亚马逊的服务，允许开发人员租用虚拟计算机。
为了让事情变得简单，并且由于我喜欢从工程师的角度思考用户，所以让我们回顾一下用户场景会话的生命周期。
二、前端
场景回顾：用户打开界面。
Instagram 最初于 2010 年作为 iOS 应用程序推出。由于 Swift 于 2014 年发布，我们可以假设 Instagram 是使用Objective-C 和 UIKit 等其他东西的组合编写的。
图片
三、负载均衡
场景回顾：打开应用程序后，获取主订阅源照片的请求会发送到后端，并在那里到达Instagram的负载均衡器。
Instagram 使用亚马逊的弹性负载均衡器。他们有 3 个 NGINX 实例，根据它们是否健康来换入和换出。
每个请求首先到达负载均衡器，然后再路由到实际的应用程序服务器。
图片
四、后端
场景回顾：负载均衡器将请求发送到应用程序服务器，应用程序服务器保存正确处理请求的逻辑。
Instagram 的应用服务器使用Django ，用 Python 编写，Gunicorn作为他们的 WSGI 服务器。
回顾一下，WSGI（Web 服务器网关接口）将请求从 Web 服务器转发到 Web 应用程序。
Instagram 使用Fabric同时在多个实例上并行运行命令。这允许在几秒钟内部署代码。
它们运行在超过 25 台 Amazon High-CPU 超大型机器上。由于服务器本身是无状态的，当他们需要处理更多请求时，他们可以添加更多机器。
图片
五、通用数据存储
场景回顾：应用服务器发现请求需要主提要的数据。为此，我们假设它需要：
- 最新的相关照片ID
- 与这些照片ID匹配的实际照片
- 这些照片的用户数据。
1.数据库：Postgres
场景回顾: 应用服务器从Postgres获取最新的相关照片ID。
应用程序服务器将从PostgreSQL中提取数据，PostgreSQL 存储了 Instagram 的大部分数据，例如用户和照片元数据。
Postgres 和 Django 之间的连接使用Pgbouncer进行池化。
Instagram由于收到的数据量很大（每秒超过 25 张照片和 90 个赞）而对他们的数据进行了分片。他们使用代码将数千个“逻辑”分片映射到几个物理分片。
Instagram 面临并解决的一个有趣的挑战是生成可以按时间排序的 ID。他们生成的可按时间排序的 ID 如下所示：
- 41 位时间（以毫秒为单位）（提供了 41 年的 ID 和自定义纪元）
- 13位代表逻辑分片ID
- 10 位表示自动递增序列，模数 1024。这意味着我们可以为每个分片、每毫秒生成 1024 个 ID
场景回顾：由于Postgres中的可按时间排序的ID，应用服务器已成功接收到最新的相关照片ID。
2.照片存储：S3 和 Cloudfront
场景回顾: 然后，应用服务器通过快速CDN链接获取与这些照片ID匹配的实际照片，以便为用户快速加载。
Amazon S3中存储了数 TB 的照片。这些照片已使用 Amazon CloudFront快速提供给用户。
3.缓存：Redis 和 Memcached
场景思考：为了从Postgres获取用户数据，应用服务器（Django）使用Redis将照片ID与用户ID进行匹配。
Instagram 使用 Redis 将大约 3 亿张照片存储到创建它们的用户 ID 的映射，以便知道在获取主提要、活动提要等照片时要查询哪个分片。所有 Redis 都存储在内存中减少延迟，并且它被分片到多台机器上。
通过一些巧妙的哈希处理，Instagram 能够在不到 5 GB 的空间中存储 3 亿个键映射。为了知道要查询哪个 Postgres 分片，需要此 photoID 到用户 ID 键值映射。
场景回顾：由于使用Memcached的高效缓存，从Postgres获取用户数据很快，因为最近的响应被缓存了。
对于一般缓存，Instagram 使用Memcached 。他们当时有 6 个 Memcached 实例。Memcached 在 Django 上分层相对简单。
有趣的是：两年后，即 2013 年，Facebook 发布了一篇具有里程碑意义的论文，介绍了他们如何扩展 Memcached 以帮助他们每秒处理数十亿个请求。
用户现在可以看到主页，里面有他关注的人的最新照片。
图片
4.主副本设置
Postgres 和 Redis 都在主副本设置中运行，并使用 Amazon EBS（弹性块存储）快照来频繁备份系统。
六、推送通知和异步任务
场景回顾：现在，假设用户关闭了应用程序，但随后收到朋友发布照片的推送通知。
此推送通知是使用pyapns发送的，与 Instagram 已经发送的其他十亿多条推送通知一起。Pyapns 是一个开源、通用的 Apple 推送通知服务 (APNS) 提供商。
场景回顾：用户非常喜欢这张照片！所以他决定在Twitter上分享。
在后端，任务被推送到Gearman中，这是一个任务队列，它将工作外包给更适合的机器。Instagram 有大约 200 个 Python 工作线程使用 Gearman 任务队列。
Gearman 用于执行多个异步任务，例如向所有用户的关注者推送活动（例如发布的新照片）（这称为扇出）。
图片
七、监控
场景回顾：Instagram应用程序因服务器出现错误而崩溃，并发送了错误响应。Instagram的三名工程师立即得到了提醒。
Instagram 使用Sentry （一款开源 Django 应用程序）来实时监控 Python 错误。
Munin用于绘制系统范围的指标并发出异常警报。Instagram 有一堆自定义 Munin 插件来跟踪应用程序级别的指标，例如每秒发布的照片。
Pingdom用于外部服务监控，PagerDuty用于处理事件和通知。
八、最终架构一览
图片
——后记——
Instagram发布的19个月，后活跃用户数量超过5000万，活跃用户数量达到1亿，2012年6月份达到1.3亿。同年10月25日，当时的Facebook以总值7.15亿美元收购Instagram，创始人Kevin从中获得了4亿美元的回报。
值得一提的是，于编程而言，Kevin是自学成才。管理学科出身的他，刚毕业时可谓是一张白纸，在社交旅游网站Nextstop营销部门工作时，凯文开始每晚抽时间自学编程。
Instagram 的成功带来的不仅仅创造了当代硅谷最伟大的成功故事之一，Kevin的自学成才的历程成为了激烈开发者们对于编程的热情。
参考链接：
https://instagram-engineering.tumblr.com/post/10853187575/sharding-ids-at-instagram
