三個(gè)中國(guó)程序員 vs三個(gè)美國(guó)程序員，不得不承認(rèn)，差距太大了！

作者：liuxin 2023-11-28 09:03:50

國(guó)內(nèi)市場(chǎng)也沒有很好的云服務(wù)作為基礎(chǔ)設(shè)施，當(dāng)時(shí)李彥宏表示，云計(jì)算只不過是新瓶裝舊酒，15年來沒有新東西，馬化騰則認(rèn)為云計(jì)算要像水電一樣用還為時(shí)尚早。

大概是2009年，我和兩個(gè)好哥們聊天，覺得智能手機(jī)可能是風(fēng)口，商量著要弄一個(gè)照片分享網(wǎng)站。

用戶可以用手機(jī)把隨手拍的照片放到網(wǎng)上分享，名稱都起好了，叫InstantPost。

可是我們的執(zhí)行力太差了，聚了兩次，做了一點(diǎn)兒技術(shù)驗(yàn)證，就沒有下文了。

過了幾年，我看到美國(guó)一個(gè)叫Instagram的火了，不由地一拍大腿：臥槽！這不就是我們當(dāng)年要做的事兒?jiǎn)?？?/p>

圖片

后來我看到Instagram初期的故事，他們也是三個(gè)程序員，從2010年10月到2011年12月，在一年多的時(shí)間內(nèi)，就把用戶數(shù)量從0增長(zhǎng)到了1400萬(wàn)！

看完他們的架構(gòu)設(shè)計(jì)，我就釋然了，拋開執(zhí)行力，在2009年那個(gè)時(shí)間點(diǎn)，我們確實(shí)不行。

Instagram制定的架構(gòu)指導(dǎo)準(zhǔn)則是：

1.保持簡(jiǎn)單

2.不要重新發(fā)明輪子

3.盡可能使用經(jīng)過驗(yàn)證的可靠技術(shù)

所以早期的Instagram跑在云上，使用EC2和Ubuntu Linux 11.04（“Natty Narwhal”）。

接下來，站在一個(gè)用戶會(huì)話(Session)的角度，來看看Instagram的處理過程。

前端

Session：用戶打開了Instagram APP。

2010年，Instagram開發(fā)了一個(gè)iOS app，正式推出。

因?yàn)檫@時(shí)候Swift還沒有發(fā)布，他們用了Objective-C，UIKit等技術(shù)。

圖片

負(fù)載均衡

Session：打開App后，會(huì)向后端發(fā)起一個(gè)請(qǐng)求（獲取主界面的“信息流”），這個(gè)請(qǐng)求會(huì)首先到達(dá)Instagram的負(fù)載均衡。

Instagram 最早使用2個(gè)Nginx并在它們之間進(jìn)行DNS Round-Robin，這種方法的缺點(diǎn)是，如果某一個(gè)機(jī)器出現(xiàn)故障，DNS的更新需要時(shí)間。

后來他們選擇了Amazon的Elastic Load Balancer，這里有三個(gè)NGINX實(shí)例，可以換入換出。

圖片

后端

Session：負(fù)載均衡會(huì)把請(qǐng)求轉(zhuǎn)發(fā)給應(yīng)用服務(wù)器

Instagram用Django作為后端服務(wù)，運(yùn)行在 Amazon High-CPU Extra-Large 上，因?yàn)檫@三個(gè)程序員發(fā)現(xiàn)，后端服務(wù)是CPU密集型的。

用Gunicorn做WSGI Server。

圖片

應(yīng)用運(yùn)行在超過25臺(tái)亞馬遜虛擬機(jī)中，這些應(yīng)用都是無(wú)狀態(tài)的，可以在需要的時(shí)候進(jìn)行擴(kuò)展。

為了在多臺(tái)機(jī)器上運(yùn)行命令（例如部署代碼），Instagram使用了Fabric，它有一個(gè)很好用的并行模式，部署只需要幾秒鐘。

數(shù)據(jù)存儲(chǔ)

Session: 用戶請(qǐng)求到達(dá)了應(yīng)用服務(wù)器，接下來它需要獲得這些數(shù)據(jù)：

1.最新的Photo IDs

2.這些Photo ID對(duì)應(yīng)的實(shí)際照片

3.這些照片的用戶數(shù)據(jù)

Database: PostgreSQL

Session: 應(yīng)用服務(wù)器從PostgreSQL獲取最新的Photo ID，這里保存著用戶和照片的元數(shù)據(jù)。

