# 整個 Netflix 堆棧的 360 度視圖
> 原文: [http://highscalability.com/blog/2015/11/9/a-360-degree-view-of-the-entire-netflix-stack.html](http://highscalability.com/blog/2015/11/9/a-360-degree-view-of-the-entire-netflix-stack.html)

*This is a guest?[repost](http://www.scalescale.com/the-stack-behind-netflix-scaling/)?by?[Chris Ueland](http://twitter.com/ChrisUeland), creator of?[Scale Scale](http://scalescale.com/), with a creative high level view of the Netflix stack.*
> 隨著我們對擴展的研究和深入研究,我們將繼續涉足 Netflix。 他們的故事很公開。 這篇文章是我們在 Bryan 的幫助下整理而成的。 我們從互聯網上收集了信息。 如果您想了解更多信息,我們將在此附上。 否則請盡情享受!
>
> –克里斯/ ScaleScale / MaxCDN

## 看看我們對 Netflix 如何擴展感興趣的觀點
Netflix 由馬克·蘭道夫(Marc Randolph)和里德·黑斯廷斯(Reed Hastings)于 1997 年在加利福尼亞州斯科茨谷市成立,最初擁有 30 名員工,其中 925 名從事按租金付費。如今,Netflix 已成為全球領先的互聯網電視網絡,在 50 個國家/地區擁有 6900 萬訂戶 每月欣賞超過 100 億小時的電視節目和電影。 它們非常透明,可以在線發布很多信息。 我們已收集并分享了我們認為最有趣的內容:

## 規模文化
NetFlix 有一個關于文化的著名演講。 這些概念是關于重新思考人力資源的。 他們的許多人員都集中在此演示文稿的原理上。 這是一些示例幻燈片和演示。 這為文化提供了重要的背景,以了解他們如何擴展軟件堆棧以及其工作原理。


完整演示文稿在這里[。](http://www.scalescale.com/the-stack-behind-netflix-scaling/#)
## 通過 Amazon 支持許多標題
Netflix 的基礎設施位于 Amazon EC2 上,來自電影制片廠的數字電影原版存儲在 Amazon S3 上。 使用云上的機器,根據視頻分辨率和音頻質量,每部電影被編碼為 50 多種不同版本。 超過 1 PB 的數據存儲在 Amazon 上。 這些數據被發送到內容傳遞網絡,以將內容提供給本地 ISP。
Netflix 在后端使用了許多開源軟件,包括 Java,MySQL,Gluster,Apache Tomcat,Hive,Chukwa,Cassandra 和 Hadoop。
[](http://2zmzkp23rtmx20a8qi485hmn.wpengine.netdna-cdn.com/wp-content/uploads/2015/11/netflix-architecture.png)
## 支持多種設備
Netflix 上大量的編解碼器和比特率組合意味著“在將相同的標題交付給所有流媒體平臺之前,必須對其進行 120 次不同的編碼”。
盡管 Netflix 使用自適應比特率流技術來調整視頻和音頻質量以匹配客戶的下載速度,但它們還為用戶提供了在其網站上選擇視頻質量的能力。
您可以從提供 Netflix 應用程序的任何與 Internet 相連的設備上立即觀看,例如計算機,游戲機,DVD 或藍光播放器,HDTV,機頂盒,家庭影院系統,電話或平板電腦。
它們以不同的比特率支持以下編解碼器中的每個標題,以使其在設備和連接上工作。
* 視頻– [VC-1](https://en.wikipedia.org/wiki/VC-1) , [H.264(AVC)](https://en.wikipedia.org/wiki/H.264),VC-1, [H.263](https://en.wikipedia.org/wiki/H.263) , [H.265(HEVC)](https://en.wikipedia.org/wiki/High_Efficiency_Video_Coding)
* 音頻– [WMA](https://en.wikipedia.org/wiki/Windows_Media_Audio) ,[杜比數字](https://en.wikipedia.org/wiki/Dolby_Digital),[杜比數字 Plus](https://en.wikipedia.org/wiki/Dolby_Digital_Plus) , [AAC](https://en.wikipedia.org/wiki/Advanced_Audio_Coding) 和 [Ogg Vorbis](https://en.wikipedia.org/wiki/Ogg_Vorbis)
### Netflix Open Connect CDN
Netflix Open Connect CDN 是為擁有超過 100,000 個訂閱者的大型 ISP 提供的。 一種特殊構建的低功耗高存儲密度設備可將 Netflix 內容緩存在 ISP 的數據中心內,以降低互聯網傳輸成本。 該設備運行 FreeBSD 操作系統, nginx 和 Bird Internet 路由守護程序。

NetFlix 巴黎公開賽–圖片來源:@dtemkintwitter
在處觀看 Open Connect 視頻[。](https://www.youtube.com/watch?v=mBCXdaukvcc)
## 縮放算法
在 2009 年,Netflix 舉辦了一項名為 [Netflix 獎](https://en.wikipedia.org/wiki/Netflix_Prize)的競賽。 他們打開了一堆匿名數據,并允許團隊嘗試得出更好的算法。 獲勝團隊將現有算法提高了 10.06%。 Netflix 打算再獲得一個 Netflix 獎,但最終沒有這樣做,因為 FTC 擔心隱私。
Netflix 推薦系統包含許多算法。 生產系統中使用的兩個核心算法是受限玻爾茲曼機(RBM)和一種稱為 SVD ++的矩陣分解形式。 使用線性混合將這兩種算法結合在一起以產生單個更高的準確性估計。
受限玻爾茲曼機是經過修改以在協同過濾中工作的神經網絡。 每個用戶都有一個 RBM,每個節點的輸入節點代表該用戶已評分的電影。
SVD ++是 SVD(奇異值分解)的不對稱形式,它利用了 RBM 等隱式信息。 它是由 Netflix 競賽的獲勝團隊開發的。
Netflix 團隊在其工程博客上介紹了[學習個性化主頁](http://techblog.netflix.com/2015/04/learning-personalized-homepage.html)
## 開源項目
[https://netflix.github.io/](https://netflix.github.io/) 。 Netflix 有一個很棒的工程博客,最近他們在 Netflix 上發表了一篇名為 [The Evolution of Open Source 的文章。](http://techblog.netflix.com/2015/10/evolution-of-open-source-at-netflix.html)
## 大數據
* [Genie](https://github.com/Netflix/genie) -對我們各種數據處理框架(尤其是 Hadoop)的強大,基于 REST 的抽象。
* [Inviso](https://github.com/Netflix/inviso) -提供有關我們 Hadoop 作業和集群性能的詳細見解。
* [口紅](https://github.com/Netflix/lipstick)-以清晰,可視的方式顯示 Pig 作業的工作流程。
* [Aegisthus](https://github.com/Netflix/aegisthus) -啟用從 Cassandra 中批量提取數據以進行下游分析處理。
## 構建和交付工具
* [Nebula](https://nebula-plugins.github.io/) -Netflix 努力共享其內部構建基礎結構。
* [代理程序](https://github.com/Netflix/aminator)-用于創建 EBS AMI 的工具。
* [Asgard](https://github.com/Netflix/asgard) -用于 Amazon Web Services(AWS)中的應用程序部署和云管理的 Web 界面。
## 通用運行時服務&庫
* [Eureka](https://github.com/Netflix/eureka) -Netflix 云平臺的服務發現。
* [Archaius](https://github.com/Netflix/archaius) -分布式配置。
* [功能區](https://github.com/Netflix/ribbon)-彈性和智能的進程間和服務通信。
* [Hystrix](https://github.com/Netflix/hystrix) -提供超越單次服務呼叫的可靠性。 在運行時隔離等待時間和容錯能力。
* **[Karyon](https://github.com/Netflix/karyon)** 和 **[控制器](https://github.com/Netflix/governator)-** JVM 容器服務。
* [Prana](https://github.com/Netflix/prana) sidecar -
* [Zuul](https://github.com/Netflix/zuul) -在云部署的邊緣提供動態腳本化代理。
* [Fenzo](https://github.com/Netflix/Fenzo) -為云本機框架提供高級調度和資源管理。
## 數據持久性
* **[EVCache](https://github.com/Netflix/EVCache)** 和 **[炸藥](https://github.com/Netflix/dynomite)** **-** 用于大規模使用 Memcached 和 Redis。
* **[Astyanax](https://github.com/Netflix/astyanax)** 和 **[Dyno](https://github.com/Netflix/dyno)** **-** 客戶端庫可更好地使用云中的數據存儲。
## 洞察力,可靠性和性能
* [Atlas](https://github.com/Netflix/atlas) -時間序列遙測平臺
* [Edda](https://github.com/Netflix/edda) -跟蹤云中更改的服務
* [觀眾](https://github.com/Netflix/spectator)-Java 應用程序代碼與 Atlas 的輕松集成
* [向量](https://github.com/Netflix/vector)-以最小的開銷公開高分辨率的主機級指標。
* [Ice](https://github.com/Netflix/ice) -揭示了持續的成本和云利用率趨勢。
* [Simian Army](https://github.com/Netflix/SimianArmy) -測試 Netflix 實例是否出現隨機故障。
## 安全性
* [Security Monkey](https://github.com/Netflix/security_monkey) -幫助監視和保護基于 AWS 的大型環境。
* [Scumblr](https://github.com/Netflix/scumblr) -利用整個 Internet 的針對性搜索來發現特定的安全問題以進行調查。
* [MSL](https://github.com/Netflix/MSL) -一種可擴展且靈活的安全消息傳遞協議,可解決許多安全通信用例和要求。
* [Falcor](https://netflix.github.io/falcor/) -通過虛擬 JSON 圖將遠程數據源表示為單個域模型。
* [Restify](https://github.com/restify/node-restify) -專門用于 Web 服務 API 的 node.js REST 框架
* [RxJS](https://github.com/ReactiveX/RxJS) -用于 JavaScript 的反應式編程庫
## 參考資料
1. [關于 HackerNews](https://news.ycombinator.com/item?id=10534219)
2. [https://zh.wikipedia.org/wiki/Netflix](https://en.wikipedia.org/wiki/Netflix)
3. [http://gizmodo.com/this-box-can-hold-an-entire-netflix-1592590450](http://gizmodo.com/this-box-can-hold-an-entire-netflix-1592590450)
4. [http://edition.cnn.com/2014/07/21/showbiz/gallery/netflix-history/](http://edition.cnn.com/2014/07/21/showbiz/gallery/netflix-history/)
5. [http://techblog.netflix.com/2015/01/netflixs-viewing-data-how-we-know-where.html](http://techblog.netflix.com/2015/01/netflixs-viewing-data-how-we-know-where.html)
6. [https://gigaom.com/2013/03/28/3-shades-of-latency-how-netflix-built-a-data-architecture-around-timeliness/](https://gigaom.com/2013/03/28/3-shades-of-latency-how-netflix-built-a-data-architecture-around-timeliness/)
7. [https://gigaom.com/2015/01/27/netflix-is-revamping-its-data-architecture-for-streaming-movies/](https://gigaom.com/2015/01/27/netflix-is-revamping-its-data-architecture-for-streaming-movies/)
8. [http://stackshare.io/netflix/netflix](http://stackshare.io/netflix/netflix)
9. [https://www.quora.com/How-does-the-Netflix-movie-recommendation-algorithm-work](https://www.quora.com/How-does-the-Netflix-movie-recommendation-algorithm-work)
10. [https://netflix.github.io/](https://netflix.github.io/)
在哪里提到 Spring? Netflix 的所有 Java 都在 Spring 框架的上下文中。
到目前為止,這還不是一個完整的列表。 不好的文章。
NetFlix 不使用 Spring,至少他們從未在任何演示文稿或白皮書中提及 Spring。
我在這里看不到他們使用 Node.JS 嗎? 我記得曾經從他們那里看到幻燈片,談論他們如何處理 Node.JS 的服務以及如何優化這些服務。
有一些使用 Spring 的應用程序,但是 95%以上的 Java 應用程序直接使用 Guice 或通過 Governor 增強。
他們在那里的服務中使用 guice 代替。Governator 是一個很好的 guice 擴展庫,盡管將它們標記為已棄用,您仍可以在該庫中找到一些硬編碼的依賴項。
好像他們沒有在使用 docker ...
您在“受限玻爾茲曼機器”中寫了“玻爾茲曼”錯誤。
@ cmp,restify 是使用 Node 并為其構建的 Web API 框架。
本文是有缺陷的,它沒有說明軟件公司最重要的事情,即:他們使用哪個需求管理系統,以及它們如何保持需求與代碼之間的可處理性?
他們確實使用 Spring Cloud,這是參考 https://2015.event.springone2gx.com/schedule/sessions/spring_cloud_at_netflix.html
炸藥列在錯誤的類別下。 當前,它是一個分布式的內存存儲。
出色的工作!
從所有者到 Netflix 的內容交付(關系圖上的左箭頭)使用 SMPTE 的可互操作主格式(IMF)。 視頻使用 JPEG-2000 編碼,音頻未編碼(線性 PCM)。 內容使用 MXF 打包(例如,非常類似于 D-Cinema 的內容)。
SMPTE 當前正在努力擴展此標準,以支持 HDR +視頻:高動態范圍(HDR)可提供更多的對比度,寬色域(WCG)可提供更多的顏色,高幀速率(HFR)可以每秒 50 幀或更多。
來自 Netflix 的 Chris Fetner 提供詳細信息的柏林論壇 2015 年會議上的詳細信息:
http://www.mesclado.com/smpte-forum-2015-future-proofing-media-production-part-3/ ?lang = en
Netflix 還使用 Groovy 編程語言和 RxJava 進行功能性反應式編程(請參閱 http://de.slideshare.net/InfoQ/functional-reactive-programming-in-the-netflix-api)
Netflix 使用 ElasticBox 來管理后臺。 他們還在許多地方使用 Docker。
Netflix 還運營著一個相當大的 Elasticsearch 集群。 參見 https://www.elastic.co/videos/netflix-using-elasticsearch/和 https://www.elastic.co/elasticon/2015/sf/arrestful-development-how-netflix-uses-elasticsearch-to- 更好地了解
Netflix 是 Apache Cassandra 的已知用戶。 他們的技術博客對此進行了廣泛報道,而 Netflix 對此已經非常公開。 (作為一個旁注,我在同一博客上找不到任何標記 DynamoDB 的帖子)。
Netflix 使用 Node.JS。 本文只有 50%正確。 這里的一些內容,我們已經從其他內容切換到了。 我在 Netflix 的工程團隊工作。 我們確實使用 Cassandra。 我們還使用 Reactor.JS。 一直在進行變化以適應技術變化。 我們混合使用了 JS 庫,并完成了許多自定義工作,例如滑塊。
netflix 是否使用帶有 typescript 的節點,它們如何使用動態類型的 JS 維護大型節點應用程序
只需在 github 上的 Netflix 上尋找 Java 技術,他們為 Spring-Cloud 做出了很大貢獻。
另請參閱 OSS:https://netflix.github.io/
- 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 內容平臺的經驗教訓