# 整个 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)
![](https://img.kancloud.cn/f9/18/f918d17ff1619d9a3b862c798bd85fb9_225x104.png)
*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
![](https://img.kancloud.cn/a1/eb/a1eb655f6c4fc83c73cbc73852a863d4_640x591.png)
## 看看我们对 Netflix 如何扩展感兴趣的观点
Netflix 由马克·兰道夫(Marc Randolph)和里德·黑斯廷斯(Reed Hastings)于 1997 年在加利福尼亚州斯科茨谷市成立,最初拥有 30 名员工,其中 925 名从事按租金付费。如今,Netflix 已成为全球领先的互联网电视网络,在 50 个国家/地区拥有 6900 万订户 每月欣赏超过 100 亿小时的电视节目和电影。 它们非常透明,可以在线发布很多信息。 我们已收集并分享了我们认为最有趣的内容:
![](https://img.kancloud.cn/86/04/8604f6e1feee77f1296f04093da07d62_640x222.png)
## 规模文化
NetFlix 有一个关于文化的著名演讲。 这些概念是关于重新思考人力资源的。 他们的许多人员都集中在此演示文稿的原理上。 这是一些示例幻灯片和演示。 这为文化提供了重要的背景,以了解他们如何扩展软件堆栈以及其工作原理。
![](https://img.kancloud.cn/20/2f/202f9e39235ab31aa135bcac7dc47840_638x479.png)
![](https://img.kancloud.cn/9b/2f/9b2f07f6912e76ac5d805c0a31e98cb3_638x479.png)
完整演示文稿在这里[。](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。
[![](https://img.kancloud.cn/32/6a/326ab4001d93986629210933336403fd_640x322.png)](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 路由守护程序。
![](img/46e25abc5f6631b9baee6e4c4b6cb016.png)
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 内容平台的经验教训