耗时一年用户从 0 增长至 1400 万，背后仅三名工程师，这家社交巨头背后的技术栈是如何搭建的？
发布时间：2023-09-21 15:29:06
值得注意的是，这个曾经估值近千亿美元的 Instagram 在技术运作上一直遵循着三个指导原则：让事情变得更简单、绝不重新发明轮子、尽可能使用经过验证的可靠技术。
在当今这个各领域巨头们都在过度堆砌豪华技术栈以求建立技术霸权的时代，Instagram 的成功也不禁让人思考，是否最终 99%的公司都可以使用由三、四个人管理的经典 LAMPish 堆栈？
Instagram 发展史
2009 年，27 岁刚刚从斯坦福大学毕业的 Kevin Systrom 任职于 Nextstop——一家旅行推荐初创公司。Systrom 之前曾在谷歌担任过企业开发助理，并在 Odeo 公司实习（该公司后来发展成了 Twitter，也就是如今的 X）。
虽然 Systrom 并没有接受过计算机科学方面的正式训练，但还是凭借着才智和毅力在 Nextstop 任职时利用业余时间学会了编程。他最终开发出一款名叫 Burbn 的 Web 应用原型，其设计灵感来自他个人对威士忌和波本酒的深深喜爱。Burbn 应用允许用户签到、发布邀约和分享照片。尽管当时基于位置的签到类应用非常流行，但 Burbn 的照片共享功能仍在同类市场中显得独树一帜。
2010 年 3 月，关键的转折点不期而至。当时 Systrom 参加了硅谷初创公司 Hunch 的一场聚会，并在会上遇见了来自 Baseline Ventures 和 Andreessen Horowitz 的两位风险投资家。在向他们展示了 Burbn 应用的原型之后，大家决定有机会喝杯咖啡再做进一步讨论。首次会面之后，Systrom 决定辞掉工作、专心打磨 Burbn。短短两周之内，他就从 Baseline Ventures 和 Andreessen Horowitz 筹集到 50 万美元的种子资金，用以进一步拓展自己的创业公司。
有了种子资金的加持，Systrom 得以组建一支维系业务运转的团队：第一位加入的成员是 25 岁的 Mike Krieger。Krieger 同样来自斯坦福大学，此前曾在社交媒体平台 Meebo 担任工程师兼用户体验设计师，而且两人在校期间就认识对方。
在 Krieger 加入之后，二人重新评估了 Burbn 的业务空间，并决定将注意力集中在单一核心之上：分享由移动设备拍摄的照片。他们仔细研究了当时摄影领域的其他领先应用。在他们二人看来，Hipstamatic 应用的表现最出色，当时也颇受市场欢迎。其最大亮点就是提供丰富的功能选项，比如照片滤镜。然而，由于该软件缺乏社交媒体分享功能，Systrom 和 Krieger 从 Hipstamatic 和 Facebook 等社交平台的夹缝当中看到了巨大潜力。
于是他们退后一步，将 Burbn 精简成了照片加评论加“点赞”的功能综合体。以此为基础，他们将应用重新命名为 Instagram，结合的是 Instant（即时）与 telegram（电报）两个单词。他们还专注于改善照片共享体验，想要把 Instagram 打造成一款极简化、尽可能减少用户操作需求的产品。经过八周的应用调整之后，他们带着 beta 版本给朋友们体验，尝试进行初步性能评估。在解决了软件中的一些错误之后，Instagram 首度与全世界用户见面。
2010 年 10 月 6 日 Instagram 的 iOS 版本正式亮相，并在一天之内就吸引到 2.5 万名用户。在第一周结束时，Instagram 的下载量已达 10 万次。到 12 月中旬，其用户数量达到 100 万。必须承认，Instagram 的成功有着很强的运气因素，因为就在几个月前（2010 年 6 月）搭载更强摄像头的 iPhone 4 刚刚惊艳出炉。
随着 Instagram 用户基础的迅速扩张，更多投资者对这家年轻的公司表现出兴趣。2011 年 2 月，Instagram 在 A 轮融资中筹得 700 万美元。作为其投资方之一，Benchmark Capital 为 Instagram 开出了 2500 万美元的市场估值。除了机构投资者之外，Instagram 还吸引到社交媒体技术行业众多领先厂商的关注，其中就包括 Twitter 和 Facebook。
尽管新一轮融资让 Systrom 和 Krieger 拥有了扩大人员规模的底气，但两位创始人还是决定控制自身体量，将班底继续保持在十几人的水平。
Systrom 在 Odeo 实习时结识了 Twitter 联合创始人 Jack Dorsey。Dorsey 也对 Instagram 表现出深厚的兴趣，并提出出手收购的想法。据报道，Twitter 最终提出了价值约 5 亿平均的股票收购方案，但被 Systrom 予以回绝。
用户从 0 增长到 1400 万，背后仅靠 3 名工程师支撑
从 2010 年 10 月到 2011 年 12 月，Instagram 在短短一年多时间里将用户数量从 0 扩展至 1400 万。而这一切的实现，背后仅有 3 名工程师的参与。
这个惊人目标源自三大基本原则，外加稳定可靠的技术栈，以下是 Instagram 的指导原则与技术栈构成分析。
一直以来，Instagram 的技术运作都遵循着三个指导原则：
让事情变得更简单。
绝不重新发明轮子。
尽可能使用经过验证的可靠技术。
简要介绍技术栈
Instagram 的早期基础设施运行在 AWS 之上，使用 EC2 配合 Ubuntu Linux，EC2 是亚马逊提供的服务，允许开发人员租用虚拟计算机承载自家工作负载。
为了保证一切尽可能简单，这里用纯粹的工程师思维展开讨论，延着用户会话的生命周期捋顺整个流程：
前端
会话：用户打开 Instagram 应用。
Instagram 最初于 2010 年发布 iOS 版应用。由于 Swift 语言要到 2014 年才亮相，所以合理的猜测是 Instagram 是使用 Objective-C 和 UIKit 等方案组合编写而成。
负载均衡
会话：在应用开启之后，向后端发送一条获取主提要图像的请求，此请求随后抵达 Instagram 负载均衡器。
Instagram 采用亚马逊的 Elastic Load Balancer 服务。工程师们租用了 3 个 NGINX 实例，并根据其运行情况来决定何时切入和切出。
每条请求会首先抵达负载均衡器，而后再被路由至实际应用服务器。
后端
会话：负载均衡器将请求发送至应用服务器，而应用服务器负责保存正确处理请求所必需的逻辑。
Instagram 的应用服务器使用 Django、由 Python 编写，并选择 Gunicorn 作为其 WSGI 服务器。
这里解释一下，WSGI（Web 服务器网关接口）负责将请求从 Web 服务器转发至 Web 应用程序。
Instagram 使用 Fabric 同时在多个实例上并行运行命令，从而在几秒钟之内完成代码部署。
这一切共同运行在 25 台以上的亚马逊 High-CPU Extra-Large 超大设备之上。由于服务器本身保持无状态，所以在需要处理更多请求时，可以灵活添加更多计算资源。
通用数据存储
会话：应用服务器须识别出请求所需要的主提要数据，这里猜测它需要完成以下流程：
获取相关图像的最新 ID；
获取与这些 ID 相匹配的实际图像；
为这些图像获取用户数据。
数据库：Postgres
会话：应用服务器从 Postgres 处获取相关图像的最新 ID。
应用服务器将从 PostgreSQL 处提取数据，PostgreSQL 存储有 Instagram 的大部分数据，包括用户和照片元数据。
Postgres 和 Django 之间的连接，由 Pgbouncer 负责汇总成池。
由于收取到的数据量很大（每秒超过 25 张图像和 90 个赞），因此 Instagram 需要对数据进行分片。Instagram 依靠代码将数千个“逻辑”分片映射至数个物理分片。
Instagram 还面临着另一个有趣挑战，即如何生成可以按时间排序的 ID。他们生成的可按时间排序 ID 如下所示：
用 41 位表示时间（以毫秒为单位，可在一条自定义 epoch 中表达 41 年间的所有 ID）；
用 13 位表示逻辑分片 ID；
用 10 位表示自动递增序列，模数为 1024。这意味着我们可以每毫秒为每个分片生成 1024 个 ID。
借助 Postgres 中的可按时间排序 ID，应用服务器能够成功接收到相关图像的最新 ID。
图像存储：S3 与 CloudFront
会话：之后，应用服务器会获取与各图像 ID 相匹配的实际图像，并通过快速 CDN 链接为用户提供顺畅的加载体验。
Amazon S3 中存储有数以 TB 的图像。这些图像可通过 Amazon CloudFront 被快速交付给用户。
缓存：Redis 与 Memcached
会话：为了从 Postgres 处获取用户数据，应用服务器（Django）使用 Redis 将图像 ID 与用户 ID 进行匹配。
在 Redis 的支持下，Instagram 能够为约 3 亿张图像存储建立起指向创建者用户 ID 的映射，借此引导在获取主提要、活动提要等图像时具体应查询哪个分片。所有 Redis 都存储在内存内以降低延迟，并将数据分片至多台机器之上。
通过一系列巧妙的哈希处理，Instagram 得以在不到 5 GB 空间内存储这 3 亿个键映射。
由此建立的图像 ID 与用户 ID 的键值映射，用于指示具体应查询哪个 Postgres 分片。
会话：借助 Memcached 的高效缓存（最近响应均被纳入缓存），从 Postgres 处获取用户数据的速度很快。
对于常规缓存，Instagram 使用 Memcached。当时 Instagram 设置了 6 个 Memcached 实例，可以在 Django 上以相对简单的方式进行分层。
有趣的事实：两年之后的 2013 年，Facebook 发布了一篇具有里程碑意义的论文，介绍了他们如何扩展 Memcached 以顺利实现每秒数十亿条请求的处理能力。
会话：用户现在可以看到主页内容，其中展示的就是其所关注用户的最新图像。
主副本设置
Postgres 和 Redis 均在主副本设置中运行，并使用 Amazon EBS（Elasti