大部分的數(shù)據(jù)，如用戶，照片元數(shù)據(jù)，標(biāo)簽等都保存在PostgreSQL數(shù)據(jù)庫(kù)中。

因?yàn)閿?shù)據(jù)量不小，每秒鐘有25個(gè)照片上傳，并且有90個(gè)贊，Instagram對(duì)數(shù)據(jù)做了分片。

分片系統(tǒng)由數(shù)千個(gè)邏輯分片組成，這些分片在代碼中被映射到少得多的物理分片，用這種辦法，可以從少量的數(shù)據(jù)庫(kù)開始，擴(kuò)展到更多的數(shù)據(jù)庫(kù)。

當(dāng)擴(kuò)展時(shí)，只需要把邏輯分片從一個(gè)數(shù)據(jù)庫(kù)“指向”另外一個(gè)即可，無(wú)需挪動(dòng)任何數(shù)據(jù)。

一個(gè)挑戰(zhàn)是：Instagram如何解決Photo ID問題，因?yàn)樾枰馨磿r(shí)間排序，而無(wú)需獲得有關(guān)照片的更多信息，理想情況下，ID應(yīng)該是64位的。

后來的解決方案是這樣的：

41位：記錄毫秒時(shí)間

13位：邏輯分片ID

10位：自動(dòng)增長(zhǎng)的序列，模數(shù)1024，這意味著每毫秒，每個(gè)分片可以生成1024個(gè)ID

最終結(jié)果是個(gè)64為整數(shù)，可以被PostgreSQL排序，找到最新的照片。

照片的存儲(chǔ)：S3 和Cloudfront

Session: 獲取了Photo ID以后，應(yīng)用服務(wù)器要獲取真正的照片，快速發(fā)給用戶

照片保存在Amazon S3中，存儲(chǔ)了幾個(gè)TB的數(shù)據(jù)，通過使用CDN（Amazon CloudFront ），照片可以快速分發(fā)給世界各地的用戶（例如日本，是Instagram第二大受歡迎的國(guó)家）

緩存

Instagram 需要將大約 3 億張照片(ID)和創(chuàng)建它們的用戶ID的映射保存起來，以便知道查詢那個(gè)分片。

他們選擇了Redis后發(fā)現(xiàn)，為了保存這些映射，Redis需要21GB內(nèi)存，這已經(jīng)大于 Amazon EC2 上的 17GB 實(shí)例類型。

后來他們向Redis的核心開發(fā)人員Pieter Noordhuis求助，Pieter建議使用Redis Hash，最終通過巧妙的設(shè)計(jì)，這些映射僅需不到5G的內(nèi)存。

對(duì)于其他緩存（如session），Instagram使用Memcached，當(dāng)時(shí)有6個(gè)實(shí)例。

圖片

數(shù)據(jù)備份

無(wú)論是PostGreSQL還是Redis，都會(huì)使用Amazon EBS經(jīng)常性進(jìn)行數(shù)據(jù)備用

通知和異步任務(wù)

Session: 用戶關(guān)閉了App，但是朋友發(fā)送了一張照片，需要發(fā)送一個(gè)通知。

Instagram的推送服務(wù)用的是 pyapns, 這是一個(gè)開源的、通用的蘋果推送服務(wù)提供商，運(yùn)行非常穩(wěn)定，為Instagram處理了超過10億條推送通知。

Session:用戶非常喜歡這張照片! 他決定在Twitter何Facebook上分享。

在后臺(tái), 任務(wù)被推送到了Gearman, 這個(gè)任務(wù)隊(duì)列會(huì)保存任務(wù)，Instagram有大約200 Python workers 來處理這些任務(wù)。

圖片

監(jiān)控

Session: Uh oh! 服務(wù)器端發(fā)生了錯(cuò)誤，Instagram崩潰了，那三個(gè)程序員需要收到告警，馬上進(jìn)行處理。

Instagram 使用 Sentry這個(gè)開源的應(yīng)用來實(shí)時(shí)監(jiān)控Python錯(cuò)誤。

使用Munin來繪制各種系統(tǒng)指標(biāo)的圖表，如果有任何情況超出正常范圍，就會(huì)向程序員發(fā)出異常告警。Instagram 有一堆自定義 Munin 插件來跟蹤應(yīng)用程序級(jí)別的指標(biāo)，例如每秒發(fā)布的照片、每分鐘注冊(cè)人數(shù)等。

對(duì)于外部服務(wù)的監(jiān)控，使用了Pingdom ，PagerDuty 用于處理事件和通知。