# Salesforce Architecture-他们每天如何处理 13 亿笔交易
> 原文: [http://highscalability.com/blog/2013/9/23/salesforce-architecture-how-they-handle-13-billion-transacti.html](http://highscalability.com/blog/2013/9/23/salesforce-architecture-how-they-handle-13-billion-transacti.html)
![](https://img.kancloud.cn/4c/6f/4c6f23957e21a15179b0557c50d6d2d2_240x169.png)
*这是由 [salesforce.com](http://www.linkedin.com/profile/view?id=3158913) 的首席站点可靠性工程师 [Claude Johnson](http://www.linkedin.com/profile/view?id=3158913) 撰写的来宾帖子。*
以下是 salesforce.com 的核心平台和应用程序的体系结构概述。 其他材料(例如,Heroku 的 Dyno 架构)或其他产品的子系统(例如,work.com 和 do.com)不在本材料中,尽管 database.com 不在其中。 想法是与技术社区分享有关 salesforce.com 如何执行工作的一些见解。 任何错误或遗漏是我的。
这绝不是全面的,但是如果有兴趣,作者将很乐意解决 salesforce.com 运作的其他领域。 Salesforce.com 希望与以前未与之互动的技术社区更加开放。 这是关于“如何打开和服”的开始。
自 1999 年以来,salesforce.com 一直专注于构建通过 Internet 交付的业务技术,以取代传统的企业软件。 我们的客户通过按月订阅付费,以通过网络浏览器随时随地访问我们的服务。 我们希望这种对 salesforce.com 核心体系结构的探索将是对该社区做出的许多贡献的第一步。
## 定义
让我们从一些基本的 salesforce.com 术语开始:
* **实例**-共享和非共享的完整的系统,网络和存储基础结构集,可为部分客户提供 salesforce.com 服务。 例如,na14.salesforce.com 是一个实例。
* **Superpod** -一组系统,网络和存储基础结构,包括出站代理服务器,负载平衡器,邮件服务器,SAN 结构和支持多个实例的其他基础结构。 Superpods 在数据中心内提供服务隔离,因此共享或复杂组件的问题不会影响该数据中心中的每个实例。
* **机构**(又称组织)-Salesforce 应用程序的单个客户。 从 www.salesforce.com 或 developer.force.com 开始的每次试用都会产生一个新的组织。 组织是高度可定制的,并且可以具有不同的安全设置,记录可见性和共享设置,UI 外观,工作流,触发器,自定义对象,标准 salesforce.com CRM 对象上的自定义字段,甚至是自定义 REST API。 组织可以支持从一百万到数百万个许可的个人用户帐户,门户网站用户帐户和 Force.com 网站用户帐户。
* **沙箱**-salesforce.com 服务的一个实例,该实例托管用于客户应用程序开发目的的生产组织的完整副本。 使用我们平台的客户可以拥有完整的应用程序开发生命周期。 这些是供客户在将更改部署到其生产组织中之前对其应用程序进行用户验收测试的测试环境。
## 统计信息(截至 2013 年 8 月)
* 17 个北美实例,4 个 EMEA 实例和 2 个 APAC 实例
* 20 个沙箱实例
* 1,300,000,000 笔以上的每日交易
* 高峰时每秒 24,000 个数据库事务(相当于其他站点上的页面浏览)
* 15,000 多个硬件系统
* > 22 PB 的原始 SAN 存储容量
* > 5K SAN 端口
## 使用的软件技术
* 用于开发和初级生产系统的 Linux
* 带 ZFS 的 Solaris 10
* 码头
* 索尔
* 记忆快取
* Apache QPID
* 质量体系
* 剃刀木偶
* Perl,Python
* 纳吉奥斯
* Perforce,Git,Subversion
## 硬件/软件架构
### 登录到 salesforce.com 服务
我们维护一个服务器池来处理所有实例的登录流量。 来自许多(但不是全部)实例的少数服务器接受登录请求,并将会话重定向到用户的家庭实例。 当您通过 login.salesforce.com 登录时,会发生这种情况。
客户流量始于我们的外部 DNS。 查找成功返回实例的 IP 地址后,标准 Internet 路由会将其定向到适当的数据中心。
一旦流量进入该数据中心中的网络,它将被定向到该 IP 所在的负载平衡器对。 我们所有面向 Internet 的 IP 都是在一对主用/备用负载均衡器上配置的 VIP。
### 在实例内部
负载平衡器将流量定向到给定实例的应用程序层。 在这一层,我们既提供标准网页流量,也提供我们的 API 流量。 API 流量占我们应用程序层总体服务的流量的 60%以上。 根据客户请求的需求,它将被定向到用于各种类型的后端处理的其他服务器层。
### 核心应用
核心应用程序层包含十到 40 个应用程序服务器,具体取决于实例。 每个服务器运行一个配置有多达 14 GiB 堆的 Hotspot JVM,具体取决于服务器硬件配置。
批处理服务器负责在数据库层上运行计划的自动化过程。 例如,每周导出过程,该过程用于以单一存档文件格式导出客户数据作为备份形式。
Salesforce.com 提供许多服务,包括基本和高级内容管理。 我们有一个内容搜索服务器和一个内容批处理服务器,用于管理内容应用程序层上的异步过程。 内容批处理服务器计划内容类型的处理,包括诸如某些文件类型的渲染预览和文件类型转换之类的功能。
### 数据库
主要数据流发生在核心应用服务器层和数据库层之间。 从软件的角度来看,所有内容都通过数据库,因此数据库性能至关重要。 每个主要实例(例如 NA,AP 或 EU 实例)都使用 8 节点集群数据库层。 客户沙箱(例如 CS 实例)具有 4 节点集群数据库层。
由于 salesforce.com 是一个非常受数据库驱动的系统,因此减少数据库负载至关重要。 为了减少数据库层的负载,我们开发了 ACS-API Cursor Server。 这是对两个问题的解决方案,使我们能够显着提高核心数据库性能。 首先,我们曾经将游标存储在数据库中,但是删除操作会影响性能。 其次,在使用数据库表保存游标之后,DDL 开销变成了负面影响。 因此诞生了 ACS。 ACS 是在一对服务器上运行的游标缓存,提供了一种从数据库层卸载游标处理的方法。
### 搜索
我们的搜索层运行在商用 Linux 主机上,每台主机上都配备了 640 GiB PCI-E 闪存驱动器,该驱动器充当搜索请求的缓存层。 这些主机通过 NFS 文件系统从共享的 SAN 阵列中获取数据。 搜索索引存储在闪存驱动器上,以提高搜索吞吐量的性能。
搜索索引当前在转换服务器上进行,转换服务器通过光纤通道 SAN 从存储阵列安装 LUN。 这些 LUN 组成一个 QFS 文件系统,该文件系统允许单写程序但多读程序访问。 像大多数其他关键系统一样,我们以主动/被动方式运行它们,而被动节点则执行一些低优先级的搜索索引工作。 然后将其结果发送给活动伙伴以写入 QFS 文件系统。
当这些相同的 LUN 从一组在 SPARC 上运行 Solaris 10 的四个 NFS 服务器以只读方式装入时,就会发生转换。 然后,这些通过 SAN 安装的文件系统通过 NFS 共享到先前描述的搜索层。
### Fileforce
我们维护一层提供对象存储的服务器,其概念与亚马逊的 S3 或 OpenStacks 的 Swift 项目相似。 Fileforce 这个系统是内部开发的,目的是减少数据库层的负载。 在引入 Fileforce 之前,所有二进制大对象(BLOB)都直接存储在数据库中。 Fileforce 联机后,所有大于 32 KiB 的 BLOB 都已迁移到其中。 小于 32 KiB 的 BLOB 继续存在于数据库中。 Fileforce 中的所有 BLOB 在数据库中都有一个引用,因此为了从备份中还原 Fileforce 数据,我们必须基于来自同一还原点的数据库备份来启动数据库实例。
Fileforce 包括捆绑程序功能,旨在减少 Fileforce 服务器上的磁盘查找负载。 如果数据库中存储了 100 个以上小于 32 KB 的对象,则将在应用服务器上运行一个进程,以将这些对象捆绑到一个文件中。 对捆绑文件的引用与捆绑中的查找偏移量一起保留在数据库中。 这类似于 Facebook 的 Haystack 图像存储系统,但内置于对象存储系统中。
### 支持
每个实例包含其他各种支持角色的服务器,例如调试应用程序服务器和应用程序层中的“ Hammer 测试”应用程序服务器,监视每个实例运行状况的中心服务器以及监视运行 Nagios 的服务器。 实例本身之外还包含支持服务器,例如存储管理,数据库管理,日志聚合,生产访问身份验证和其他功能。
## 未来发展方向
在数据库层,我们正在仔细检查数据存储系统的几种选项。 我们还在评估更高速度,更低延迟的互连,例如与现有数据库解决方案的集群互连的 Infiniband。
将来,我们希望使搜索主机能够进行所有读写操作。 我们正在为搜索索引推出 Apache Solr。 Solr 在我们现有的搜索主机上本地运行。 SAN,NFS 服务器和基于 SPARC 的索引器主机将全部消失,这将大大降低整个搜索层的复杂性。
我们的应用程序容器以前是 Resin,但在过去的一年中,我们一直在迁移到 Jetty。 我们还在对应用层硬件进行硬件更新,这将使 RAM 大小增加 30%-266%,并将 Sandy Bridge 处理器引入我们的堆栈。
我希望对 salesforce.com 技术架构和堆栈的概述能使您有趣且有益。 如果您对其他访客帖子感兴趣,请深入评论我们广泛的技术基础架构的其他部分。 谢谢阅读!
## 相关文章
* [Force.com 多租户架构的内部设计](http://www.infoq.com/presentations/SalesForce-Multi-Tenant-Architecture-Craig-Weissman)
* [Salesforce.com 架构](http://www.scribd.com/doc/145879736/Salesforce-com-Architecture)
* [单元架构](http://highscalability.com/blog/2012/5/9/cell-architectures.html)
克劳德
感谢您抽出宝贵时间发布此信息。 我想对您如何使用 Solaris 和 ZFS 的更多信息非常感兴趣。 另外,如果必须全部这样做,是否会再次使用 QFS?
谢谢!
你们正在使用什么数据库?
此外,您提到了 Resin 和 Jetty,但在语言列表中没有提及 Java。 如果使用 Java,则正在使用 Java EE 的哪些部分?
他们没有提到它,但我可以想象它是神谕!
@MiddleAgedGeek
他们使用 Oracle 或曾经使用 Oracle:http://www.dbms2.com/2012/06/26/is-salesforce-com-going-to-stick-with-oracle/
?? 每秒有 24,000 个数据库事务(24k TPS)由多少台数据库机处理? 还是每个数据库服务器处理多少 TPS?
另外,我们是否在这里谈论纯 OLTP,OLAP 和混合液?
韦斯
FIleforce 在 Solaris 10 上运行,并且 Fileforce 数据存储在从镜像 VDEV 创建的 ZFS 池中。 (镜像 VDEV 的数量取决于服务器的型号。)
我开始之前就选择了 QFS。 由于 salesforce.com 是 Sun 商店,并且搜索索引是在具有 SAN 存储的 SPARC 服务器上运行的,因此 QFS 是操作人员轻松实现高吞吐量,可靠的搜索索引文件系统的方式。 NFS 将其安装到搜索层的唯一原因是字节顺序问题。 如前所述,我们正在转向一种更易于推理,故障排除和支持的体系结构。
MiddleAgedGeek 和 ymo,
请参阅 http://www.salesforce.com/company/news-press/press-releases/2013/06/130625.jsp,但我们确实使用 Oracle 数据库。 我们确实将其他数据存储用于不同的应用程序,但是上述核心数据库是 Oracle。
至于 Java,我们将 Jetty 用作容器,但是我们并未使用大多数核心 Java EE 功能。 Java 是我们内部构建的核心应用服务器的选择语言。
普热梅克
24000 个事务/秒是我们所有实例中高峰事务速率的平均值。 工作量主要是 OLTP,但是由于客户使用我们服务的方式,肯定有 OLAP 组件。
Claude,
很棒的文章,感谢您在幕后进行的深入探寻,我期待更深入的潜水。 社区绝对可以从 SF 经验中学习。
1.3B 事务...是否还可以将其定义为单个客户端请求(网页浏览,ajax 请求)以及服务器的相应响应?
以后的文章建议对实例进行检测和监视。 数据量,脱机处理,什么类型的数据(http 日志,代码跟踪语句,度量标准等)。
嗨,克劳德,
感谢您分享此信息。 它真的很有帮助:-)
彼得
是的,交易是对实例的应用层的请求/响应。
我也一定会通过这个建议。 我希望我的团队和其他人能看到更多类似的帖子。 我很高兴得到如此积极的回应。 谢谢你们!
惊人的帖子比我以前看到的要详细得多。 谢谢!
您今年要参加 Dreamforce 吗?
我使用该平台已有几年了,我一直想知道它是如何在后台运行的。 处理的数据量以及所有响应的响应速度简直太疯狂了。
很棒的帖子! 感谢分享!
惊人的帖子,
在注释部分提到的是 Oracle DB。 我猜一个实例中的群集。 您如何处理 HA 和 DR?
例如,如何将 Appexchange 部署添加到不同的位置,例如在同一地点?
是否存在共享实例,还是仅在所有实例中都复制了?
感谢您的评论。
有趣的文章-感谢分享。 您如何监视系统-性能和中断。 除了 Nagios 之外,您还使用其他监视工具吗? Splunk,仙人掌等?
感谢您分享知识。
有许多服务器可为来自不同大陆的客户提供应用程序层服务。
您是否为每个新的注册客户端创建单独的数据库? 或每个服务器的数据库有一定限制。 在数据库层部分找不到太多有关如何进行负载平衡的信息?
引人入胜的文章,并保持他们的到来。 我经常推测出幕后的魔力,这绝对是一本好书。 我希望类似的帖子将继续围绕这样的主题-它们不仅通过透明性建立信任-它们还有助于增进我们的集体工程知识。 谢谢!
嗨
非常有启发性的文章!
我想深入了解 Force.com 网站如何与整个事情联系在一起。 它托管在 DMZ 区域中吗?
谢谢!
是否考虑过像事务服务器集群这样的单独层来减少会话负载? 当然,我假设在数据库层而不是在应用程序服务器层运行存储过程。
您可以在以下位置找到 Salesforce.com 架构幻灯片:http://www.slideshare.net/gueste35dd2/salesforcecom-corporate-presentation-july-2009?next_slideshow=1-上面的划线链接要求我注册&,但要付费 。
很棒的架构概述! 要求:这是 2 岁。 请分享过去两年中的体系结构和基础架构升级。 谢谢 !
现在的堆栈是什么样的? 它是如何成长的? 什么是新的,什么掉了? 软件堆栈必须已大修几次。
从接收的客户数量来看,SFDC 的技术足迹必须每年增长 10-20%?
- 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 内容平台的经验教训