# 如今 Etsy 的架构是什么样的?
> 原文: [http://highscalability.com/blog/2016/3/23/what-does-etsys-architecture-look-like-today.html](http://highscalability.com/blog/2016/3/23/what-does-etsys-architecture-look-like-today.html)
![](https://img.kancloud.cn/d3/8d/d38de1ecb79c7b01a039a17f0b8ad42d_240x161.png)
*这是 [Christophe Limpalair](https://twitter.com/ScaleYourCode) 的来宾帖子,基于他对 [Jon Cowie](https://twitter.com/jonlives) ,员工运营部所做的[采访](https://scaleyourcode.com/interviews/interview/25)([视频](https://www.youtube.com/watch?v=3vV4YiqKm1o)) 工程师和 Breaksmith @ Etsy。*
随着 Etsy 从新平台过渡到稳定且完善的电子商务引擎,Etsy 成为了一个令人着迷的观看和研究平台。 这种转变需要进行很多文化上的改变,但最终结果却是惊人的。
如果您还没有看到它,2012 年有一篇[文章](http://highscalability.com/blog/2012/1/9/the-etsy-saga-from-silos-to-happy-to-billions-of-pageviews-a.html)概述了他们的成长和转变。 但是从那以后发生了什么? 他们还在创新吗? 如何制定工程决策,这如何影响他们的工程文化? 这些是我们与 Etsy 的一名运维工程师,定制厨师的作者 Jon Cowie 在新的播客节目中探讨的问题。
## [](#what-does-etsys-architecture-look-like-nowadays)如今 Etsy 的架构是什么样的?
自上一次更新可追溯到 2012 年以来(在前面提到的帖子中),他们的体系结构并没有真正改变太多。 尽管这听起来有些无聊,但它概述了一个重要的概念,并为我们提供了对 Etsy 的工程文化的一些见识。 在整篇文章中,我们都会回头介绍这种文化,但这是它们的总体架构:
Etsy 的生产基础设施全是裸机。 但是,在开发方面,他们可以虚拟化环境。 这为每个开发人员提供了一个代表整个堆栈缩影的虚拟机。 最终,虚拟环境仍在 Etsy 自己的物理硬件上运行。
实际的堆栈本身仍然看起来像这样:
* 的 Linux
* 阿帕奇
* 的 MySQL
* 的 PHP
* 缓存层
* F5 负载平衡器
它们具有许多具有不同作业的不同缓存层。 他们大量使用 memcached 缓存数据库对象。
Etsy 具有面向第三方开发人员的面向公众的 API,并且它们还具有内部 API。 这些 API 有缓存层,因为有些答案不是短暂的。 例如,如果一个答案生存一个小时或更长时间,他们可能会缓存它。
当然,它们也大量缓存图像和静态资产。
这里的挑战是缓存失效。 确保您没有向用户提供过时的内容,而是充分利用了缓存以尽可能减少数据库的负载。 另外,请确保您通过将其缓存并靠近最终用户来更快地向用户提供响应。 Etsy 团队还深深地关注着这件事,这可以从其工程博客 CodeasCraft.com 上的定期性能报告中看出。
尽管总体架构几乎相同,但这并不意味着 Etsy 工程师和 Ops 团队一直坐在那里摆弄他们的拇指。 好吧,也许其中一些有,但是我离题了...
## [](#so-what-are-their-ops-challenges-do-they-still-have-to-put-out-fires)那么他们的操作挑战是什么? 他们还必须灭火吗?
我们只是看到他们倾向于在成熟和成熟的技术方面犯错误,因此他们不会花费太多时间扑灭火灾。 新问题往往来自引入新系统。 我敢肯定,你们中的许多人以前都读过这篇文章:您介绍了一个新的系统,该系统在纸上可以解决所有问题。 除非它对您环境中当前的其他组件具有复杂且“不可能”的反应。 因此,您必须找出导致问题的原因以及解决方法。
老实说,如果您从事这一领域,那么您可能会活在当下。 这些有趣的挑战使您抓狂,您真的想弄清楚,以便继续进行下一个挑战。 除非有时花费的时间太长,然后变得很麻烦。
大多数公司面临的另一个挑战是试图雇用优秀人才。 您在哪里还能找到优秀的人才? 如果您正在使用新的“热门功能”,那么可能很难找到该人才,而且价格会昂贵得多。 但是,如果您选择像 PHP 这样成熟的东西,它并不是那么困难。 仍然很难,但是不像为 Scala 找到人那样难。
到目前为止,已有许多 PHP 工具出现了十年,而语言也是如此。 许多前沿漏洞已被消除。 这意味着更少的难以发现的怪异错误,以及更多的专家可以聘用。
## [](#does-that-mean-they-never-change-anything-in-their-architecture)这是否表示他们从不更改架构中的任何内容?
不,绝对不是。 这意味着他们拥有制定使用新技术的决策的明确流程。
他们实际上使用工具来创建“体系结构评论”,支持者在其中输入支持材料和该思想背后的理论。 然后,一个团队将提出一个他们认为适合 Etsy 当前环境的概念。
让我们看一个最近的例子。 他们介绍了 Kafka 用于事件流水线。 为了做到这一点,一个团队提出了一个用例,说明了为什么要使用 Kafka 以及如何解决 Etsy 的实际问题。 然后,他们进行了体系结构审查,高级工程师和所有相关方聚集在一起讨论该提案。
它是一种成熟且成熟的技术吗?
它会真正解决问题吗?这是解决问题的最佳方法吗?
组件将如何与我们的系统反应?
谁来支持这个?
一旦回答了这些问题,它们便进入实施阶段。
在上线之前,它必须经历另一个称为“可操作性审查”的过程,该过程将验证一切是否就绪。 这包括设置适当的监视和警报,为每个待命人员设置适当的程序,等等。 与该实现有关的每个人都必须参与“什么,何时,如何”。
另一个重要的考虑因素是:“我们可以通过在已经拥有的工具上构建它来做到这一点吗?” 稍后,我们将详细介绍。
这些是在实施建议的技术之前必须回答的问题。 这种彻底的分析可能需要一些时间,但是对于已建立的电子商务平台而言,正常运行时间至关重要。
“我们非常重视站点的正常运行时间,可靠性和总体可操作性。”
## [](#customizing)自定义
我们已经看到了 Etsy 的文化如何促进稳定。 我们尚未讨论的是它如何鼓励定制现有工具。
正如我们刚刚看到的那样,定制一个已经在使用中的工具有时更有意义,而不是实施一个新的工具来解决问题。 一个典型的例子是定制 Chef。 乔恩·考伊(Jon Cowie)已成为一些有影响力的厨师定制的一部分,例如[刀叉](https://github.com/jonlives/knife-spork)。 该自定义实际上来自 Etsy 团队试图解决的问题。 当多个开发人员同时对同一 Chef Server 和存储库进行更改时,更改将被覆盖。 Jon 负责这个工具,不仅为一个大型开源社区提供了帮助,而且还解决了 Etsy 的一个关键和局限性问题。
这是 Jon 启发编写[定制厨师](http://shop.oreilly.com/product/0636920032984.do)的一部分。 这是他希望自己拥有的书。
这也是 Chef 开源文化的一个很好的例子。 乔恩(Jon)强调说,Chef 并非旨在成为“一刀切”的解决方案。 它旨在为人们提供一个工具包,使我们能够解决自己的自动化问题。 Chef 的想法是,用户是他们自己系统的专家。 虽然它不能告诉您该怎么做,但它为您提供了工具,因此您可以自己做出决定,然后告诉您想要什么。
当然,这并不是说定制没有自己的问题。 如果自定义某些内容,则必须“拥有它”。 一旦决定开源该工具或自定义工具,它将变得更加复杂。 实际上,Etsy 在决定开放源代码工具后就对此产生了疑问。 他们将开放该工具的源代码,但工程师随后将在本地下载一个版本,为 Etsy 基础结构对其进行编辑,然后再将其推回主存储库。 许多项目只是没有被更新。
他们是如何解决的? 通过适当的程序。 就像想要在系统中引入新技术一样,如果您想在 Etsy 中开源项目,则需要回答有关该项目及其维护方式的一些问题。
它也很多都承认哪些项目不再需要维护了。 他们最终完成了多个项目,并明确表示不再进行更新。 这样一来,他们就可以重新组合并专注于内部实际使用的工具。
“因此,我们已建立的流程更加适合确保我们只开源自己在生产中积极使用的东西。”
因为归根结底,如果没有人要维护一种工具,那么它可能不会对整个社区有所帮助。
## [](#what-about-you)你呢?
您的过程和思维方式有何不同? 您从 Etsy 的方法中学到了什么吗? 从他们的工程文化和开放源代码实践怎么样?
[关于 HackerNews](https://news.ycombinator.com/item?id=11345723)
- 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 内容平台的经验教训