# 可汗學院支票簿每月在 GAE 上擴展至 600 萬用戶
> 原文: [http://highscalability.com/blog/2013/4/1/khan-academy-checkbook-scaling-to-6-million-users-a-month-on.html](http://highscalability.com/blog/2013/4/1/khan-academy-checkbook-scaling-to-6-million-users-a-month-on.html)
<iframe align="right" allowfullscreen="" frameborder="0" height="141" src="http://www.youtube.com/embed/r7hC0oVPTVs" width="250"></iframe>
[可汗學院](https://www.khanacademy.org/) 是由 [Salman Khan](https://www.khanacademy.org/talks-and-interviews/key-media-pieces/v/salman-khan-talk-at-ted-2011--from-ted-com) 創立的一家非營利性公司,其目標是向所有人,任何地方,任何時間提供免費的世界一流的教育。 那是很多知識。 長期以來,我受汗學院的啟發和迷住,我真的很想知道他們打算如何去做。 [可汗學院的首席開發人員 Ben Kamens](https://twitter.com/kamens) 在一次采訪中給出了令人驚訝的答案:[如何將您的初創企業擴展到數百萬的用戶](http://www.youtube.com/watch?v=r7hC0oVPTVs)。
**簡短答案**:組建一支強大的團隊,專注于功能,讓 [Google App Engine](https://appengine.google.com/) 負責。
在采訪中,有些人似乎被 GAE 的全部愛拒之門外。 部分原因在于,面試官是 Google App Engine 的開發倡導者 Fred Sauer,因此兩者之間有一定程度的熟悉度。 但是最大的原因是,由于您應該喜歡 GAE 的所有原因,他們真的很喜歡 GAE。 沒關系。 在這個時代,您可以自由選擇任何平臺。
**最大的驚喜**:
* “ 60 分鐘”上的個人資料所帶來的訪問量比 TechChrunch,HackerNews 和其他所有內容的總和還多。 舊媒體還沒有死。
第一部分**最喜歡**:
* GAE 是所有典型可擴展性問題的抽象,讓您專注于業務問題。 所有 [抽象泄漏](http://www.joelonsoftware.com/articles/LeakyAbstractions.html) ,無論您選擇什么,都將不得不處理問題,但是您正在選擇要處理的問題類型 根據您選擇的平臺。 這全都在于了解您要進行的權衡。
以下是我對訪談的主要要點:
* 汗學院(Khan Academy)每月大約有 600 萬用戶,也許是 1500 萬注冊用戶。 為了進行比較,Coursera [共有 600 萬用戶](http://news.illinois.edu/ii/12/1115/coursera_daphne_koller.html) ,但我不確定這些用戶的活躍程度。
* 演變:
* 最初,創建了視頻以支持學習如何解決數學問題。 這些視頻托管在 YouTube 上。 YouTube 沒有擴展問題。
* 但是 YouTube 不是交互式的,他們要做的很大一部分是向用戶展示學習樹,進行測驗,管理結果等。因此,他們首先嘗試了一個基于 Java 的自托管網站,但該網站被壓碎了。 加載。
* 然后切換到 GAE。 可汗學院與許多初創公司不同,因為它已經在 YouTube 上建立了一個現成的受眾群體。 數十萬用戶從 YouTube 切換到 GAE。 他們緩慢地建立了可以處理新用戶的非 YouTube 網站的基礎。 在 YouTube 上引導客戶可能是一個不錯的一般策略。
* 有很多新聞報道,整個事情如雪球般滾滾,而且還在不斷增長。
* 為什么選擇 GAE?
* 對于任何一家初創公司來說,不要使用 GAE 或 EC2 之類的提供商都是沒有道理的。 它們有助于解決許多您不需要解決的可伸縮性問題。 輕而易舉。 如果您吸引了很多注意力,則可以立即投入更多資金并擴大規模。
* Spectrum:您想要開箱即用的控制權與可伸縮性的要求是多少? 控制得越多,您越有可能朝自己的腳開槍,做錯事。
* GAE 為您提供了開箱即用的可擴展性。 只要插入信用卡,就不會有很多可擴展性問題。 這為我提出了一個要點:他們如何負擔 GAE? 有趣的是,非營利性經濟學可以使人們擺脫對每個新客戶獲取成本的關注,而不必擔心貨幣化策略。
* 使用 AWS,您必須更多地玩游戲,知道如何處理實例,這需要花費更多時間。
* 他們不攜帶傳呼機,不用擔心復制,不需要重啟實例,也不需要應用操作系統補丁。 他們與 GAE 并不需要做很多事情。
* Khan Academy 的暑期實習生 Dylan Vassallo 參與了多個 App Engine 項目,并在 Hacker News 主題 中發表了出色的評論 [像 GAE:我是可汗學院的暑期實習生,從事各種 App Engine 項目。 我沒有根據的猜測是我們是該平臺的大客戶之一。 GAE 最大的缺點之一就是缺乏控制:與 EC2 不同,在 EC2 中,您需要根據自己的需要來模制原始的 Linux 安裝,而您的應用程序必須始終符合 GAE 的服務模型。 但是,通過放棄其中一些自由,您會得到很多很棒的回報。 可汗學院(Khan Academy)已成功利用 App Engine 擴展到數百萬用戶,而無需雇用一個系統管理員或花費太多時間擔心與操作相關的任何事情。 我們能夠毫不費力地應對流量高峰,例如 60 分鐘的外觀和新計算機科學課程的發布(http://khanacademy.org/cs)。 要部署站點,任何開發人員(或我們友好的 CI 機器人)都可以簡單地運行我們的“ deploy.py”并等待幾分鐘,然后回到花時間在產品上。 我們不必再考慮數據庫是否可以處理我們向其拋出的寫負載。 就此而言,App Engine 數據存儲區是獨一無二的無后顧之憂。 (嗯,我敢肯定 Google SRE 對此非常擔心,但我們不必這樣做。)](about:blank)
* 為什么舊媒體仍然有意義。 與 60 分鐘驅動的流量相比,來自 TechCrunch,HackerNews 等的所有流量都不算什么。 差遠了。
* 他們知道他們將獲得大量流量,因此他們準備好轉彎右撥盤,以快速啟動新實例。 這就是他們所做的一切。 這是一個錯誤。
* 他們最終為這些新用戶做了很多不必要的工作。 他們需要簡化體驗。 例如,他們認為對于所有這些新流量來說,這將是運行該平臺的好時機,這是第一次使用其新的測試基礎架構來跟蹤所有這些美味數據的 A / B 測試。 失敗了
* 只要確保主要體驗干凈整潔。 如果您必須跟蹤數據,請確保它非常重要,并使用經過良好測試的數據跟蹤解決方案。
* 不要一次增加流量運行新代碼。 您只會得到一次。 如果有一半的國家因為您試圖跟蹤太多數據而無法訪問該網站,那么這是不值得的。
* 他們現在要做的是使主頁盡可能靜態,簡單,快速地加載,如果您分支出主頁,則可以獲得完整的體驗。 簡化傳入流量。
* 沒有進行足夠的負載測試。 60 分鐘帶來了很多流量,并且沒有經過測試。 但是它們具有一致的高流量負載,當不同時區的用戶上線時,流量每天都會激增。 交通也是季節性的。 他們通過自然流量模式獲得了很多有用的壓力測試。 他們必須處理高峰,低谷,人流量少的月份,然后人流量大的時候。 因此,他們知道必須在 GAE 中配置其代碼才能處理該峰值。
* 將您的工作盡可能多地轉移給其他人。 他們適合哪個 GAE。 巨大的勝利。 在有 9 名或 10 名員工的情況下,他們認為不再需要解決性能問題,并希望下一次能夠解決問題。 他們將人們奉獻給表演。 他們建立儀表板以提前預測問題。 試圖更加積極地關注性能和可伸縮性問題。
* 2 至 5 人的小組不關注可擴展性問題。 專注于功能。 使您的產品很棒。 讓人們回到它。 成功開展業務后,您就可以對所有想要的東西進行過度設計。 當您有機會構建成功的產品時,請擔心問題。
* 績效是每個人的工作,每個人都被分配給它。 嘗試在整個團隊中建立對績效的總體意識。
* 您將遇到大獲勝的性能問題,然后這是一個反復的較小的改進游戲,每次改進.25%,. 5%導致性能提高,因此這必須是每個人的工作。 人們不僅可以投入額外的 JavaScript 或進行新的數據庫查詢,還只會使您的網站運行緩慢。
* 他們有一個或兩個人的團隊專注于表現的宿舍。 可能是性能改進,也可能是工具,可以使他們更加了解性能。
* 收集大量數據。 他們想向老師和其他人報告數據。 他們的舊數據存儲系統無法匯總所有數據。 因此,他們致力于:
* 匯總數據
* 在寫入上做更多的工作,因此讀取速度很快。 重新配置數據。 復制到任何地方。 使其真正快速地進行以后的分析。
* 對于分析而言,它們似乎可能不在 GAE 范圍內,但這并未具體說明。
* 在需求旺盛之前,請不要著迷于棘手的問題,例如即時重新配置功能。
* 它們足夠小,每個人都應對 DevOps 負責,以保持系統正常運行。 將來,GAE 之外可能會有足夠的系統,他們將擁有獨立的團隊,但目前還沒有。
* 在技術和產品上都使事情變得簡單,直到您完全知道需要構建什么為止。 從長遠來看,他們為解決問題和解決問題而構建的許多功能會導致真正的問題。 構建后很難將其關閉。
* 懶惰。 使用其他人的工具。 在您的企業表現出色之前,請不要害怕使用他人的工作。
## 相關文章
* [Ben Kamens 博客](http://bjk5.com/) 中,關于可汗學院的話題很多。 非常可愛的狗。 他在 [亞馬遜的 Mega Dropdown](http://bjk5.com/post/44698559168/breaking-down-amazons-mega-dropdown) 上寫了一篇很棒的文章。
* [GitHub 上的可汗學院](https://github.com/Khan) -他們的所有代碼均為 [開源](https://khanacademy.kilnhg.com/)
* 如果 GAE 對您中的某些人來說太過分了,這是關于 [的好消息,有關 Google App Engine](https://news.ycombinator.com/item?id=4403739) 的隱藏成本
* [我在可汗學院(Khan Academy)做過的事情](http://jamie-wong.com/2012/08/22/what-i-did-at-khan-academy/) -雖然視頻內容很籠統,但這是關于團隊所做工作的具體內容
* Google Group for [Khan Academy Developers](https://groups.google.com/forum/?fromgroups#!forum/khanacademy-developers)
* [可汗學院使用 GAE / Bingo 進行的 A / B 測試課程](http://bjk5.com/post/28269263789/lessons-learned-a-b-testing-with-gae-bingo)
* [Khan Academy Docs](https://sites.google.com/a/khanacademy.org/forge/home) -很多果汁詳細信息
* [可汗學院使用 Google App Engine](https://cloud.google.com/files/KhanAcademy.pdf) 來擴展和簡化
* [有關可汗學院開發工作原理的大圖片](http://www.brianbondy.com/blog/id/109/) [圖](http://interviews.slashdot.org/story/13/02/25/1417249/interviews-khan-academy-lead-developer-ben-kamens-answers-your-questions)
* [GAE 調整應用性能](http://interviews.slashdot.org/story/13/02/25/1417249/interviews-khan-academy-lead-developer-ben-kamens-answers-your-questions) [調節](https://developers.google.com/appengine/docs/adminconsole/performancesettings) -您的旋鈕,如果您知道 [如何調整它們](http://bjk5.com/post/40833194761/pending-queues-and-loading-requests-on-app-engine) 。
* [第 1 部分:可汗學院首席開發人員 Ben Kamens 訪談](http://www.youtube.com/watch?v=BXxYEhwDh28)
* [訪談:可汗學院首席開發人員 Ben Kamens 回答了您的問題](http://interviews.slashdot.org/story/13/02/25/1417249/interviews-khan-academy-lead-developer-ben-kamens-answers-your-questions)
- 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 內容平臺的經驗教訓