耗時一年用戶從 0 增長至 1400 萬，背后僅三名工程師，這家社交巨頭背后的技術(shù)棧是如何搭建的？
發(fā)布時間：2023-09-21 15:29:06
值得注意的是，這個曾經(jīng)估值近千億美元的 Instagram 在技術(shù)運作上一直遵循著三個指導原則：讓事情變得更簡單、絕不重新發(fā)明輪子、盡可能使用經(jīng)過驗證的可靠技術(shù)。
在當今這個各領(lǐng)域巨頭們都在過度堆砌豪華技術(shù)棧以求建立技術(shù)霸權(quán)的時代，Instagram 的成功也不禁讓人思考，是否最終 99%的公司都可以使用由三、四個人管理的經(jīng)典 LAMPish 堆棧？
Instagram 發(fā)展史
2009 年，27 歲剛剛從斯坦福大學畢業(yè)的 Kevin Systrom 任職于 Nextstop——一家旅行推薦初創(chuàng)公司。Systrom 之前曾在谷歌擔任過企業(yè)開發(fā)助理，并在 Odeo 公司實習（該公司后來發(fā)展成了 Twitter，也就是如今的 X）。
雖然 Systrom 并沒有接受過計算機科學方面的正式訓練，但還是憑借著才智和毅力在 Nextstop 任職時利用業(yè)余時間學會了編程。他最終開發(fā)出一款名叫 Burbn 的 Web 應用原型，其設計靈感來自他個人對威士忌和波本酒的深深喜愛。Burbn 應用允許用戶簽到、發(fā)布邀約和分享照片。盡管當時基于位置的簽到類應用非常流行，但 Burbn 的照片共享功能仍在同類市場中顯得獨樹一幟。
2010 年 3 月，關(guān)鍵的轉(zhuǎn)折點不期而至。當時 Systrom 參加了硅谷初創(chuàng)公司 Hunch 的一場聚會，并在會上遇見了來自 Baseline Ventures 和 Andreessen Horowitz 的兩位風險投資家。在向他們展示了 Burbn 應用的原型之后，大家決定有機會喝杯咖啡再做進一步討論。首次會面之后，Systrom 決定辭掉工作、專心打磨 Burbn。短短兩周之內(nèi)，他就從 Baseline Ventures 和 Andreessen Horowitz 籌集到 50 萬美元的種子資金，用以進一步拓展自己的創(chuàng)業(yè)公司。
有了種子資金的加持，Systrom 得以組建一支維系業(yè)務運轉(zhuǎn)的團隊：第一位加入的成員是 25 歲的 Mike Krieger。Krieger 同樣來自斯坦福大學，此前曾在社交媒體平臺 Meebo 擔任工程師兼用戶體驗設計師，而且兩人在校期間就認識對方。
在 Krieger 加入之后，二人重新評估了 Burbn 的業(yè)務空間，并決定將注意力集中在單一核心之上：分享由移動設備拍攝的照片。他們仔細研究了當時攝影領(lǐng)域的其他領(lǐng)先應用。在他們二人看來，Hipstamatic 應用的表現(xiàn)最出色，當時也頗受市場歡迎。其最大亮點就是提供豐富的功能選項，比如照片濾鏡。然而，由于該軟件缺乏社交媒體分享功能，Systrom 和 Krieger 從 Hipstamatic 和 Facebook 等社交平臺的夾縫當中看到了巨大潛力。
于是他們退后一步，將 Burbn 精簡成了照片加評論加“點贊”的功能綜合體。以此為基礎(chǔ)，他們將應用重新命名為 Instagram，結(jié)合的是 Instant（即時）與 telegram（電報）兩個單詞。他們還專注于改善照片共享體驗，想要把 Instagram 打造成一款極簡化、盡可能減少用戶操作需求的產(chǎn)品。經(jīng)過八周的應用調(diào)整之后，他們帶著 beta 版本給朋友們體驗，嘗試進行初步性能評估。在解決了軟件中的一些錯誤之后，Instagram 首度與全世界用戶見面。
2010 年 10 月 6 日 Instagram 的 iOS 版本正式亮相，并在一天之內(nèi)就吸引到 2.5 萬名用戶。在第一周結(jié)束時，Instagram 的下載量已達 10 萬次。到 12 月中旬，其用戶數(shù)量達到 100 萬。必須承認，Instagram 的成功有著很強的運氣因素，因為就在幾個月前（2010 年 6 月）搭載更強攝像頭的 iPhone 4 剛剛驚艷出爐。
隨著 Instagram 用戶基礎(chǔ)的迅速擴張，更多投資者對這家年輕的公司表現(xiàn)出興趣。2011 年 2 月，Instagram 在 A 輪融資中籌得 700 萬美元。作為其投資方之一，Benchmark Capital 為 Instagram 開出了 2500 萬美元的市場估值。除了機構(gòu)投資者之外，Instagram 還吸引到社交媒體技術(shù)行業(yè)眾多領(lǐng)先廠商的關(guān)注，其中就包括 Twitter 和 Facebook。
盡管新一輪融資讓 Systrom 和 Krieger 擁有了擴大人員規(guī)模的底氣，但兩位創(chuàng)始人還是決定控制自身體量，將班底繼續(xù)保持在十幾人的水平。
Systrom 在 Odeo 實習時結(jié)識了 Twitter 聯(lián)合創(chuàng)始人 Jack Dorsey。Dorsey 也對 Instagram 表現(xiàn)出深厚的興趣，并提出出手收購的想法。據(jù)報道，Twitter 最終提出了價值約 5 億平均的股票收購方案，但被 Systrom 予以回絕。
用戶從 0 增長到 1400 萬，背后僅靠 3 名工程師支撐
從 2010 年 10 月到 2011 年 12 月，Instagram 在短短一年多時間里將用戶數(shù)量從 0 擴展至 1400 萬。而這一切的實現(xiàn)，背后僅有 3 名工程師的參與。
這個驚人目標源自三大基本原則，外加穩(wěn)定可靠的技術(shù)棧，以下是 Instagram 的指導原則與技術(shù)棧構(gòu)成分析。
一直以來，Instagram 的技術(shù)運作都遵循著三個指導原則：
讓事情變得更簡單。
絕不重新發(fā)明輪子。
盡可能使用經(jīng)過驗證的可靠技術(shù)。
簡要介紹技術(shù)棧
Instagram 的早期基礎(chǔ)設施運行在 AWS 之上，使用 EC2 配合 Ubuntu Linux，EC2 是亞馬遜提供的服務，允許開發(fā)人員租用虛擬計算機承載自家工作負載。
為了保證一切盡可能簡單，這里用純粹的工程師思維展開討論，延著用戶會話的生命周期捋順整個流程：
前端
會話：用戶打開 Instagram 應用。
Instagram 最初于 2010 年發(fā)布 iOS 版應用。由于 Swift 語言要到 2014 年才亮相，所以合理的猜測是 Instagram 是使用 Objective-C 和 UIKit 等方案組合編寫而成。
負載均衡
會話：在應用開啟之后，向后端發(fā)送一條獲取主提要圖像的請求，此請求隨后抵達 Instagram 負載均衡器。
Instagram 采用亞馬遜的 Elastic Load Balancer 服務。工程師們租用了 3 個 NGINX 實例，并根據(jù)其運行情況來決定何時切入和切出。
每條請求會首先抵達負載均衡器，而后再被路由至實際應用服務器。
后端
會話：負載均衡器將請求發(fā)送至應用服務器，而應用服務器負責保存正確處理請求所必需的邏輯。
Instagram 的應用服務器使用 Django、由 Python 編寫，并選擇 Gunicorn 作為其 WSGI 服務器。
這里解釋一下，WSGI（Web 服務器網(wǎng)關(guān)接口）負責將請求從 Web 服務器轉(zhuǎn)發(fā)至 Web 應用程序。
Instagram 使用 Fabric 同時在多個實例上并行運行命令，從而在幾秒鐘之內(nèi)完成代碼部署。
這一切共同運行在 25 臺以上的亞馬遜 High-CPU Extra-Large 超大設備之上。由于服務器本身保持無狀態(tài)，所以在需要處理更多請求時，可以靈活添加更多計算資源。
通用數(shù)據(jù)存儲
會話：應用服務器須識別出請求所需要的主提要數(shù)據(jù)，這里猜測它需要完成以下流程：
獲取相關(guān)圖像的最新 ID；
獲取與這些 ID 相匹配的實際圖像；
為這些圖像獲取用戶數(shù)據(jù)。
數(shù)據(jù)庫：Postgres
會話：應用服務器從 Postgres 處獲取相關(guān)圖像的最新 ID。
應用服務器將從 PostgreSQL 處提取數(shù)據(jù)，PostgreSQL 存儲有 Instagram 的大部分數(shù)據(jù)，包括用戶和照片元數(shù)據(jù)。
Postgres 和 Django 之間的連接，由 Pgbouncer 負責匯總成池。
由于收取到的數(shù)據(jù)量很大（每秒超過 25 張圖像和 90 個贊），因此 Instagram 需要對數(shù)據(jù)進行分片。Instagram 依靠代碼將數(shù)千個“邏輯”分片映射至數(shù)個物理分片。
Instagram 還面臨著另一個有趣挑戰(zhàn)，即如何生成可以按時間排序的 ID。他們生成的可按時間排序 ID 如下所示：
用 41 位表示時間（以毫秒為單位，可在一條自定義 epoch 中表達 41 年間的所有 ID）；
用 13 位表示邏輯分片 ID；
用 10 位表示自動遞增序列，模數(shù)為 1024。這意味著我們可以每毫秒為每個分片生成 1024 個 ID。
借助 Postgres 中的可按時間排序 ID，應用服務器能夠成功接收到相關(guān)圖像的最新 ID。
圖像存儲：S3 與 CloudFront
會話：之后，應用服務器會獲取與各圖像 ID 相匹配的實際圖像，并通過快速 CDN 鏈接為用戶提供順暢的加載體驗。
Amazon S3 中存儲有數(shù)以 TB 的圖像。這些圖像可通過 Amazon CloudFront 被快速交付給用戶。
緩存：Redis 與 Memcached
會話：為了從 Postgres 處獲取用戶數(shù)據(jù)，應用服務器（Django）使用 Redis 將圖像 ID 與用戶 ID 進行匹配。
在 Redis 的支持下，Instagram 能夠為約 3 億張圖像存儲建立起指向創(chuàng)建者用戶 ID 的映射，借此引導在獲取主提要、活動提要等圖像時具體應查詢哪個分片。所有 Redis 都存儲在內(nèi)存內(nèi)以降低延遲，并將數(shù)據(jù)分片至多臺機器之上。
通過一系列巧妙的哈希處理，Instagram 得以在不到 5 GB 空間內(nèi)存儲這 3 億個鍵映射。
由此建立的圖像 ID 與用戶 ID 的鍵值映射，用于指示具體應查詢哪個 Postgres 分片。
會話：借助 Memcached 的高效緩存（最近響應均被納入緩存），從 Postgres 處獲取用戶數(shù)據(jù)的速度很快。
對于常規(guī)緩存，Instagram 使用 Memcached。當時 Instagram 設置了 6 個 Memcached 實例，可以在 Django 上以相對簡單的方式進行分層。
有趣的事實：兩年之后的 2013 年，F(xiàn)acebook 發(fā)布了一篇具有里程碑意義的論文，介紹了他們?nèi)绾螖U展 Memcached 以順利實現(xiàn)每秒數(shù)十億條請求的處理能力。
會話：用戶現(xiàn)在可以看到主頁內(nèi)容，其中展示的就是其所關(guān)注用戶的最新圖像。
主副本設置
Postgres 和 Redis 均在主副本設置中運行，并使用 Amazon EBS（Elasti
