# Facebook 以 190 億美元的價格收購了 WhatsApp 體系結構
> 原文: [http://highscalability.com/blog/2014/2/26/the-whatsapp-architecture-facebook-bought-for-19-billion.html](http://highscalability.com/blog/2014/2/26/the-whatsapp-architecture-facebook-bought-for-19-billion.html)

[Rick Reed](http://www.linkedin.com/pub/rick-reed/2/186/427) 在 3 月即將舉行的演講中,標題為 [,即“十億”和“ B”:在 WhatsApp 上擴展到新的水平](http://lanyrd.com/2014/erlangfactory/scwqrt/) 令人眼前一亮 [WhatsApp](http://en.wikipedia.org/wiki/WhatsApp) 統計信息:
> 擁有數百個節點,數千個內核,數百 TB 的 RAM 的東西,并希望為不久將在全球范圍內成為現實的數十億智能手機提供服務? WhatsApp 上基于 Erlang / FreeBSD 的服務器基礎結構。 在滿足對消息傳遞服務不斷增長的需求方面,我們面臨著許多挑戰,但是隨著我們不斷擴大服務范圍(> 8000 核)和速度(>每秒 70M Erlang 消息), 系統。
但是由于我們還沒有那個話題,讓我們來看一下 Rick Reed 兩年前在 WhatsApp 上的演講: [擴展到數百萬個同時連接](http://vimeo.com/44312354) 。
在 Yahoo 期間,Rick Reed 用 C ++構建了高性能的消息總線,對于高可伸縮性體系結構并不是陌生的。 創始人也是前雅虎人,他們在縮放系統方面經驗不多。 因此,WhatsApp 憑借其擴展能力誠實地表現出來。 而且由于他們的目標是在世界上每部智能手機上都擁有大毛毛的大膽目標,因此幾年之內可能會增加 50 億部手機,因此他們需要充分利用這種體驗。
在我們弄清事實之前,讓我們先討論一下這個絕對迷人的難題:WhatsApp 對 Facebook 可能價值 190 億美元?
作為一名程序員,如果您問我 WhatsApp 是否值那么多,我會回答否定! 它只是通過網絡發送內容。 變得真實。 但是我也是那個認為我們不需要博客平臺的人,因為遠程登錄到您自己的服務器,用 vi 編輯 index.html 文件然后用 HTML 編寫帖子有多難? 我花了相當長的時間才意識到這不是愚蠢的代碼,而是讓所有這些用戶都喜歡并使用您的產品才是最困難的部分。 您無法購買愛情
是什么讓 WhatsApp 如此有價值? 技術? 忽略所有說可以使用 PHP 在一周內編寫 WhatsApp 的人。 那根本不是真的。 就像我們將看到的很酷的技術一樣。 但可以肯定的是,如果他們愿意的話,Facebook 有足夠的能力來構建 WhatsApp。
讓我們看一下功能。 我們知道 WhatsApp 是 [無頭](http://sequoiacapital.tumblr.com/post/77211282835/four-numbers-that-explain-why-facebook-acquired) (無廣告,無頭,無游戲)的產品,其忠實的 [用戶 世界](http://www.wired.com/wiredenterprise/2014/02/whatsapp-rules-rest-world/) 。 它在殘酷的 SMS 收費世界中提供免費短信。 作為一個庇護的美國人,最令我驚訝的是,有多少真實的人使用 WhatsApp 與家人和朋友保持聯系。 因此,當您使用 WhatsApp 時,您認識的人很可能已經在使用它,因為每個人都擁有一部電話,從而緩解了空社交網絡的問題。 它積極地跨平臺運行,因此您認識的每個人都可以使用它,并且它將正常工作。 它“行之有效”是經常使用的短語。 它功能齊全(共享位置,視頻,音頻,圖片,一鍵通,語音消息和照片,閱讀回執,群組聊天,通過 WiFi 發送消息,并且無論收件人是否在線,都可以完成所有操作) 或不)。 它很好地處理了本地語言的顯示。 使用您的手機號碼作為身份并將您的聯系人列表作為社交圖表非常簡單。 無需電子郵件驗證,用戶名和密碼,也不需要信用卡號。 這樣就可以了。
令人印象深刻,但那不值 190 億美元。 其他產品可以在功能上競爭。
[Google 想要](https://www.theinformation.com/Google-Was-Willing-to-Beat-Facebook-s-19-Billion-Offer-for-WhatsApp) 是可能的原因。 這是 [威脅](http://www.forbes.com/sites/parmyolson/2013/12/19/watch-out-facebook-whatsapp-climbs-past-400-million-active-users/) 的威脅。 費用為每位用戶 0.99 美分。 Facebook 是 [絕望的](http://www.foxbusiness.com/technology/2014/02/21/facebook-buying-whatsapp-is-desperate-move/) 。 適用于 [您的電話簿](http://www.theregister.co.uk/2014/02/20/facebook_whatsapp_19bn_buy_also_45_for_your_phonebook/) 。 用于元數據(即使 WhatsApp 不保存任何元數據)。
適用于 [4.5 億活躍用戶](http://sequoiacapital.tumblr.com/post/77211282835/four-numbers-that-explain-why-facebook-acquired) ,用戶基礎每天增長一百萬,潛在的十億用戶。 Facebook 需要其下一個十億用戶使用 WhatApp。 當然,如果有的話,那一定是一部分。 每位用戶約 40 美元的成本似乎并不合理,尤其是在大量庫存支付的情況下。 Facebook 以 [每位用戶 30 美元的價格收購了 Instagram](http://finance.fortune.cnn.com/2012/04/10/why-instagram-is-worth-1b-to-facebook/) 。 Twitter 用戶為 [,價值$ 110](http://www.forbes.com/sites/georgeanders/2013/11/07/a-twitter-user-is-worth-110-facebooks-98-linkedins-93/) 。
本尼迪克特·埃文斯 [很好地證明了](https://www.youtube.com/watch?v=VnhbvS0MBXE) 移動業務是一個價值 1 萬億美元的業務,WhatsApp 正在擾亂該行業的 SMS 部分,全球范圍內 全球短信系統每天僅發送 200 億條短信,每天發送 180 億條短信,從而實現超過 1000 億美元的收入。 從 PC 到幾乎普及的智能手機的過渡發生了根本變化,機遇的規模是一個比 Facebook 正常運營的市場更大的可尋址市場。
但是 Facebook 承諾不會投放廣告,也不會出現干擾,那么勝利在哪里?
[商業使用移動](http://www.happymarketer.com/singapore-is-progressively-doing-business-over-whatsapp-are-you) 的有趣發展。 WhatsApp 用于為項目團隊創建小組對話,風險投資家通過 WhatsApp 進行交易流程對話。
Instagram 用于科威特 [出售綿羊](http://storify.com/cbccommunity/kuwait-entrepreneurs-use-instagram-to-sell-sheep) 。
WhatsApp 的競爭對手微信在 1 月份推出了出租車出租車服務。 在第一個月, [接待了 2100 萬輛出租車](http://www.techinasia.com/wechat-21-million-taxi-rides-booked/) 。
電子商務的未來似乎將通過移動消息傳遞應用程序進行傳播,它一定是電子商務嗎?
不僅僅是使用 WhatsApp 的企業曾經在臺式機或網絡上使用過這些應用程序。 西班牙的警務人員使用 WhatsApp 來抓捕罪犯。 意大利的人們使用它來組織籃球比賽。
出于顯而易見的原因,商務和其他應用程序正在向移動設備轉移。 每個人都擁有移動設備,這些消息傳遞應用程序功能強大,免費且使用便宜。 您不再需要桌面或 Web 應用程序即可完成工作。 許多功能可以疊加在消息傳遞應用程序上。
因此,消息傳遞對 Google 和 Facebook 構成了威脅。 桌面已死。 網絡快要死了。 消息傳遞+移動是 [整個生態系統,它們避開了其渠道](https://news.ycombinator.com/item?id=7282876) 。 消息傳遞已經成為[在移動而不是搜索上的參與中心](http://cubed.fm/2014/02/cubed-episode-18-the-paradigm-shift-of-mobile-engagement-models/),它改變了事物的發現方式以及改變應用程序將贏得未來的本質。 我們不僅是前網頁排名,而且是網絡前。
Facebook 是否需要進入這個市場或變得無關緊要?
隨著移動技術的發展,我們看到了 Facebook 的無人化。 Facebook 的桌面 Web 界面是門戶樣式的界面,可訪問后端提供的所有功能。 它很大,很復雜而且吱吱作響。 誰真正喜歡 Facebook UI?
當 Facebook 轉向移動設備時,他們嘗試了門戶方法,但這種方法無效。 因此,他們采用的策略是更小,更集中,[專用的應用](http://www.theverge.com/2014/1/16/5269664/facebook-plans-suite-of-standalone-mobile-apps-for-2014)。 移動第一! 在小屏幕上,您只能做很多事情。 在移動設備上,找到特殊的應用程序要比在復雜的門戶風格的應用程序中找到深深的菜單要容易得多。
但是 Facebook 向前邁進了一步。 他們不僅在創建專用的應用程序,而且還在提供具有相似功能的多個競爭應用程序,而這些應用程序甚至可能沒有共享后端基礎架構。 我們通過 Messenger 和 WhatsApp,Instagram 和 Facebook 的照片應用程序看到了這一點。 Paper 是 Facebook 的備用界面,功能非常有限,但它做得很好。
康韋定律可能在這里適用。 “設計系統的組織受約束以產生作為這些組織的通信結構副本的設計”的想法。 借助整體后端基礎架構,我們獲得了類似于 Borg 的門戶設計。 向移動的轉變使組織擺脫了這種思維方式。 如果可以構建僅提供一部分 Facebook 基礎結構視圖的應用程序,則可以構建完全不使用 Facebook 基礎結構的應用程序。 而且如果他們不需要 Facebook 的基礎架構,那么它們完全可以免費完全不由 Facebook 構建。 那么,Facebook 到底是什么?
Facebook 首席執行官馬克·扎克伯格(Mark Zuckerberg)有他自己的看法,他在移動世界大會 上的 [主旨演講中說,Facebook 收購 WhatsApp 與該公司密切相關。 Internet.org 愿景:](http://techcrunch.com/2014/02/24/whatsapp-is-actually-worth-more-than-19b-says-facebooks-zuckerberg/)
> 的想法是開發一組免費使用的基本互聯網服務-“互聯網 911”。這些服務可能是社交網絡服務,例如 Facebook,消息服務,搜索或其他 像天氣一樣。向用戶免費提供這些捆綁服務將像各種網關藥物一樣工作-那些如今可能能夠負擔數據服務和電話費用的用戶根本看不出為什么要為這些數據付費 這將為他們提供為何重要的一些背景信息,這將使他們為此類更多的服務付費(或者希望如此)
這是長距離比賽,這是一種游戲,擁有大量有價值的股票,您可以玩。
我們得出結論了嗎? 我不這么認為。 如此驚人的美元金額加上如此微弱的明顯立即回報,以至于長期游戲的解釋實際上確實是有道理的。 我們還處在移動的初期。 沒有人知道未來會是什么樣,所以不必費力強迫未來看起來像您的過去。 Facebook 似乎就是這樣做的。
但是足夠了。 僅 32 位工程師如何支持 4.5 億活躍用戶? 讓我們找出...
## 來源
這里的警告是,我們對所有架構的 WhatsApp 知之甚少。 只是零零碎碎地從各種來源收集而來。 Rick Reed 的主要演講是關于使用 Erlang 時使服務器達到 200 萬連接的優化過程,這很有趣,但這不是完整的體系結構。
* [從 2012 年起縮放至數百萬個同時連接](http://vimeo.com/44312354) ( [幻燈片](http://www.erlang-factory.com/upload/presentations/558/efsf2012-whatsapp-scaling.pdf) ),作者:瑞克·里德
* [Erlang Factory 對 Rick Reed 的采訪](http://mirkobonadei.com/interview-with-rick-reed/)。
* [對來自 Erlang 的 WhatsApp](http://pdincau.wordpress.com/2013/03/27/an-interview-with-eugene-fooksman-erlang/) 的 Eugene Fooksman 的采訪。
* [DLD14-WhatsApp 怎么了? (Jan Koum,David Rowan)](http://www.youtube.com/watch?v=WgAtBTpm6Xk&feature=youtu.be)
* [yowsup](https://github.com/tgalal/yowsup/wiki/Yowsup-Library-Documentation) 是 WhatsApp API 的開源版本。 由于 DMCA 移除,該存儲庫現在不可用[,但是它們確實記錄了 WhatsApp 的一些內部工作原理。 萬物的多樣性。](http://openwhatsapp.org/blog/2014/02/13/mass-dmca-takedowns-whatsapp/)
* 在 *相關文章下列出的一些來源。*
## 統計信息
這些統計信息通常適用于當前系統,而不是我們正在討論的系統。 當前系統的討論將包括有關數據存儲,消息傳遞,元集群以及更多 BEAM / OTP 補丁的黑客技巧。
* 4.5 億活躍用戶,并且達到這個數字的速度超過歷史上任何其他公司。
* 32 位工程師,一名開發人員支持 1400 萬活躍用戶
* 每天在七個平臺上(入站+出站)發送 500 億條消息
* 每天有超過一百萬的用戶注冊
* 為廣告投入了$ 0
* 來自紅杉資本的 6000 萬美元[投資; 紅杉將賺 34 億美元](http://techcrunch.com/2011/04/08/sequoia-whatsapp-funding/)
* 35%是 Facebook 現金中的[被用于交易](http://finance.fortune.cnn.com/2014/02/19/facebook-whatsapp-the-other-numbers/)
* 數百個節點
* > 8000 色
* 數百兆字節的 RAM
* >每秒 70M Erlang 消息
* 在 2011 年,WhatsApp 在具有內存和 CPU 的單臺計算機上實現了 [100 萬個已建立的 tcp 會話](http://blog.whatsapp.com/index.php/2011/09/one-million/) 。 在 2012 年,它被推翻了 [200 萬 tcp 連接](http://blog.whatsapp.com/index.php/2012/01/1-million-is-so-2011/) 。 2013 年,WhatsApp [發了推文](https://twitter.com/WhatsApp/status/286591302185938946) :12 月 31 日,我們創下了新的記錄天:入站 7B 消息,出站 11B 消息=一天處理的總消息量為 180 億 ! 2013 年快樂!!!
## 平臺
### 后端
* Erlang
* FreeBSD
* 偏航,lighttpd
* PHP
* 自定義補丁 [BEAM](http://www.erlang-factory.com/upload/presentations/708/HitchhikersTouroftheBEAM.pdf) (BEAM 類似于 Java 的 JVM,但適用于 Erlang)
* 自定義 XMPP
* 托管[可能位于軟件層](http://www.ip-adress.com/whois/whatsapp.com) 中
### 前端
* 七個客戶端平臺:iPhone,Android,Blackberry,諾基亞 Symbian S60,諾基亞 S40,Windows Phone 、?
* SQLite
### 硬件
* 面向用戶的標準服務器:
* Dual Westmere Hex-core(24 個邏輯 CPU);
* 100GB RAM,SSD;
* 雙網卡(公用面向用戶的網絡,專用后端/分發);
## 產品
* **重點是消息傳遞**。 不管人們身在何處,都可以聯系世界各地的人們,而不必花很多錢。 創始人揚·庫姆(Jan Koum)記得 1992 年與全世界的家人建立聯系有多么困難。
* **隱私** 。 由揚·庫姆(Jan Koum)在烏克蘭度過的成長經歷所塑造,那里沒有什么私人物品。 消息不存儲在服務器上; 聊天記錄未存儲; 目標是盡可能少地了解用戶; 您的姓名和性別未知; 聊天記錄僅在您的手機上。
## 常規
* WhatsApp 服務器幾乎完全在 Erlang 中實現。
* 執行后端消息路由的服務器系統是在 Erlang 中完成的。
* 偉大的成就是,使用很小的服務器空間就可以管理活動用戶的數量。 團隊的共識是,這很大程度上是因為 Erlang。
* 值得一提的是 [Facebook 聊天室](http://www.erlang-factory.com/upload/presentations/31/EugeneLetuchy-ErlangatFacebook.pdf)于 2009 年用 Erlang 編寫,但由于很難找到合格的程序員,他們放棄了它。
* WhatsApp 服務器已從 ejabberd 啟動
* Ejabberd 是用 Erlang 編寫的著名開源 Jabber 服務器。
* 最初選擇是因為它開放,受到開發人員的好評,易于啟動以及 Erlang 對于大型通信系統的長期適用性的保證。
* 接下來的幾年用于重寫和修改 ejabberd 的相當多的部分,包括從 XMPP 切換到內部開發的協議,重組代碼庫和重新設計一些核心組件,并對 Erlang VM 進行很多重要的修改,以 優化服務器性能。
* 為了每天處理 500 億條消息,重點是建立一個可靠的有效系統。 獲利是一個值得關注的問題,它遠未實現。
* 系統運行狀況的主要衡量標準是消息隊列長度。 節點上所有進程的消息隊列長度將得到持續監控,如果它們積壓的積壓超過預設閾值,則會發出警報。 如果一個或多個進程落后,則會發出警報,這將提供指向下一個攻擊瓶頸的指針。
* 通過上載圖像,音頻或視頻以發送到 HTTP 服務器,然后發送指向內容的鏈接及其 Base64 編碼縮略圖(如果適用)來發送多媒體消息。
* 通常每天都會推送一些代碼。 通常,一天要多次,但通常可以避免高峰時段。 Erlang 有助于積極地將修補程序和功能投入生產。 熱加載意味著可以推送更新而無需重啟或流量轉移。 通常,再次通過熱加載可以很快消除錯誤。 系統趨向于松散耦合,這使得很容易以增量方式推出更改。
* Whatsapp 應用程序使用什么協議? WhatsApp 服務器池的 SSL 套接字。 所有消息都會在服務器上排隊,直到客戶端重新連接以檢索消息為止。 消息的成功檢索將發送回 whatsapp 服務器,該服務器將該狀態轉發回原始發件人(它將在消息旁邊顯示為“復選標記”圖標)。 客戶端接受消息后,就會從服務器內存中清除消息
* 在 Whatsapp 中,注冊過程如何在內部進行? WhatsApp 曾經根據電話 IMEI 號碼創建用戶名/密碼。 最近更改了。 WhatsApp 現在使用應用程序的一般請求發送唯一的 5 位數 PIN 碼。 然后,WhatsApp 將 SMS 發送到指定的電話號碼(這意味著 WhatsApp 客戶端不再需要在同一部電話上運行)。 然后,根據密碼,該應用會向 WhatsApp 請求一個唯一的密鑰。 該密鑰用作將來所有呼叫的“密碼”。 (此“永久”密鑰存儲在設備上)。 這也意味著注冊新設備將使舊設備上的密鑰無效。
* Android 上使用了 Google 的推送服務。
* Android 上的更多用戶。 Android 更加令人愉快。 開發人員可以對功能進行原型設計,并在一夜之間將其推銷給數億用戶,如果有問題可以迅速解決。 iOS,不是很多。
## 每服務器 2 百萬個以上的連接
* 經歷了很多用戶增長,這是一個好問題,但這也意味著必須花錢購買更多的硬件,并增加管理所有這些計算機的操作復雜性。
* 需要針對流量增加進行規劃。 例如足球比賽和西班牙或墨西哥的地震。 這些發生在高峰流量負載附近,因此需要有足夠的備用容量來處理高峰和顛簸。 最近的一場足球比賽在每日高峰時出站郵件率激增了 35%。
* 初始服務器裝入是每臺服務器 200 個同時連接。
* 推斷出來將意味著很多服務器都有望實現增長。
* 面對突發負載,服務器很脆弱。 網絡故障和其他問題將會發生。 需要解耦組件,以免大容量情況下變脆。
* 目標是每服務器一百萬個連接。 當它們以 200K 連接運行時,給出了一個宏偉的目標。 運行具有裕量的服務器以允許發生世界性事件,硬件故障以及其他類型的故障,將需要足夠的彈性來處理高使用率水平和故障。
## 用于提高可伸縮性的工具和技術
* 編寫了系統活動報告程序工具(wsar):
* 記錄整個系統的系統統計信息,包括 OS 統計信息,硬件統計信息,BEAM 統計信息。 它是經過構建的,因此很容易從其他系統(例如虛擬內存)中插入指標。 跟蹤 CPU 利用率,總體利用率,用戶時間,系統時間,中斷時間,上下文切換,系統調用,陷阱,已發送/已接收的數據包,所有進程中隊列中消息的總數,繁忙的端口事件,流量速率,輸入/輸出字節 ,排程統計資料,垃圾收集統計資料,收集的字詞等。
* 最初每分鐘運行一次。 由于系統的驅動更加困難,因此需要一秒鐘的輪詢分辨率,因為如果一分鐘內看不到該事件,則該事件將在空間中發生。 真正細粒度的統計數據,以查看一切運行情況。
* CPU 中的硬件性能計數器(pmcstat):
* 以時間百分比查看 CPU 的位置。 可以知道執行仿真器循環花費了多少時間。 在他們的情況下,這是 16%,告訴他們只有 16%的人在執行仿真代碼,因此即使您能夠刪除所有 Erlang 代碼的所有執行時間,也只能節省總運行時間的 16%。 這意味著您應該專注于其他領域以提高系統效率。
* dtrace,內核鎖計數,fprof
* Dtrace 主要用于調試,而不是性能。
* 在 FreeBSD 上修補了 BEAM 以包括 CPU 時間戳。
* 編寫腳本以創建所有進程的匯總視圖,以查看例程在所有時間上所花費的時間。
* 最大的獲勝是在打開鎖定計數的情況下編譯模擬器。
* 一些問題:
* 較早的時候,在垃圾回收例程上花費了更多時間,這被減少了。
* 看到已調離的網絡堆棧有一些問題。
* 大多數問題與模擬器中的鎖爭用有關,這在鎖計數的輸出中表現出強烈的作用。
* 測量:
* 合成工作負載(意味著從您自己的測試腳本生成流量)對于以極大規模調整面向用戶的系統的價值很小。
* 非常適合簡單的界面(例如用戶表),可以盡快生成插入和讀取。
* 如果要在一臺服務器上支持一百萬個連接,則將需要 30 臺主機打開足夠的 IP 端口以生成足夠的連接來僅測試一臺服務器。 對于 200 萬臺服務器,它將占用 60 個主機。 只是很難產生這種規模。
* 在生產期間看到的流量類型很難生成。 可以猜測正常的工作量,但是實際上可以看到網絡事件,世界事件,因為多平臺可以看到客戶端之間行為的變化以及國家/地區的變化。
* Tee 的工作量:
* 進行正常的生產流量并將其通過管道傳輸到單獨的系統。
* 對于可能限制副作用的系統非常有用。 不想散布流量并做會影響用戶永久狀態或導致向用戶發送多條消息的事情。
* Erlang 支持熱加載,因此可以在完整的生產負載下運行,有一個想法,進行編譯,在程序運行時加載更改并立即查看更改的好壞。
* 添加了旋鈕以動態更改生產負載,并查看其如何影響性能。 將跟蹤 sar 輸出,以查看諸如 CPU 使用率,VM 使用率,偵聽隊列溢出以及轉動旋鈕以查看系統如何做出反應。
* 實際生產負荷:
* 終極測試。 同時進行輸入工作和輸出工作。
* 將服務器放入 DNS 兩次,這樣它將獲得正常流量的兩倍或三倍。 由于客戶端不遵守 DNS TTL 且存在延遲,因此造成了 TTL 問題,因此無法迅速做出反應以獲取更多無法處理的流量。
* IPFW。 將流量從一臺服務器轉發到另一臺服務器,這樣可以為主機提供所需客戶端連接的確切數量。 一個錯誤導致內核崩潰,因此無法很好地工作。
* 結果:
* 開始于每個服務器 200K 個并發連接。
* 第一個瓶頸出現在 425K。 系統出現了很多爭論。 工作停止了。 對調度程序進行檢測,以衡量正在執行的工作,休眠或旋轉的工作量。 在負載下,它開始達到休眠狀態,因此整個系統使用了 35-45%的 CPU,但調度程序的利用率為 95%。
* 第一輪修復程序已超過一百萬個連接。
* VM 使用率為 76%。 CPU 占 73%。 BEAM 模擬器以 45%的利用率運行,這與用戶百分比非常接近,這很好,因為該模擬器以用戶身份運行。
* 通常,CPU 利用率不是衡量系統繁忙程度的好方法,因為調度程序使用 CPU。
* 一個月后,解決瓶頸問題的原因是每個服務器有 200 萬個連接。
* BEAM 利用率為 80%,接近 FreeBSD 可能開始分頁的位置。 CPU 大致相同,連接增加了一倍。 調度程序遇到了爭用,但運行得很好。
* 似乎是個停止的好地方,因此開始分析 Erlang 代碼。
* 最初每個連接有兩個 Erlang 進程。 切成一個。
* 使用計時器做了一些事情。
* 每個服務器的連接數達到 280 萬峰值
* 571k pkts / sec,> 200k dist msgs / sec
* 進行了一些內存優化,因此 VM 負載降至 70%。
* 嘗試了 3 百萬個連接,但失敗了。
* 當系統出現問題時,請查看長消息隊列。 單個消息隊列或消息隊列的總和。
* 已添加到 BEAM 工具中有關每個進程的消息隊列統計信息。 發送/接收多少消息,速度有多快。
* 每 10 秒采樣一次,可以看到一個進程在其消息隊列中有 600K 條消息,出隊列率為 40K,延遲為 15 秒。 預計排水時間為 41 秒。
* 調查結果:
* Erlang + BEAM 及其修復-具有出色的 SMP 可擴展性。 幾乎線性的可伸縮性。 卓越。 在 24 路機器上,可以以 85%的 CPU 使用率運行系統,并且可以保持生產負荷。 它可以像這樣整天運行。
* 證明 Erlang 的程序模型。
* 服務器啟動的時間越長,它將積累長期處于運行狀態的連接(大多數情況下處于空閑狀態),因此它可以處理更多的連接,因為這些連接對每個連接而言并不那么忙。
* 競爭是最大的問題。
* 他們的 Erlang 代碼中進行了一些修復,以減少 BEAM 的爭用問題。
* 一些已修補到 BEAM。
* 對工作負載進行分區,因此無需過多地處理處理器。
* 時間鎖定。 每次從端口傳遞消息時,它看起來都會更新一天中的時間,這是所有調度程序中的一個鎖,這意味著所有 CPU 都在打一個鎖。
* 優化使用計時器輪。 刪除了 bif 計時器
* 檢查 IO 時間表在算術上增長。 創建的 VM 崩潰將在各個點重新分配哈希表。 改進以使用表格的幾何分配。
* 添加了寫入文件,該文件占用一個您已經打開的端口,以減少端口爭用。
* Mseg 分配是所有分配器之間的單點爭用。 按調度程序進行。
* 接受連接時有很多端口事務。 設置選項以減少昂貴的端口交互。
* 當消息隊列積壓很大時,垃圾回收將破壞系統的穩定性。 因此,暫停 GC 直到隊列縮小。
* 避免付出一些常見的代價。
* 將 TSE 時間計數器從 FreeBSD 9 反向移植到了 8。讀取計時器更便宜。 快速獲取時間,比購買芯片便宜。
* 從 FreeBSD 9 向后移植 igp 網絡驅動程序,因為在 NIC 鎖定時存在多個隊列問題。
* 增加文件和套接字的數量。
* Pmcstat 顯示花費了大量時間來查找網絡堆棧中的 PCB。 因此,增加哈希表的大小可以使查找更快。
* BEAM 補丁
* 先前提到的檢測補丁。 儀器調度程序可獲取利用率信息,消息隊列的統計信息,睡眠次數,發送速率,消息計數等。可以使用 procinfo 以 Erlang 代碼進行操作,但是連接數百萬時非常慢。
* 統計信息收集非常有效,因此可以在生產中運行。
* 統計信息以 3 個不同的衰減間隔保持:1、10、100 秒間隔。 允許隨著時間推移查看問題。
* 使鎖計數適用于較大的異步線程數。
* 為調試鎖定計數器添加了調試選項。
* 調整
* 將調度程序的喚醒閾值設置為低,因為調度程序會進入睡眠狀態并且永遠不會喚醒。
* 優先使用 mseg 分配器,而不是 malloc。
* 每個調度程序的每個實例都有一個分配器。
* 配置載波大小從大到大。 使 FreeBSD 使用超級頁面。 降低了 TLB 跳動率,并提高了同一 CPU 的吞吐量。
* 以實時優先級運行 BEAM,以使諸如 cron 作業之類的其他事情不會中斷計劃。 防止可能導致重要用戶流量積壓的故障。
* 修補程序可記錄旋轉計數,以便調度程序不會旋轉。
* 失憶癥
* 首選 os:timestamp 而不是 erlang:now。
* 不使用事務,但是使用遠程復制遇到了積壓。 每個表的并行復制可提高吞吐量。
* 實際上還有很多更改。
## 課程
* **優化是一項僅適用于巨魔和工程師的深色球衣工作。** 。 當 Rick 進行他為獲得 200 萬個服務器連接所做的所有更改時,我很麻木。 請注意,編寫工具,運行測試,向后移植代碼,將測試對象添加到幾乎每個堆棧級別,調試系統,查看痕跡,處理非常低級的細節并試圖理解所有內容都需要大量工作 。 這就是消除瓶頸,以將性能和可伸縮性提高到極限的方法。
* **獲取所需的數據**。 **編寫工具。 補丁工具。 添加旋鈕。** Ken 堅持不懈地擴展系統以獲取他們所需的數據,不斷為他們管理和優化系統所需的數據編寫工具和腳本。 盡一切努力。
* **測量。 消除瓶頸。 測試。 重復。** 這就是您的操作方式。
* **二郎巖石!** Erlang 繼續證明其作為通用,可靠,高性能平臺的能力。 盡管就個人而言,所需的所有調優和補丁處理都對該主張造成了懷疑。
* **破解病毒代碼并獲利** **。** 病毒性是一種寓言性的品質,但是正如 WhatsApp 所顯示的,如果您確實發現了,伙計,它值得很多錢。
* **價值和員工人數現已正式離婚** **。** 當今世界上有很多倍增力。 先進的全球電信基礎設施使類似 WhatsApp 的應用成為可能。 如果 WhatsApp 必須建立網絡或電話等,那將永遠不會發生。 強大的廉價硬件和開放源代碼軟件的可用性當然是另一個倍數。 就像在正確的時間,正確的位置,正確的產品出現在正確的購買者面前一樣。
* **這種對用戶想法** **的殘酷關注。** WhatsApp 專注于成為一個簡單的消息傳遞應用程序,而不是游戲網絡,廣告網絡或消失的照片網絡。 那為他們工作。 它指導了他們的無廣告立場,在添加功能時保持應用程序簡單的能力,以及總體而言,它在任何手機上都可以正常工作。
* **簡單原因的限制是可以的** **。** 您的身份與電話號碼相關,因此,如果更改電話號碼,則您的身份將消失。 這非常像計算機。 但這確實使整個系統的設計更加簡單。
* **年齡不是沒有** **。** 如果是年齡歧視導致 WhatsApp 聯合創始人布萊恩·阿克頓(Brian Acton)在 2009 年無法在 Twitter 和 Facebook 上找到工作,那真可恥,可恥,可恥。
* **簡單開始,然后自定義** **。** 最初啟動聊天時,服務器端基于 ejabberd。 此后已被完全重寫,但這是向 Erlang 方向邁出的第一步。 在最初的用例中,Erlang 的可伸縮性,可靠性和可操作性方面的經驗導致了越來越廣泛的使用。
* **保持服務器計數低** **。** 不斷努力將服務器數量保持在盡可能低的水平,同時為產生短期使用高峰的事件留有足夠的空間。 分析和優化,直到這些工作受到收益遞減的影響,然后再部署更多硬件。
* **故意過度配置硬件。** 這可確保用戶在慶祝活動期間獲得不間斷的服務,并且員工能夠享受假期,而不必花費所有時間解決過載問題。
* **當您收取費用** **時,增長停滯。** 當免費使用 WhatsApp 時,增長非常快,早期每天有 10,000 次下載。 然后,當切換到付費時,每天的費用下降到 1,000。 到了年底,在添加了圖片消息后,他們決定收取一次性的下載費用,后來又改為年度付款。
* **靈感來自最陌生的地方** **。** 忘記了 Skype 帳戶上的用戶名和密碼的經驗驅使人們使應用程序“正常運行”。
## 相關文章
* [關于黑客新聞](https://news.ycombinator.com/item?id=7306066)
* [主題演講:Benedict Evans-InContext 2014](https://www.youtube.com/watch?v=VnhbvS0MBXE) (相關的 [幻燈片](http://ben-evans.com/presentations/2013/11/5/mobile-is-eating-the-world-autumn-2013-edition) )
* [Whatsapp 和 190 億美元](http://ben-evans.com/benedictevans/2014/2/19/whatsapp-and-19bn) ,作者:Benedict Evans
* [WhatsApp 的博客:一家市值 160 億美元的初創企業的精彩日記](http://www.slideshare.net/socialmarketingfella/the-diary-of-a-16-billion-startup-31457350) -Andre Bourque 的精彩活動時間表。
* Rick 在 GitHub 上對 [Erlang 的更改](https://github.com/reedr)
* [WhatsApp 博客](http://blog.whatsapp.com/) :
* [一百萬!](http://blog.whatsapp.com/index.php/2011/09/one-million/) ( [Hacker News](https://news.ycombinator.com/item?id=3028547) )
* [一百萬就是 2011 年](http://blog.whatsapp.com/index.php/2012/01/1-million-is-so-2011/)
* [4 億個故事](http://blog.whatsapp.com/index.php/2013/12/400-million-stories/)
* [WhatsApp:內幕](http://www.wired.co.uk/news/archive/2014-02/19/whatsapp-exclusive)
* [WhatsApp](http://www.whatsapp.com/opensource/) 使用的開源項目
* [Whatsapp,Facebook,Erlang 和實時消息傳遞:一切都始于 ejabberd](http://blog.process-one.net/whatsapp-facebook-erlang-and-realtime-messaging-it-all-started-with-ejabberd/)
* Quora: [WhatsApp 如何工作?](http://www.quora.com/How-does-WhatsApp-work-1) , [WhatsApp 如何在移動網絡中工作?](http://www.quora.com/How-does-WhatsApp-work-out-of-mobile-network) , [WhatsApp 如何成長得如此之大?](http://www.quora.com/WhatsApp-Messenger/How-did-WhatsApp-grow-so-big)
* [WhatsApp 已損壞,實際上已損壞](http://fileperms.org/whatsapp-is-broken-really-broken/) -早期的安全問題
* [WhatsApp 首席執行官 Jan Koum Hates Advertising 和 Tech Rumor Mill(全潛視頻)](http://allthingsd.com/20130510/whatsapp-ceo-jan-koum-hates-advertising-and-the-tech-rumor-mill-full-dive-video/)
* [新加坡正在逐步通過 WhatsApp 開展業務。 你是?](http://www.happymarketer.com/singapore-is-progressively-doing-business-over-whatsapp-are-you)
* [四個數字解釋了 Facebook 為什么收購 WhatsApp](http://sequoiacapital.tumblr.com/post/77211282835/four-numbers-that-explain-why-facebook-acquired)
* [馬克·扎克伯格的公告](https://www.facebook.com/zuck/posts/10101272463589561?stream_ref=10)
* [帶有 Mochiweb 的百萬用戶彗星應用程序,第 3 部分](http://www.metabrew.com/article/a-million-user-comet-application-with-mochiweb-part-3)
* [Erlang 內部,WhatsApp 成功背后的罕見編程語言](http://www.fastcolabs.com/3026758/inside-erlang-the-rare-programming-language-behind-whatsapps-success)
* [Facebook 的扎克伯格說,WhatsApp 的價值實際上超過 19B 美元,并且是 Internet.org 達成了交易](http://techcrunch.com/2014/02/24/whatsapp-is-actually-worth-more-than-19b-says-facebooks-zuckerberg/)
* [Facebook 以 190 億美元收購 Whatsapp:價值與定價觀點](http://aswathdamodaran.blogspot.in/2014/02/facebook-buys-whatsapp-for-19-billion.html)
* [Facebook 的 190 億美元渴望,馬克·扎克伯格(Mark Zuckerberg)解釋](http://www.forbes.com/sites/georgeanders/2014/02/19/facebook-justifies-19-billion-by-awe-at-whatsapp-growth/)
* [恕我直言:從 WhatsApp 汲取的教訓](http://blog.mindcrime-ilab.de/2012/12/16/imho-lessons-learned-from-whatsapp/)
* [您可能不會使用 WhatsApp,但世界其他地區肯定會使用](http://www.wired.com/wiredenterprise/2014/02/whatsapp-rules-rest-world/)
* [WhatsApp 的故事挑戰了山谷的一些傳統智慧](http://techcrunch.com/2014/02/23/the-whatsapp-story-challenges-the-valleys-conventional-wisdom/)
* [根據 Jan Koum(視頻)的說法,WhatsApp 做了正確的事](http://recode.net/2014/02/20/what-whatsapp-did-right-according-to-jan-koum-video/)
* [Facebook 為什么要購買 WhatsApp?](http://kottke.org/14/02/why-did-facebook-buy-whatsapp)
* [有人可以向我解釋 WhatsApp 的估值嗎?](http://www.linkedin.com/today/post/article/20140220134541-79695780-can-someone-explain-whatsapp-s-valuation-to-me)
* [Google 對 WhatsApp 的不尋常出價](https://www.theinformation.com/Google-s-Unusual-Offer-to-WhatsApp) 。
我理解正確嗎? WS 正在一臺唯一的服務器上運行? 真? 那簡直是瘋了,O_o 正常,它總是掉下來...
伊凡,你是怎么得出這個結論的?
是從哪兒說的?
> 數百個節點
> > 8000 個內核
> 數百兆字節的 RAM
謝謝! 這是我今年(2014 年)閱讀的最好的,最有趣,最令人鼓舞和最具挑戰性的文章之一。 我喜歡看到其他人所做的既平凡(或使復雜的平凡)又令人驚奇。 我的團隊將繼續使用 Java,但是看到另一個團隊不僅在財務上如此成功,而且能夠滿足數億用戶的需求是令人鼓舞的。 太棒了! 謝謝!
800 萬資金是錯誤的。 他們籌集了大約六千萬。
yowsup 在這里可用:https://github.com/nprasan/yowsup
我贊同 Kevin 的評論-一篇非常出色的文章。 實際上在 1 篇文章中有 3 篇很棒的文章:移動應用程序市場分析,深入的技術探討,一般課程。 非常感謝! 會在這里上班...
您說:“盡管就個人而言,所需的所有調優和修補工作都對該主張造成了一些懷疑。” 這種懷疑似乎基于 Erlang / OTP 靜止不動的假設,而事實上一段時間前 WhatsApp 的 Erlang / OTP 補丁已被并入 Erlang / OTP 中。 Erlang / OTP 是開源的,社區補丁很常見,愛立信的 OTP 團隊在社區的幫助下繼續在功能,性能和可伸縮性方面推動平臺向前發展。 我相信 WhatsApp 最初是在 Erlang / OTP 的 R14B 版本上開發補丁的,但是下個月(2014 年 3 月),OTP 團隊將發布 17.0 版,再次達到了每年生產 Erlang / OTP 的新主要版本的正常時間表。
很棒的帖子!
時間過長
到目前為止,我幾個月來讀的最好的文章。
做得好,可擴展性高。
首先,很棒的文章。 whatsapp 的工程設計以及他們對細節的關注給我留下了深刻的印象。 擁有內部外觀很酷。
但是,對于涉及“ 200 萬個 TCP 連接”的測試,我感到困惑。 我不清楚這到底是什么意思。 我的理解是,無效的 TCP 連接理論上只需要 R??AM,而對 CPU 或帶寬的影響很小。
如果是這樣,我很難懷疑該基準所達到的目標。 在大多數情況下,RAM 不是限制因素嗎? 我不清楚 Erlang 在這里有什么特別的幫助,或者說 200 萬個連接測試的實際含義是,CPU 和帶寬是否應該處于閑置狀態。 在演示文稿中,聽起來好像 CPU 的使用率為 85%,但我不清楚 CPU 的實際功能。 誰能啟發我?
優秀的文章。
談到隱私,“郵件未存儲在服務器上”
不對
至少,視頻和 img 消息將發送到服務器,然后進行壓縮,然后轉發給您的聯系人。
如果 whatsapp 在此之后將其刪除,我相信這取決于 NSA。
很棒的文章! 感謝您分享。
優秀的文章...! 感謝分享。
絕對驚人的文章! 我喜歡它,每一行,每一句話!!!
偉大的偉大偉大的職位。 我在 2009 年從事類似項目的工作,我知道所有這些技術講座,并且帖子中的細節非常詳盡。 我非常感謝作為技術部分的商業觀點和經驗教訓...很好的結論。
值得花時間閱讀。 謝謝。
不要相信會告訴您的人會花費 30 臺主機打開足夠的 IP 端口來生成足夠的連接來測試具有一百萬個并發連接的服務器。 這是完全錯誤的,并且僅僅是對知識缺失的證明。 ;)
已收藏。 這是非常棒的信息,感謝您的分享,
由于不熟悉此類工程的尖端人員,這是一本有趣的文章。
誰能回答一個愚蠢的問題?
我很欣賞從單個服務器中獲得如此高的效率必然需要大量的工作,這是一項巨大的成就,但是為什么這樣的消息傳遞應用程序原則上會帶來巨大的可擴展性挑戰? 為什么最小數量的服務器很重要? 在我的手機上看到自己的小 WhatsApp 氣泡時,我經常只與約 20 個人聯系,很少能以每小時 4 個以上的速度進行完整的對話。
因此,如果我不得不從視覺上代表整個網絡,我會猜想有很多自然的分區,而不是像 bittorrent 這樣的大規模且不可預測的互連。 并不是說這將是一個小的編程任務,但是原則上,通用框架不能通過遵循然后預測用戶的自然分區來將連接分配給服務器。 例如。 我和我的倫敦哥們都亂倫,與圣保羅的交通突然中斷為零。
因此,一旦最佳地分配了連接,服務器之間的剩余最小流量就不會成為問題-尤其是當您看到我突然嘗試與 Sao Paolo 進行實時聊天時,您將我們切換到同一臺服務器進行一次 。
我不是在問為什么 WhatsApp 沒有嘗試構建這種復雜的東西,而是我是否對社交網絡連接的預測分區的 Hadoop 需求未得到滿足是正確的? (是的,我意識到這比 hadoop 要復雜得多)
當客戶端收到消息后,消息將被刪除,這聽起來很完美,但是如果出現群發消息怎么辦? 它會一直持續到小組的所有成員都收到嗎?
不錯的文章。 讓您欣賞系統的復雜性,并像 Whatsapp 一樣被我們視為日常用戶。
嘿,這是很酷的文章。
我有一個問題,我還沒有完全明白。 那么,客戶端建立的每個套接字連接都將在一個單獨的過程中結束嗎? 如果是這樣,那么服務器如何創建一百萬個:/進程中的消息隊列如何一次可能達到 20 萬條消息?
謝謝
Facebook 沒有購買 Whatsapp 的建筑,而是購買了 10 億以上的昏迷用戶
- LiveJournal 體系結構
- mixi.jp 體系結構
- 友誼建筑
- FeedBurner 體系結構
- GoogleTalk 架構
- ThemBid 架構
- 使用 Amazon 服務以 100 美元的價格構建無限可擴展的基礎架構
- TypePad 建筑
- 維基媒體架構
- Joost 網絡架構
- 亞馬遜建筑
- Fotolog 擴展成功的秘訣
- 普恩斯的教訓-早期
- 論文:Wikipedia 的站點內部,配置,代碼示例和管理問題
- 擴大早期創業規模
- Feedblendr 架構-使用 EC2 進行擴展
- Slashdot Architecture-互聯網的老人如何學會擴展
- Flickr 架構
- Tailrank 架構-了解如何在整個徽標范圍內跟蹤模因
- Ruby on Rails 如何在 550k 網頁瀏覽中幸存
- Mailinator 架構
- Rackspace 現在如何使用 MapReduce 和 Hadoop 查詢 TB 的數據
- Yandex 架構
- YouTube 架構
- Skype 計劃 PostgreSQL 擴展到 10 億用戶
- 易趣建筑
- FaceStat 的禍根與智慧贏得了勝利
- Flickr 的聯合會:每天進行數十億次查詢
- EVE 在線架構
- Notify.me 體系結構-同步性
- Google 架構
- 第二人生架構-網格
- MySpace 體系結構
- 擴展 Digg 和其他 Web 應用程序
- Digg 建筑
- 在 Amazon EC2 中部署大規模基礎架構的六個經驗教訓
- Wolfram | Alpha 建筑
- 為什么 Facebook,Digg 和 Twitter 很難擴展?
- 全球范圍擴展的 10 個 eBay 秘密
- BuddyPoke 如何使用 Google App Engine 在 Facebook 上擴展
- 《 FarmVille》如何擴展以每月收獲 7500 萬玩家
- Twitter 計劃分析 1000 億條推文
- MySpace 如何與 100 萬個并發用戶一起測試其實時站點
- FarmVille 如何擴展-后續
- Justin.tv 的實時視頻廣播架構
- 策略:緩存 404 在服務器時間上節省了洋蔥 66%
- Poppen.de 建筑
- MocoSpace Architecture-一個月有 30 億個移動頁面瀏覽量
- Sify.com 體系結構-每秒 3900 個請求的門戶
- 每月將 Reddit 打造為 2.7 億頁面瀏覽量時汲取的 7 個教訓
- Playfish 的社交游戲架構-每月有 5000 萬用戶并且不斷增長
- 擴展 BBC iPlayer 的 6 種策略
- Facebook 的新實時消息系統:HBase 每月可存儲 135 億條消息
- Pinboard.in Architecture-付費玩以保持系統小巧
- BankSimple 迷你架構-使用下一代工具鏈
- Riak 的 Bitcask-用于快速鍵/值數據的日志結構哈希表
- Mollom 體系結構-每秒以 100 個請求殺死超過 3.73 億個垃圾郵件
- Wordnik-MongoDB 和 Scala 上每天有 1000 萬個 API 請求
- Node.js 成為堆棧的一部分了嗎? SimpleGeo 說是的。
- 堆棧溢出體系結構更新-現在每月有 9500 萬頁面瀏覽量
- Medialets 體系結構-擊敗艱巨的移動設備數據
- Facebook 的新實時分析系統:HBase 每天處理 200 億個事件
- Microsoft Stack 是否殺死了 MySpace?
- Viddler Architecture-每天嵌入 700 萬個和 1500 Req / Sec 高峰
- Facebook:用于擴展數十億條消息的示例規范架構
- Evernote Architecture-每天有 900 萬用戶和 1.5 億個請求
- TripAdvisor 的短
- TripAdvisor 架構-4,000 萬訪客,200M 動態頁面瀏覽,30TB 數據
- ATMCash 利用虛擬化實現安全性-不變性和還原
- Google+是使用您也可以使用的工具構建的:閉包,Java Servlet,JavaScript,BigTable,Colossus,快速周轉
- 新的文物建筑-每天收集 20 億多個指標
- Peecho Architecture-鞋帶上的可擴展性
- 標記式架構-擴展到 1 億用戶,1000 臺服務器和 50 億個頁面視圖
- 論文:Akamai 網絡-70 個國家/地區的 61,000 臺服務器,1,000 個網絡
- 策略:在 S3 或 GitHub 上運行可擴展,可用且廉價的靜態站點
- Pud 是反堆棧-Windows,CFML,Dropbox,Xeround,JungleDisk,ELB
- 用于擴展 Turntable.fm 和 Labmeeting 的數百萬用戶的 17 種技術
- StackExchange 體系結構更新-平穩運行,Amazon 4x 更昂貴
- DataSift 體系結構:每秒進行 120,000 條推文的實時數據挖掘
- Instagram 架構:1400 萬用戶,1 TB 的照片,數百個實例,數十種技術
- PlentyOfFish 更新-每月 60 億次瀏覽量和 320 億張圖片
- Etsy Saga:從筒倉到開心到一個月的瀏覽量達到數十億
- 數據范圍項目-6PB 存儲,500GBytes / sec 順序 IO,20M IOPS,130TFlops
- 99designs 的設計-數以千萬計的綜合瀏覽量
- Tumblr Architecture-150 億頁面瀏覽量一個月,比 Twitter 更難擴展
- Berkeley DB 體系結構-NoSQL 很酷之前的 NoSQL
- Pixable Architecture-每天對 2000 萬張照片進行爬網,分析和排名
- LinkedIn:使用 Databus 創建低延遲更改數據捕獲系統
- 在 30 分鐘內進行 7 年的 YouTube 可擴展性課程
- YouPorn-每天定位 2 億次觀看
- Instagram 架構更新:Instagram 有何新功能?
- 搜索技術剖析:blekko 的 NoSQL 數據庫
- Pinterest 體系結構更新-1800 萬訪問者,增長 10 倍,擁有 12 名員工,410 TB 數據
- 搜索技術剖析:使用組合器爬行
- iDoneThis-從頭開始擴展基于電子郵件的應用程序
- StubHub 體系結構:全球最大的票務市場背后的驚人復雜性
- FictionPress:在網絡上發布 600 萬本小說
- Cinchcast 體系結構-每天產生 1,500 小時的音頻
- 棱柱架構-使用社交網絡上的機器學習來弄清您應該在網絡上閱讀的內容
- 棱鏡更新:基于文檔和用戶的機器學習
- Zoosk-實時通信背后的工程
- WordPress.com 使用 NGINX 服務 70,000 req / sec 和超過 15 Gbit / sec 的流量
- 史詩般的 TripAdvisor 更新:為什么不在云上運行? 盛大的實驗
- UltraDNS 如何處理數十萬個區域和數千萬條記錄
- 更簡單,更便宜,更快:Playtomic 從.NET 遷移到 Node 和 Heroku
- Spanner-關于程序員使用 NoSQL 規模的 SQL 語義構建應用程序
- BigData 使用 Erlang,C 和 Lisp 對抗移動數據海嘯
- 分析數十億筆信用卡交易并在云中提供低延遲的見解
- MongoDB 和 GridFS 用于內部和內部數據中心數據復制
- 每天處理 1 億個像素-少量競爭會導致大規模問題
- DuckDuckGo 體系結構-每天進行 100 萬次深度搜索并不斷增長
- SongPop 在 GAE 上可擴展至 100 萬活躍用戶,表明 PaaS 未通過
- Iron.io 從 Ruby 遷移到 Go:減少了 28 臺服務器并避免了巨大的 Clusterf ** ks
- 可汗學院支票簿每月在 GAE 上擴展至 600 萬用戶
- 在破壞之前先檢查自己-鱷梨的建筑演進的 5 個早期階段
- 縮放 Pinterest-兩年內每月從 0 到十億的頁面瀏覽量
- Facebook 的網絡秘密
- 神話:埃里克·布魯爾(Eric Brewer)談銀行為什么不是堿-可用性就是收入
- 一千萬個并發連接的秘密-內核是問題,而不是解決方案
- GOV.UK-不是你父親的書庫
- 縮放郵箱-在 6 周內從 0 到 100 萬用戶,每天 1 億條消息
- 在 Yelp 上利用云計算-每月訪問量為 1.02 億,評論量為 3900 萬
- 每臺服務器將 PHP 擴展到 30,000 個并發用戶的 5 條 Rockin'Tips
- Twitter 的架構用于在 5 秒內處理 1.5 億活躍用戶,300K QPS,22 MB / S Firehose 以及發送推文
- Salesforce Architecture-他們每天如何處理 13 億筆交易
- 擴大流量的設計決策
- ESPN 的架構規模-每秒以 100,000 Duh Nuh Nuhs 運行
- 如何制作無限可擴展的關系數據庫管理系統(RDBMS)
- Bazaarvoice 的架構每月發展到 500M 唯一用戶
- HipChat 如何使用 ElasticSearch 和 Redis 存儲和索引數十億條消息
- NYTimes 架構:無頭,無主控,無單點故障
- 接下來的大型聲音如何使用 Hadoop 數據版本控制系統跟蹤萬億首歌曲的播放,喜歡和更多內容
- Google 如何備份 Internet 和數十億字節的其他數據
- 從 HackerEarth 用 Apache 擴展 Python 和 Django 的 13 個簡單技巧
- AOL.com 體系結構如何發展到 99.999%的可用性,每天 800 萬的訪問者和每秒 200,000 個請求
- Facebook 以 190 億美元的價格收購了 WhatsApp 體系結構
- 使用 AWS,Scala,Akka,Play,MongoDB 和 Elasticsearch 構建社交音樂服務
- 大,小,熱還是冷-條帶,Tapad,Etsy 和 Square 的健壯數據管道示例
- WhatsApp 如何每秒吸引近 5 億用戶,11,000 內核和 7,000 萬條消息
- Disqus 如何以每秒 165K 的消息和小于 0.2 秒的延遲進行實時處理
- 關于 Disqus 的更新:它仍然是實時的,但是 Go 摧毀了 Python
- 關于 Wayback 機器如何在銀河系中存儲比明星更多的頁面的簡短說明
- 在 PagerDuty 遷移到 EC2 中的 XtraDB 群集
- 擴展世界杯-Gambify 如何與 2 人組成的團隊一起運行大型移動投注應用程序
- 一點點:建立一個可處理每月 60 億次點擊的分布式系統的經驗教訓
- StackOverflow 更新:一個月有 5.6 億次網頁瀏覽,25 臺服務器,而這一切都與性能有關
- Tumblr:哈希處理每秒 23,000 個博客請求的方式
- 使用 HAProxy,PHP,Redis 和 MySQL 處理 10 億個請求的簡便方法來構建成長型啟動架構
- MixRadio 體系結構-兼顧各種服務
- Twitter 如何使用 Redis 進行擴展-105TB RAM,39MM QPS,10,000 多個實例
- 正確處理事情:通過即時重放查看集中式系統與分散式系統
- Instagram 提高了其應用程序的性能。 這是如何做。
- Clay.io 如何使用 AWS,Docker,HAProxy 和 Lots 建立其 10 倍架構
- 英雄聯盟如何將聊天擴大到 7000 萬玩家-需要很多小兵。
- Wix 的 Nifty Architecture 技巧-大規模構建發布平臺
- Aeron:我們真的需要另一個消息傳遞系統嗎?
- 機器:惠普基于憶阻器的新型數據中心規模計算機-一切仍在變化
- AWS 的驚人規模及其對云的未來意味著什么
- Vinted 體系結構:每天部署數百次,以保持繁忙的門戶穩定
- 將 Kim Kardashian 擴展到 1 億個頁面
- HappyPancake:建立簡單可擴展基金會的回顧
- 阿爾及利亞分布式搜索網絡的體系結構
- AppLovin:通過每天處理 300 億個請求向全球移動消費者進行營銷
- Swiftype 如何以及為何從 EC2 遷移到真實硬件
- 我們如何擴展 VividCortex 的后端系統
- Appknox 架構-從 AWS 切換到 Google Cloud
- 阿爾及利亞通往全球 API 的憤怒之路
- 阿爾及利亞通往全球 API 步驟的憤怒之路第 2 部分
- 為社交產品設計后端
- 阿爾及利亞通往全球 API 第 3 部分的憤怒之路
- Google 如何創造只有他們才能創造的驚人的數據中心網絡
- Autodesk 如何在 Mesos 上實施可擴展事件
- 構建全球分布式,關鍵任務應用程序:Trenches 部分的經驗教訓 1
- 構建全球分布式,關鍵任務應用程序:Trenches 第 2 部分的經驗教訓
- 需要物聯網嗎? 這是美國一家主要公用事業公司從 550 萬米以上收集電力數據的方式
- Uber 如何擴展其實時市場平臺
- 優步變得非常規:使用司機電話作為備份數據中心
- 在不到五分鐘的時間里,Facebook 如何告訴您的朋友您在災難中很安全
- Zappos 的網站與 Amazon 集成后凍結了兩年
- 為在現代時代構建可擴展的有狀態服務提供依據
- 細分:使用 Docker,ECS 和 Terraform 重建基礎架構
- 十年 IT 失敗的五個教訓
- Shopify 如何擴展以處理來自 Kanye West 和 Superbowl 的 Flash 銷售
- 整個 Netflix 堆棧的 360 度視圖
- Wistia 如何每小時處理數百萬個請求并處理豐富的視頻分析
- Google 和 eBay 關于構建微服務生態系統的深刻教訓
- 無服務器啟動-服務器崩潰!
- 在 Amazon AWS 上擴展至 1100 萬以上用戶的入門指南
- 為 David Guetta 建立無限可擴展的在線錄制活動
- Tinder:最大的推薦引擎之一如何決定您接下來會看到誰?
- 如何使用微服務建立財產管理系統集成
- Egnyte 體系結構:構建和擴展多 PB 分布式系統的經驗教訓
- Zapier 如何自動化數十億個工作流自動化任務的旅程
- Jeff Dean 在 Google 進行大規模深度學習
- 如今 Etsy 的架構是什么樣的?
- 我們如何在 Mail.Ru Cloud 中實現視頻播放器
- Twitter 如何每秒處理 3,000 張圖像
- 每天可處理數百萬個請求的圖像優化技術
- Facebook 如何向 80 萬同時觀看者直播
- Google 如何針對行星級基礎設施進行行星級工程設計?
- 為 Mail.Ru Group 的電子郵件服務實施反垃圾郵件的貓捉老鼠的故事,以及 Tarantool 與此相關的內容
- The Dollar Shave Club Architecture Unilever 以 10 億美元的價格被收購
- Uber 如何使用 Mesos 和 Cassandra 跨多個數據中心每秒管理一百萬個寫入
- 從將 Uber 擴展到 2000 名工程師,1000 個服務和 8000 個 Git 存儲庫獲得的經驗教訓
- QuickBooks 平臺
- 美國大選期間城市飛艇如何擴展到 25 億個通知
- Probot 的體系結構-我的 Slack 和 Messenger Bot 用于回答問題
- AdStage 從 Heroku 遷移到 AWS
- 為何將 Morningstar 遷移到云端:降低 97%的成本
- ButterCMS 體系結構:關鍵任務 API 每月可處理數百萬個請求
- Netflix:按下 Play 會發生什么?
- ipdata 如何以每月 150 美元的價格為來自 10 個無限擴展的全球端點的 2500 萬個 API 調用提供服務
- 每天為 1000 億個事件賦予意義-Teads 的 Analytics(分析)管道
- Auth0 體系結構:在多個云提供商和地區中運行
- 從裸機到 Kubernetes
- Egnyte Architecture:構建和擴展多 PB 內容平臺的經驗教訓
- 縮放原理
- TripleLift 如何建立 Adtech 數據管道每天處理數十億個事件
- Tinder:最大的推薦引擎之一如何決定您接下來會看到誰?
- 如何使用微服務建立財產管理系統集成
- Egnyte 體系結構:構建和擴展多 PB 分布式系統的經驗教訓
- Zapier 如何自動化數十億個工作流自動化任務的旅程
- Jeff Dean 在 Google 進行大規模深度學習
- 如今 Etsy 的架構是什么樣的?
- 我們如何在 Mail.Ru Cloud 中實現視頻播放器
- Twitter 如何每秒處理 3,000 張圖像
- 每天可處理數百萬個請求的圖像優化技術
- Facebook 如何向 80 萬同時觀看者直播
- Google 如何針對行星級基礎設施進行行星級工程設計?
- 為 Mail.Ru Group 的電子郵件服務實施反垃圾郵件的貓捉老鼠的故事,以及 Tarantool 與此相關的內容
- The Dollar Shave Club Architecture Unilever 以 10 億美元的價格被收購
- Uber 如何使用 Mesos 和 Cassandra 跨多個數據中心每秒管理一百萬個寫入
- 從將 Uber 擴展到 2000 名工程師,1000 個服務和 8000 個 Git 存儲庫獲得的經驗教訓
- QuickBooks 平臺
- 美國大選期間城市飛艇如何擴展到 25 億條通知
- Probot 的體系結構-我的 Slack 和 Messenger Bot 用于回答問題
- AdStage 從 Heroku 遷移到 AWS
- 為何將 Morningstar 遷移到云端:降低 97%的成本
- ButterCMS 體系結構:關鍵任務 API 每月可處理數百萬個請求
- Netflix:按下 Play 會發生什么?
- ipdata 如何以每月 150 美元的價格為來自 10 個無限擴展的全球端點的 2500 萬個 API 調用提供服務
- 每天為 1000 億個事件賦予意義-Teads 的 Analytics(分析)管道
- Auth0 體系結構:在多個云提供商和地區中運行
- 從裸機到 Kubernetes
- Egnyte Architecture:構建和擴展多 PB 內容平臺的經驗教訓