# 可汗学院支票簿每月在 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 内容平台的经验教训