# ESPN 的架构规模-每秒以 100,000 Duh Nuh Nuhs 运行 > 原文： [http://highscalability.com/blog/2013/11/4/espns-architecture-at-scale-operating-at-100000-duh-nuh-nuhs.html](http://highscalability.com/blog/2013/11/4/espns-architecture-at-scale-operating-at-100000-duh-nuh-nuhs.html)  ESPN 于 1978 年播出 [](http://en.wikipedia.org/wiki/History_of_ESPN)。 在过去的 30 多年中，请想一想我们所见过的奇观！ 当我想到 ESPN 时，我想到的是一个全球性品牌，这正是黄金时段的定义。 它显示在他们的统计数据中。 ESPN.com 的峰值是每秒 100,000 个请求。 毫无疑问，他们的巅峰赛事是世界杯。 但是，如果您知道 ESPN 仅由几百台服务器和数十名工程师提供支持，您会感到惊讶吗？ 我曾是。 您是否会惊讶于 ESPN 正在经历从企业架构到能够处理由于移动使用，个性化和服务导向的增长而驱动的 Web 规模负载的根本转变？ 再一次，我以为 ESPN 只是想看电视上的体育节目而感到惊讶。 ESPN 的意义远不止于此。 ESPN 正在成为一个运动平台。 ESPN 如何处理所有这些复杂性，责任，变更和负载？ 与 HighScalability 上的大多数其他配置文件不同。 ESPN 的迷人故事由 [Manny Pelarinos](http://www.linkedin.com/in/manole) ，ESPN 工程部高级总监在 InfoQ 演讲中讲述 [Architecture ESPN](http://www.infoq.com/presentations/Architecture-Scale-ESPN) 的规模。 来自 [Max Protect 的信息：ESPN.com 上的可伸缩性和缓存](http://www.infoq.com/presentations/Max-Protect-Scalability-and-Caching-at-ESPN) 也已纳入其中。 在个人前计算机时代开始，ESPN 建立了创新的有线和卫星电视体育帝国。 从最初的 30 分钟计划中回顾了当天的运动，他们继续与 NBA， [USFL](http://en.wikipedia.org/wiki/United_States_Football_League) ，NHL 达成交易，后来成为大鱼 美国国家橄榄球联盟的所有运动。 逐项体育交易的目的是从所有可能的来源中获取体育数据，以便 ESPN 可以报告比分，播放电影片段，并通常成为一站式购物，包括电视和后来的网络体育节目。 这是一个需要理解的复杂系统。 他们在电视&广播，现场评分，编辑和发布，数字媒体，体育比分，网络和移动，个性化，幻想游戏等方面进行了大量工作，他们还希望将 API 访问权限扩展到第三方开发人员。 与大多数关于 HighScalability 的配置文件不同，ESPN 具有企业传统。 它是一个 Java Enterprise 堆栈，因此您将看到 Oracle 数据库，JMS 代理，Java Bean 和 Hibernate。 我们将学习的一些最重要的课程： * **平台更改了所有内容** 。 ESPN 将自己视为内容提供商。 这些天的内容可以通过多种途径访问。 它可以在电视，ESPN.com 或移动设备上显示，但内容也正被越来越多的内部应用程序（例如 Fantasy Games）所占用。 他们还希望提供一个外部 API，以便开发人员可以在 ESPN 资源上构建。 ESPN 希望成为建立在体育内容平台上的围墙花园，该平台可以集中利用其对所有人的主要优势，这是对体育相关内容和数据的前所未有的访问。 ESPN 希望在体育领域做到这一点：Facebook 为社交服务，苹果为应用服务，谷歌为 AI 服务。 问题正在从企业架构过渡到基于 API 和服务的平台，这是一个艰难的转变。 他们可以做到。 他们正在这样做。 但这将很难。 * **网络规模改变了所有内容** 。 如今，许多 Web 属性都使用 Java 作为其标准的后端开发环境，但是在 Java Enterprise 时代成长的 ESPN.com 完全采用了规范的 Enterprise 体系结构。 而且效果很好。 直到出现了从相对可预测的 ESPN.com 经历的企业级负载到由高移动流量，大规模定制和平台问题所主导的世界的阶段过渡。 我们在本机 Web 属性中看到的许多体系结构选择现在必须由 ESPN.com 使用。 * **个性化更改了所有内容** 。 当为每个用户动态构造所有内容，并且必须在每种访问方式（.com，手机，电视）上跟随您时，曾经保存数据库的缓存现在变得不那么有用了。 * **Mobile 改变了所有内容** 。 它给您的架构带来无处不在的压力。 在只有网络架构的情况下，这没什么大不了的，因为用户减少了，服务器也减少了。 在移动用户和服务器数量如此之多的移动时代，这种架构决定产生了巨大的变化。 * **伙伴关系就是力量** 。 ESPN 可以创建一个有围墙的花园，因为多年来，他们建立了合作伙伴关系，使他们可以特别访问其他人没有的数据。 最好先做到最好。 NFL 和 MLB 之类的个人体育项目试图通过自己的网络来获取这一价值，这在某种程度上削弱了这一优势，但是每个人都需要相处的力量，如果 ESPN 能够执行的话，这将使他们成为强大的平台竞争者 。 ## 统计信息 * 互联网上排名第一的体育网站。 所有网站的前 10 名。 18-54 岁男性中排名第五的网站（Facebook，Google，Microsoft，Yahoo 更大）。 * 仅由几百台服务器供电。 * 有几十个服务站点的主要部分，例如首页服务。 * 只有几十名工程师。 * 峰值为每秒 100,000 个请求。 高峰赛事是世界杯。 * 体育专用数据的大小为千兆字节。 ## 堆栈 * 基于 Java。 * Oracle 数据库， * AQ 流 * 消息代理 * WebSphere MQ * 有趣的是将地面人员集成为数据源和自动提要 * JMS Broker * Microsoft SQL Server * 休眠 * Ehcache * 我们 * IBM eXtreme Scale * 服装 * F5 负载均衡器 ## 架构  * 十年前与 Paul Allen 的一家创业公司 Starwave 一起成立，因此他们在 Microsoft 技术方面大受好评，但选择了 Java。 Java 还很年轻，因此他们必须自己独立完成大部分工作。 该站点已发展了 100 多次和 100 多次迭代。 * 通过更多服务进行了扩展，例如 Watch ESPN 是一项新的专用服务。 在数百台服务器上部署了 100 多个逻辑数据库和 200 多个不同的应用程序。 * ESPN.com 的目标是为体育迷随时随地在任何设备上提供准确及时的数据，并访问更深的内容。 分数，统计数据和更深层次的内容必须准确，即时。 就像电视一样，没有中断。 * 不要认为自己是一家技术公司。 他们是媒体和内容提供商。 由迪士尼拥有，未公开交易。 * 数字属性：ESPN.com，奇幻游戏，移动设备（WAP，iPad，iPhone 等），WatchESPN（手机上的手表电缆），ESPN Ocho（物品，W，HS 等）。 不同的体系结构和服务为每个属性提供动力。 ESPN.com 是本演讲的主要内容。 * 例如波士顿和纽约的不同本地站点。 庞大的编辑团队会为每个本地站点提供本地版本，因此不同的粉丝群体会在游戏中产生不同的倾向。 * 以低硬件占用空间处理高负载的关键是复杂的页面和片段缓存系统。 实时更新（例如得分，统计信息，时间表）具有不同的缓存系统。 个性化也有其自己的缓存系统。 * 开发人员通常没有登录生产机器的权限。 ## 架构是围绕应用程序和数据库组织的 * 数十个逻辑数据库。 MLB，NFL，NHL 等的数据库，以及每个数据库的应用程序，包括诸如 Frontpage 的更抽象的服务，用于为主要网站提供服务。 * 进程隔离。 如果部署了错误的代码，则不会破坏网站的其他部分。 * 不是整体架构，有不同的系统用于不同的运动。 * 历史上原始的 SOA 模型。 Frontpage 对返回 XML 的不同服务进行了多个 HTTP 调用，并且调用者对其所需的内容进行了解析。 不同服务之间的大量互连。 * Frontpage 计分板具有来自所有不同联赛的所有不同分数。 每种运动都有单独的应用程序。 单击 NHL 会通过负载均衡器点击 [VIP](http://en.wikipedia.org/wiki/Virtual_IP_address) ，将您带到 NHL 应用程序。 * 有一个首页应用程序，可通过调用其他服务来服务首页小部件。 * 应用程序服务。 数据库前面是 Web 应用程序服务器，其中包含这项运动的所有业务逻辑。 * 通常一项运动只有一项应用程序服务。 * 应用程序已集群，因此集群中有 6-10 个应用程序实例，因此它们可以水平扩展 * 例如，当足球比赛是季节性的时候，根据季节需求的指示，应用实例的数量将增加，而应用实例的数量将减少。 * 迪士尼数据中心具有一些弹性功能，但希望亚马逊在此领域进行改进。 * 所有提要都流入体育数据存储库（SDR）。 * 一个非常大的 Oracle 数据库。 * 您在.com 网站上看到的相同统计信息与在电视和 Sports Center 上的某些面板上用于创建最低报价的统计信息相同。 * 使用 Web 服务呼叫的电视访问统计信息。 * 电视&广播不需要以与其他属性相同的方式进行缩放，因此它们可以直接使用 Oracle 数据库中的数据。 * Oracle AQ 流用于在 Oracle 端分发消息。 * 消息网关将消息分发到具有自己的 JMS 代理的数字媒体端。 * 位于康涅狄格州布里斯托尔。 * 像 ESPN.com 这样的数字媒体，都以创建提要和标准化消息以供企业内部消费的系统为前端。 * JMS Broker（WebSphere MQ）用于分发消息。 * 位于拉斯维加斯数据中心。 * .com 和 TV 位于不同的数据中心。 两个数据中心之间的延迟为 80 毫秒。 这两个 JMS 代理经过高度优化，可以尽快发送更新。 * PubSub 是 JMS 代理之上的体系结构。 应用程序侦听不同的主题，从队列中读取消息，解组到 JavaBeans 中，保留到数据库中，然后将数据直接推送到 Web 应用程序服务器中。 ## 统计资料从何而来？ （数据提取） * 每个数据库都有一个批处理或提要处理服务，负责更新所有统计信息，进度表，排名，得分等。 * 大多数数据来自第三方供应商或职业联赛本身。 * 直接进纸。 例如，他们与 MLB 有合作关系，数据直接从 MLB 发送。 使它们比其他服务具有更大的延迟优势。 * 体育馆供稿。 音高效果（音高位置）数据是从体育场发送的。 * 手动进纸。 ESPN 人员对游戏进行评分并手动将数据输入系统。 * 大学橄榄球没有统计信息供您查看，因此观看者可以输入数据。 * 故障转移。 如果自动馈送发生故障，它还可以用作备用故障转移系统。 出现问题时，可以手动接管游戏。 * 几乎每夜都有来自第三方的“官方”统计数据被覆盖。 有很多工具和系统可以确保提要正确，但更正后的数据会在晚上出现。 * 除非游戏正在进行，否则消息速率相对较低。 复杂，因为所有游戏事件都需要按顺序处理。 * 与.com 相同的统计信息也可以为 TV 供电，但是访问方式不同。 ## 应用程序服务 * 服务之间通过本地服务，远程 EJB 或 REST 进行直接呼叫，从而彼此对话。 * 数据中心内的首选模式是具有复杂缓存层的 EJB。 从 Java 客户端访问。 * 对于 REST 服务，有一个基于 TTL 的简单缓存层。 可从 PHP，Javascript 等访问。 * 在数字媒体方面，他们使用 Microsoft SQL Server，并在该 Java 应用程序服务器之上。 之所以进行扩展，是因为他们尝试不接触数据库。 它们会缓存所有内容，因此不会命中数据库。 ## 应用程序级别缓存 * 从历史上看，Web 应用程序中的对象缓存会保留表对象的内存哈希图。 W 将游戏永久缓存在哈希图中，直到游戏填满或通过数据库触发器到期为止。 缓存是按应用程序服务器复制的。 * 这种方法简单易行，在移动设备激增之前就可以使用，因为相对容易预测为 NFL 流量等服务所需的服务器数量。由于移动流量如此之大，过期消息不断涌现。 例如，随着游戏统计信息的更新，到期时间将过去，并且所有服务器都要求更新游戏分数。 现在将推送更改而不是过期。 ## 页面缓存框架 * 高性能页面和片段缓存。 * 缓存是另一种称为 Stout 的自有技术。 将 IIS Web 服务器与 ISAPI 页面缓存插件一起使用。 用 C ++编写。 在便宜的低端硬件上运行，因此极具成本效益。 仅使用 TTL 缓存。 每秒查看 1000 多个请求。 应用层每秒收到 100 多个请求。 应用程序层具有自己的缓存层。 数十个 Stout 服务器保护应用程序层。 应用服务器层保护数据库层，因此无需横向扩展数据库。 粗壮的应用程序服务器从循环中退出。 看清漆似乎更快。 * 缓存为王。 该体系结构最重要的部分是页面缓存层。 尽可能大量使用页面缓存。 * 每个 URI，基于 TTL 的到期时间。 透明地与负载平衡器进行对话，并说对于某些 URI，我们希望缓存一定的时间。 * 最高精度是低 TTL，并且会阻塞直到它返回数据。 访问速度最慢。 例如，用于记分板数据。 * 最低精度是指高 TTL 不会阻塞，它会返回脏数据。 最快的访问速度，用于不经常更新的数据。 例如，用于计划数据。 * 编辑内容和其他不经常更改的内容可以使用更长的 TTL 进行缓存。 * 自动降级无响应的服务器。 * 基于 TTL 的缓存不能很好地工作，因为它会导致频繁访问数据库。 想象一下，数十台服务器上的 TTL 为几秒钟，那么效果不佳。 * 在每个运动的高峰时间每秒节省数百万的数据库访问。 巨大的胜利。 当只有网络时，这一切都无关紧要，因为用户减少了，服务器也减少了。 在拥有更多用户和 50 多个服务器的移动时代，这些架构决定将产生巨大的变化。 * 他们的自定义解决方案的优势在于它可以在便宜/低端的硬件上运行。 * 负载均衡器的十万个请求 * 实际应用服务器的请求数为 100 * 10 个 MLB 服务器，而不是 50 个意味着节省大量资金 ## 通用对象模型 * 尽管他们有许多不同的数据库对应不同的运动，但在它们前面却有一个共同的对象模型。 在通用模型中尽可能多地添加跨运动项目通用的内容。 * 每个游戏都有一队，通常两队。 奥林匹克运动有竞争者。 通用供稿中的代码是相同的，它允许进行强大的操作，例如为我获取所有体育页面的所有比赛成绩，而不论运动如何。 * 在特定运动中，他们具有特定运动模型。 适用于 NFL，MLB 等。当他们详细了解某项运动的今天页面时，将使用运动专用模型。 * 一层隐藏了复杂性，然后在必要时退回特定于运动的模型。 ## 休眠 * TTL 缓存不起作用，因为数据在一天中并不经常更改，而在游戏中则经常更改。 * 很少是按标识查找的，它们大多是按查询查找的，例如给我提供整周的比赛次数，以便显示时间表，或者向我显示特定团队正在比赛的所有比赛。 数以百计的查询。 * 首先易于使用。 当事情变得更加复杂或您需要最佳性能时，很难有效地使用它。 * Ehcache 用作实体更新的二级缓存，效果很好。 * Hibernate 查询缓存机制不足，因此它们构建了 JPA 查询复制器。 * 状态经常更改（例如游戏得分），但是每个人的更改都是相同的。 不适用于个性化数据或幻想，不适用于所有用户的更改。 * 在获取更新的过程中，他们在实体端的侦听器使用规则引擎监视他们关心的所有更新。 根据更新内容过滤掉查询。 自特定时间开始，针对特定游戏的更新不应触发要求数据的查询。 该查询将重新运行并推出集群，因此所有用户都将得到更新，这将使数据库不堪重负。 ## 内容管理系统 * UI 不太好，重点是性能和规模。 * 两个子系统：CMS 和 DCS（动态内容系统）。 * CMS 编辑人员。 高度优化的查询。 针对更改故事的用户的优化 UI。 完整的关系数据库模型（SQL Server）。 只有几百个编辑器，因此它不需要水平缩放。 * DCS 使用 SQL Server，但已被规范化并存储为 Blob 类型。 检索速度很快。 编辑的数据在 CMS 中继续。 发布文章时，内容将序列化并放入 DCS。 DCS 是 10 个可以水平扩展的服务器的集群。 * 所有 76 个服务（MLB，NFL 等）都有一个知道如何与 DCS 对话的插件。 该插件还具有一个缓存。 因此，在发布时，将过期发送给每个客户端，以便它将从 DCS 中获取新内容。 * 由迪士尼 Internet Group 构建的模板引擎。 迪士尼拥有 ABC 和 ESPN。 十年前建立了称为 T 的语言。高性能。 比 JSF 更像 JSP。 多年来已经建立了十万个模板。 * 硬件方面便宜，因此它们必须在软件方面高效，这就是为什么他们没有迁移到其他速度较慢的模板系统的原因。 ## 实时比分（ESPN.com） * 大多数内容都不会很快更新。 编辑内容无法快速更新。 对于分数，他们希望获得最快的分数，因此前端和后端的处理方式有所不同。 * 主供稿模板，其中包含游戏的所有数据。 一个进程轮询模板以获取更新，并将更改放入数据库的快照表中。 一切都被称为 Caster 的东西。 这是一种自定义技术，就像网络套接字存在之前的网络套接字一样。 从前端到后端有一个开放的套接字连接，这是大量的 Caster 服务器集群，并且更新通过该流传输。 前端有一个 Flash 连接器。 高端服务器除了管理与前端闪存连接器的连接外，什么也不做。 它可以进行 10 万多个并发的开放套接字连接。 每次更新快照时，都会通过适当的连接发送快照。 页面上运行的 JavaScript 读取更新并将其显示在页面上。 * Flash 连接器会每隔 30 或 60 秒降级为轮询。 糟糕的带宽使用率。 将网络套接字视为替换项。 ## 个性化设置 * 个性化就是告诉他们您最喜欢的东西是什么：体育，球员，球队，幻想数据。 这些是您特有的。 * 与 ESPN.com 的其余部分完全不同，并且有很多特定要求。 * 难以缓存，因为与其他缓存方案一样，它是 1-1 而不是 1。 并且数据必须在任何地方（.com，手机，电视）都跟随您 * 有很多个性化数据。 超过 500GB。 无法适应单个 JVM 或数据库，而该 JVM 或数据库无法按每秒 10 万个请求的吞吐量进行扩展。 * 使用 IBM eXtreme Scale 构建数据网格。 * 这是一个分布式的内存哈希图。 购买了 7 台服务器，每台服务器具有 96GB 的 RAM。 软件自动平衡数据并将其分区到 JVM。 * JVM 的最大问题是垃圾收集，因此每个服务器上运行 100 个 JVM，以最大程度地减少垃圾收集，并且软件会自动分片所有内容。 * 仅存储您独有的东西。 如果您是洋基队的粉丝，他们只是存储洋基队的 ID，而不是存储有关洋基队的所有数据。 * eXtreme Scale 的设置比 Coherence 困难，但价格便宜，并且它们从 IBM 获得的支持比 Oracle 多。 * Composer 系统知道如何与 NFL 和 MLB 等所有服务进行对话，并且知道如何与网格进行对话。 因此，要构建个性化页面，他们将转到网格并为您喜欢的团队提供正确的服务，并以 JSON 供稿的形式构建时间表，得分，幻想数据，专栏作家等。 在客户端，数据被组装。 借助 6 个用于 Composer 的商用服务器，每秒可处理数以万计的请求。 ## 奇幻游戏 * 非常不同的用例。 幻想数据是根据实际统计数据计算得出的，然后转换为“组合”数据，因此它们具有不同的提取过程。 ## API * 用于编辑内容的 API。 数据权利很棘手，但它们拥有内容，因此就是发布的内容。 * 他们面临的最大问题之一是招募新人并入职。 拥有文档和一致的 API 可以在防火墙之外为开发人员提供 API 的帮助，但在内部却可以帮助，因为它更易于构建应用程序。 * EJB 层的一些技巧无法应用到 API，因此尚未完全弄清。 * 弄清楚 API 很困难。 开发人员希望一次调用所有数据。 但是他们倾向于更细粒度的 API，这将需要更多的调用和开发人员的更多工作。 * Mashery 用于通过 TTL 缓存保护 API。 不同级别的轮询。 外部用户每分钟只能处理这么多请求。 在内部，限制不太严格。 * 最复杂的运动是足球，因为有这么多的提要提供商必须与他们合作来获取数据。 特别提款权团队将所有提要标准化为足球提要。 如果 Feed 出现问题，他们可以接管 Feed 并将其手动添加到系统中。 ## 特殊效果 中的 [ESPN 新兴技术对高分辨率图像](http://on-demand.gputechconf.com/gtc/2013/presentations/S3487-ESPN-NVIDIA-GPUs-High-Res-Imagery.pdf) 的 NVIDIA GPU 解决方案的使用。 细节不多，因此这些基本上只是幻灯片中的要点，但这很酷，看上去就像是屏幕上的魔术。 * ESPN 是高级实时图形的创新者，他们将 GPU 用于高价值功能，例如 Huck-O-Meter，HRD Ball Track，Snap Zoom，Ref Mics，Sky Cam，Ultra-Mo，播放器跟踪， 1st &十号线，K 区，获得艾美奖的 EA 虚拟剧本以及更多其他东西 * 系统中的每个 GPU 分为输入，输出，输入/输出或计算引擎 * 所有 GPU 均可通过 CUDA 进行对等访问 * 可以将多个输入卡和输出卡分配给 GPU * 硬件抽象层允许通过 gpuDirect 来自多个制造商的视频 I / O 硬件 * 每个 GPU 管道均可处理输入和输出的独特视频格式 ## 未来 * 如有必要，对于具有运动专用扩展名的所有数据都具有通用的 API 。 * 移至缓存推送模型 （不会过期）。 借助移动和水平模型以及越来越多的服务器，越来越多的服务器将通过数据库进行更新。 由于他们没有庞大的数据库，因此这成为了瓶颈。 如果在 NFL 周日停止更新分数，那将是不好的一天。 * 随着数据的传入，将其整理成通用的对象模型格式。 它异步保存到数据库，也异步推送到集群的其余部分。 例如，当发生某些更改时，源服务器将直接发送给使用者，而不是 6 台服务器，而无需将其发送到数据库。 * 更松散耦合的服务 。 通过 Java 远程处理，在本地（相同的 JVM）。 * 为所有运动创建一项服务 。 * 利用泛型和代码生成 加快转换其余部分的过程。 * 到处缓存 以保护所有组件免受负载的影响。 * 提供更多个性化的内容 ，并随处可见（.com，手机，电视）。 ## 经验教训 * **缓存推送模型**。 随着数据的传入，异步地保留到数据库中，并且也异步地推送到集群的其余部分。 更改被直接推送给使用者，这意味着使用者可以踩踏数据库以获取新的更改。 在可预测资源的更静态世界中不是必需的，而是在移动世界中可伸缩性的关键。 * **足够好就足够** 。 当您刚开始使用某项技术时，您必须自己构建很多东西，以后随着新的更好的代码的出现，它们看起来会很愚蠢。 但是您需要编码并使其正常工作，因此足够了。 * **您可以做一些** 。 您想到了 ESPN，又想到了行业领导者。 但是，ESPN 很少使用计算资源，也很少使用开发人员来创建高价值，高度可见的系统。 他们考虑效率。 一家拥有网络遗产的公司可能只是以机器便宜为由添加了所需的机器，而 ESPN 实际上考虑节省金钱以获取利润。 一个奇怪的概念。 * **了解您的听众** 。 决策是由目标决定的。 随处可见的设备，快速准确的数据，广泛的覆盖范围和高可用性。 这些价值反映在体系结构和决策过程中。 * **手动故障转移** 。 他们的系统架构的一个有趣的方面是，既包括手动输入游戏数据，又包括自动订阅源失败时的手动故障转移策略。 大多数人可能不会考虑将其作为一种选择，但是它对实现拥有快速准确数据的目标高度奉献。 * **针对不同用例的定制系统** 。 他们让不同运动和服务的需求来驱动体系结构。 这样就可以进行并行开发并完成工作。 例如，他们建立了一个查询缓存机制，专门针对游戏更新和发行进行了优化，因为这是他们的事。 * **使不同的事物看起来相同** 。 尽管千变万化的架构方法在巨大的变化和发展中非常有用，但当您想要创建通用的 API 服务层或响应移动或个性化等压力因素而进行系统范围的优化时，它确实很烂。 因此，相反的作用是建立通用的体系结构，通用的数据模型，然后在必要时退回特定类型的模型。 * **缓存以保护数据库** 。 根本不是一个新主意，但这是一个对 ESPN 来说非常有效的核心可伸缩性策略。 这使他们不必在数据库层上投入大量资金。 但是，个性化，这是未来的潮流，是缓存破坏者。 * **一致性可帮助所有开发人员** 。 拥有文档和一致的 API 可以在防火墙之外为开发人员提供 API，但在内部也可以提供帮助，因为构建应用程序更加容易。 很棒的帖子，关于 ESPN 从未想过/知道的东西，在网络/数据库相关技术上发挥了如此重要的作用。 不过有一个问题。 如今，在大数据和网络规模方面存在很多障碍。 您提到它们主要依赖于 Oracle 数据库以及 MS SQL Server 数据库上的某些其他服务。 关于 NoSQL，网络规模以及传统 RDBMS 如何无法扩展的关系，有很多可以说是“大战”。 ESPN 会考虑吗？ 这些天，我在工作中进行了一些友好的讨论，因为他们正试图强加 mongo db，仅仅是因为 MS SQL Server“无法扩展” ... ejem？ 如果您不打算透露有关该基础架构的详细信息，则无需说明在如此小的基础架构上要完成多少工作。 并不是说他们正在运行带有 8 gig RAM 的四核 Xeon。