# 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。