# Google 如何創造只有他們才能創造的驚人的數據中心網絡
> 原文: [http://highscalability.com/blog/2015/8/10/how-google-invented-an-amazing-datacenter-network-only-they.html](http://highscalability.com/blog/2015/8/10/how-google-invented-an-amazing-datacenter-network-only-they.html)

最近以自己的驕傲而自豪的 Google [宣布了](http://googlecloudplatform.blogspot.com/2015/06/A-Look-Inside-Googles-Data-Center-Networks.html) :
> 今天在 2015 年開放網絡峰會上,我們將首次揭示五代內部網絡技術的詳細信息。 從十年前我們的第一個內部數據中心網絡 Firehose 到最新一代的 Jupiter 網絡,我們已經將單個數據中心網絡的容量提高了 100 倍以上。 我們當前的產品-Jupiter 織物-可以提供超過 1 PB / sec 的總 對等帶寬 。 從角度來看,這樣的容量足以使 100,000 臺服務器以 10Gb / s 的速度交換信息,足以在不到 1/10 秒的時間內讀取國會圖書館的全部掃描內容。
Google 的數據中心網絡是使 Google 真正發揮作用的背后的魔力。 但是什么是“雙向帶寬”,為什么重要呢? 早在 [不斷變化的架構中,我們討論了雙向帶寬:新的數據中心網絡將使您的代碼和數據免費](http://highscalability.com/blog/2012/9/4/changing-architectures-new-datacenter-networks-will-set-your.html) 。 簡而言之,雙向帶寬是指 Google 服務器用來相互通信的網絡。
歷史上,數據中心網絡的定位是與用戶交談。 假設某網頁請求來自瀏覽器。 該請求將發送到服務器,并通過僅與其他幾臺服務器(甚至根本沒有服務器)進行通信來制作答復,然后將答復發送回客戶端。 這種類型的網絡稱為面向北方/南方的網絡。 實施請求幾乎不需要內部溝通。
隨著網站和 API 服務的日趨豐富,這一切都發生了變化。 現在,可以進行 [數以千計的](http://highscalability.com/blog/2012/6/18/google-on-latency-tolerant-systems-making-a-predictable-whol.html) 后端請求來創建單個網頁。 令人振奮。 這意味著通信已從與用戶交談的主導轉變為與數據中心內其他計算機的交談。 因此,這些被稱為東西方網絡。
向東方/西方主導的通信方式的轉變意味著數據中心網絡需要不同的 [拓撲結構](https://en.wikipedia.org/wiki/Network_topology) 。 舊的傳統 [胖樹](https://storagemojo.com/2008/08/24/fat-trees-and-skinny-switches/) 網絡設計已經淘汰,需要采取一些新的方法來代替它。
Google 一直處于開發新的豐富服務支持網絡設計的最前沿,這主要是因為他們的指導思想是將 [數據中心視為計算機](http://research.google.com/pubs/pub35290.html) 。 一旦您的數據中心成為計算機,您的網絡就相當于一臺計算機上的 [背板](https://en.wikipedia.org/wiki/Backplane) ,因此它必須盡可能快且可靠,因此遠程磁盤 并且可以像訪問本地存儲一樣訪問遠程存儲。
Google 的工作圍繞著三個有計劃的攻擊計劃:使用 [Clos 拓撲結構](https://en.wikipedia.org/wiki/Clos_network) ,使用 [SDN](https://www.youtube.com/watch?v=ED51Ts4o3os) (軟件定義網絡),并以自己的 Googlish 方式構建自己的自定義設備。
到目前為止,我們對 Google 的網絡設計的了解有限。 Google 研究員和 Google 聯網技術負責人 [Amin Vahdat](http://research.google.com/pubs/AminVahdat.html) 雖然沒有完全訪問權限,但在 精彩演講: [ONS [開放網絡峰會] 2015:星期三主題演講](https://www.youtube.com/watch?v=FaAZAII2x0w) 。 還有一篇論文: [Jupiter Rising:Google 數據中心網絡](http://conferences.sigcomm.org/sigcomm/2015/pdf/papers/p183.pdf) 的 Clos 拓撲和集中控制的十年。
為什么要比通常提前發布細節? 谷歌與亞馬遜之間存在真正的競爭,因此他們需要找到引人注目的差異化點。 谷歌希望他們的數據中心網絡就是其中之一。
那么,是什么讓 Google 與眾不同? 整體訊息:
* 摩爾定律的終結意味著程序的構建方式正在發生變化。
* Google 知道了。 Google 知道如何建立良好的網絡并實現適當的數據中心平衡。
* 您可以利用 Google 的云平臺(與支持 Google 搜索的平臺相同)的創新和功能來實現繁榮。
* 所以爬上去,網絡很好!
夠了嗎? 也許這不是一個具有廣泛吸引力的信息,但它可能會找到有區別的買家的房屋。
我的演講重點:
* **我們不知道如何構建可提供大量帶寬的大型網絡**。 Google 說,他們的網絡提供了 1 Pb / sec 的總二等分帶寬,但事實證明這還遠遠不夠。 為了支持數據中心的大型計算服務器,您需要 5 Pb / sec 的網絡。 請記住,今天整個互聯網可能接近 200Tb / s。
* **在大型群集**上安排作業效率更高。 否則,您會將 CPU 留在一個地方,將內存留在另一個地方。 因此,如果您可以正確地構建系統,那么數據中心規模的計算機將為您帶來確定的規模經濟。
* **Google 利用從服務器和存儲世界中汲取的經驗教訓構建了數據中心網絡系統**:橫向擴展,邏輯上集中化,使用商品組件,從不管理任何單一組件。 統一管理所有服務器,存儲和網絡。
* **I / O 差距很大**。 阿明說必須解決,如果沒有解決,我們將停止創新。 通過分類可以增加存儲容量。 機會是像訪問本地數據中心一樣訪問全局數據中心存儲。 使用 Flash 和 NVM 會越來越難。 閃存和 NWM 的新層將完全改變編程模型。 注意:很遺憾,他沒有擴大這個概念,我非常希望他能這樣做。 阿敏,我們可以談談嗎?
在一個好故事中,您所尋找的是扮演核心身份角色的角色。 在這里,我們看到 Google 運作的獨特愿景來自其在構建可擴展軟件系統方面的豐富經驗而有機發展。 也許只有 Google 才能勇于遵循自己的愿景,并建立與公認的智慧完全不同的數據中心網絡。 這需要巨大的精力。 這造就了一個好故事。
這是我在演講中毫無希望的不足:
* 十年來,數百人為這項工作做出了貢獻。
* 自從大約 30 年前將套接字引入 BSD 以來,分布式編程就面臨著同樣的挑戰。 這將改變。
* 隨著摩爾定律的結束,我們對計算的思考方式必須改變,而分布式計算的方式將要改變。
* 計算的關鍵部分以及人們如何構建自己的系統都圍繞存儲。
* 我們已經看到,遵循摩爾定律,存儲容量有了巨大的增長。
* I / O 間隙仍然存在。 處理器與他們需要處理的基礎數據之間的距離正在不斷增加。
* 我們可以認為遍布整個建筑物的磁盤可用于任何服務器。 這是太棒了。 同時,鑒于我們擁有的處理能力,它們正在越來越遠地尋找。
* 分布式計算環境中的大規模下一代閃存仍未開發。
* 在計算的未來意義上,網絡將扮演至關重要的角色。
* 聯網處于拐點。 計算手段將在很大程度上取決于您構建強大網絡的能力。
* 因此,數據中心網絡是關鍵的區別因素。
* Google 建造了建筑規模的計算機。 計算一行一行,存儲一行一行。
* 多年來,Google 建立了軟件基礎架構以利用其硬件基礎架構:
* GFS(2002),MapReduce(2004),BigTable(2006),Borg(2006),Pregel(2008),Colossus(2010),FlumeJava(2012),Dremel,Spanner。
* 這些努力中的許多已經定義了當今進行分布式計算的含義。
* 沒有世界一流的網絡基礎架構,您將無法建立世界一流的分布式計算基礎架構。 您如何構建像 GFS 這樣的系統來利用 100,000 個磁盤,而沒有世界一流的網絡將它們整合在一起?
* Google 在網絡方面的創新:
* Google Global Cache(2006 年):如何交付內容,包括來自世界各地的視頻和靜態內容)
* 守望臺(2008)
* Freedome:校園級互連
* Onix(2010 年
* BwE(2010)
* B4:Google 的軟件定義 WAN,可將全球所有數據中心連接在一起。 它比面向公眾的網絡更大,并且增長速度更快。
* Jupiter(2012):高帶寬數據中心規模聯網
* Andromeda(2014):網絡虛擬化。 我們如何利用我們的基礎網絡基礎架構,并將其拆分成單個虛擬機,以至于它們擁有自己的高性能網絡? 我們如何打開 Goog??le 一直用于其服務(例如負載平衡,DDoS 保護,訪問控制列表,VPN,路由等)的相同類型的網絡虛擬化,以及如何使這些隔離網絡在原始硬件上運行(如果可用) ?
* QUIC
* gRPC:Google 內部使用的多平臺 RPC,負載平衡,應用程序級流控制,取消調用,序列化,開源,HTTP / 2。 構建分布式服務的良好基礎。
## 數據中心網絡
* 數據中心網絡與傳統 Internet 網絡不同。
* 由單個組織運營,并且已預先計劃。 必須發現互聯網才能看到它的外觀。 您實際上知道網絡在數據中心中的外觀。 您已經計劃好了。 您建立了它。 因此,您可以集中管理它,而不用隨便發現它。 由于它是在單一組織的控制下,因此您可以運行的軟件可能會大不相同。 它無需與 20 年的歷史遺存進行互操作,因此可以針對您的需要對其進行優化。
* 吸引人們加入網絡的通常是問題的美。 美麗可能意味著這是一個難題。 是否可以將問題定義為更簡單,更可擴展且更容易?
* Google 需要一個新的網絡。 大約十年前,谷歌發現傳統的網絡架構,包括硬件和軟件,**無法滿足**的帶寬需求以及數據中心中分布式計算基礎架構的規模。
* 我們可以買嗎?
* Google 無法以任何價格購買能夠滿足 Google 分布式系統要求的數據中心網絡。
* 我們可以運行它嗎?
* 以箱為中心的部署產生了高**操作復雜性**的成本。 即使 Google 買了他們能買到的最大的數據中心網絡,用于操作這些網絡的模型還是圍繞著具有單獨命令行界面的單個盒子。
* Google 已經知道如何處理成千上萬的服務器,就像它們是一臺計算機一樣,如何處理成千上萬的磁盤,就像它們是一個存儲系統一樣。 必須像管理一千個交換機一樣管理一千個交換機**的想法沒有多大意義,而且似乎不必要地困難**。
* 我們將構建它。
* 受服務器和存儲領域的經驗啟發: **橫向擴展** 。
* 無需弄清楚如何購買下一個最大的網絡或下一個最大的路由器,而是可以像使用服務器和存儲一樣,通過使用**個附加商品元素**來擴展交換和路由基礎結構。
* 當出現需要**插入另一個網絡元素**以提供更多端口和更多帶寬時,為什么不這樣做呢?
* 允許 Google 建立橫向擴展數據中心網絡的三個關鍵原則:
* **Clos 拓撲結構** 。 這個想法是利用小型商品交換機來構建一個可以無限擴展的無阻塞超大型交換機。
* **商業硅** 。 由于 Google 并未建立廣域網互聯網基礎架構,因此他們不需要龐大的路由表或深度緩沖。 這意味著商業硅芯片可以完成在數據中心中構建基于 Clos 的拓撲的工作。
* **集中控制** 。 軟件代理知道網絡的外觀,設置路由,并對基礎計劃中的異常做出反應。 知道網絡的形狀后,管理網絡要比不斷嘗試發現其外觀要容易得多。 如果要更改網絡,則可以告訴集中控制軟件更改網絡。
* 數據中心網絡的方法也適用于園區網絡,將建筑物連接在一起并連接到廣域網。 B4 和 Andromeda 受到數據中心網絡工作的啟發和啟發,他們多年來一直在練習構建自己的硬件和集中控制基礎結構。
* 在過去 6 年中,數據中心帶寬增長了 50 倍。
* 需要交付給 Google 服務器的帶寬超過了摩爾定律。
* 這意味著要滿足 Google 必須能夠擴展的帶寬需求,就不可能不斷地淘汰舊設備并建立新的網絡。
* 規模驅動架構。
* 當今的典型網絡(不一定是 Google)可能具有 10K +交換機,250K +鏈接,10M +路由規則。 **如此規模的網絡處理方式與規模較小的網絡**根本不同。
* 為什么要建立整個數據中心規模的網絡?
* 一些最大的數據中心擁有 10 兆瓦和 10 兆瓦的計算基礎架構。
* 如果您無法大規模調度,則有大量的 **資源擱淺** 。 想象一下需要在共享基礎結構上運行的許多不同的作業。 如果必須在一個群集的邊界內調度作業,并且您有 101,000 個服務器群集,而您有 110,000 個服務器群集,那么如果可以在 10,000 個服務器群集中任意調度,則效率會好得多。 如果您可以將作業放置在 10,000 臺服務器中的任何位置,而不必放在 1,000 臺服務器中,那么這個數字就顯得非常少。 因此,如果可以構建一個網絡以擴展到整個建筑物,那么從計算和磁盤上獲得的效率將更高。 這些最終成為主要成本。 該網絡可能非常便宜,并且可以成為計算和存儲的促成因素。
* “資源擱淺”是指將一個 CPU 留在一個地方,而將內存留在另一個地方( [源](http://jturgasen.github.io/2014/10/26/tech-takeaway-012-cluster-management-at-google/) )。
* 平衡您的數據中心。
* 一旦達到建筑物的規模,就必須確保提供足夠的帶寬。
* 不平衡的數據中心缺少**某些資源,這限制了您的價值**。 如果一種資源稀缺,則意味著其他一些資源處于閑置狀態,這會增加您的成本。
* 通常,在數據中心規模上,最稀缺的資源是網絡。 由于我們不知道如何構建可提供大量帶寬的大型網絡,因此網絡配置不足。
* 帶寬。 阿姆達爾還有另一部法律。
* 對于并行計算,每 1 Mhz 計算需要 1 Mbit / sec 的 IO。
* 舉例來說,僅在您附近的未來數據中心中,計算服務器具有 64 * 2.5 Ghz 內核,然后為了平衡每個服務器大約需要 100 Gb / s 的帶寬。 這不是本地 IO。 本地 IO 無關緊要。 您需要訪問數據中心范圍的 IO。 數據中心可能有 5 萬臺服務器; 100k + IOPS 的閃存存儲,100 毫秒的訪問時間,PB 級存儲; 將來,其他一些非易失性存儲器技術將具有 1M + IOPS,10 微秒的訪問時間和 TB 的存儲量。
* 因此,您將需要 5 Pb / s 的網絡和具有相應功能的交換機。 即使超額預訂比率為 10:1,這也意味著您將需要 500Tb / s 的數據中心網絡來接近平衡。 從角度來看,一個 500Tb / s 的網絡比今天的整個 Internet 容量更大(可能接近 200Tb / s)。
* 延遲。 為了實現存儲基礎架構分解的目標,您需要可預測的低延遲。
* 磁盤速度很慢,訪問延遲為 10 毫秒,因此很容易使它們看起來很本地。 網絡比這快。
* Flash 和 NVM 困難得多。
* 可用性。 您的計算價值很高,需要不斷引入新服務器,需要將服務器升級到 1G-> 10G-> 40G-> 100G->?
* 無法拆除建筑物以進行升級。 投資太大了。 刷新網絡和服務器必須保持不變。 舊的必須與新的一起生活,而不能完全中斷很大的容量。
* 擴展網絡無效。 無法在遍布整個數據中心的網絡上進行焦土升級。
* Google Cloud Platform 建立在支持 Google 規模,性能和可用性的數據中心網絡基礎架構上。 這是向公眾開放的。 希望下一個出色的服務可以利用此基礎結構而無需發明它。
* 關鍵的挑戰是在提供隔離的同時打開硬件的原始容量。
## 軟件定義的網絡
* 網絡是實現下一代計算機體系結構的關鍵因素。 SDN 將扮演關鍵角色。
* SDN 是關于抽象并管理復雜性的軟件 [控制平面](http://sdntutorials.com/difference-between-control-plane-and-data-plane/) 。 這是要超越框框。 這是關于將網絡接口更改為標準協議而不是標準協議,而是關于管理復雜性,將其隱藏并可以使 10,000 臺交換機看起來像一個的軟件控制平面。
* 硬件將在那里。 您如何管理它,就像它是一個大實體一樣? 這就是服務器端,存儲端和網絡端的問題。
* Google 開始了,每個人都開始使用四柱集群網絡來構建數據中心網絡。 網絡的大小和帶寬由他們可以購買的最大路由器決定。 當需要更多容量時,他們需要使用更大的路由器來構建另一個數據中心網絡。
* 圍繞 Clos 拓撲的方法是使用商用交換芯片,并構建超過 5 代的網絡,如下所示:
## 
* 基于 Clos 的分層拓撲結構表示在 Clos 拓撲結構中利用了商戶硅片,可在建筑物規模上提供高帶寬。 為機架式交換機頂部供電的同一交換機芯片將服務器連接在一起,也為聚合模塊供電,這些聚合模塊可在一定數量的機架之間提供連接。 相同的硅為將邊緣聚合層連接在一起的脊柱層提供動力。
* 十年前,總帶寬為 2 兆比特/秒。 最新一代的 Jupiter 結構提供 1.3 Pb / s 的帶寬。 他們的 Jupiter Superblock 交換機提供 80Tb / s 的帶寬,它通過 OpenFlow 托管 SDN 軟件堆棧,并受到遠程控制。 交換機將利用 Google 已獲得的余額為所有數據中心供電。
## 網絡控制
* 早期,Google 面臨著如何構建其控制平面的選擇。 使用現有的服務提供商相關的 OSPF,ISIS,BGP 等堆棧。或者構建自己的堆棧。
* 他們出于多種原因選擇構建自己的。
* Google 十年前考慮的拓撲需要多路徑轉發才能起作用。 為了獲得所需的帶寬,需要在源目標之間建立很多路徑。 現有協議不支持多路徑。 他們是關于連通性的。 查找從源到目的地的路徑,而不是最佳路徑,而不是多個路徑。
* 十年前,還沒有高質量的開源堆棧。
* 所有協議都是基于廣播的,而 Google 希望以此規模運作,他們擔心基于廣播的協議的可擴展性。
* 安裝基于廣播的協議后,您必須配置每個單獨的框以使用它們,而 Google 對此并不滿意。
* 將這一切與從 Google 學到的新常規知識結合在一起,以大規模構建大規模系統:
* **邏輯上將** (這并不意味著單個服務器)集中在具有點對點數據平面的分層控制平面的情況下。 看到它一遍又一遍地播放,并且也與數據中心網絡一起播放。
* **向外擴展** 比向上擴展方便得多。 使用 GFS,MapReduce,BigTable 和 Andromeda 可以看到這種情況。
* **集中式配置和管理** 大大簡化了系統的所有方面以及部署。
## 相關文章
* [在 HackerNews](https://news.ycombinator.com/item?id=10037960) 上/ [木星在 HackerNews](https://news.ycombinator.com/item?id=9977414) 上崛起
* [Google 在大規模定義軟件定義的網絡功能虛擬化方面的經驗](https://www.youtube.com/watch?v=n4gOZrUwWmc) (Google 視頻,2014 年)
* [直觀地了解 Google 在全球網絡基礎架構中的創新](http://googlecloudplatform.blogspot.com/2015/08/a-visual-look-at-googles-innovation-in.html)
* [撤消 Google 網絡基礎架構上的帷幕](http://googleresearch.blogspot.com/2015/08/pulling-back-curtain-on-googles-network.html)
* [Google 數據中心網絡內部的外觀](http://googlecloudplatform.blogspot.com/2015/06/A-Look-Inside-Googles-Data-Center-Networks.html) (Google 博客文章 [在 HackerNews](https://news.ycombinator.com/item?id=9734305) 和 [在 Reddit 上](https://www.reddit.com/r/sysadmin/comments/3a7kwc/a_look_inside_googles_data_center_networks/) )
* [木星崛起:Google 數據中心網絡中 Clos 拓撲和集中控制的十年](http://conferences.sigcomm.org/sigcomm/2015/pdf/papers/p183.pdf) (Google 論文,2015 年)
* [服務提供商網絡的 SDN 堆棧](https://www.youtube.com/watch?v=ED51Ts4o3os) (Google 視頻,2012 年)。
* [Show 222-介紹 OpenClos 項目](http://packetpushers.net/show-222-introducing-openclos-project/) (來自 Packet Pushers 的網絡實體)
* [Google 向其最高機密的數據中心敞開大門](http://www.wired.com/2012/10/ff-inside-google-data-center/) (有線,2012 年)
* [不斷變化的體系結構:新的數據中心網絡將使您的代碼和數據自由自如](http://highscalability.com/blog/2012/9/4/changing-architectures-new-datacenter-networks-will-set-your.html) (來自 HighScalability)
* [VL2:可擴展且靈活的數據中心網絡](http://research.microsoft.com/apps/pubs/default.aspx?id=80693) (微軟提供的文件)
* [Google On Latency Tolerant Systems:由不可預測的部分組成可預測的整體](http://highscalability.com/blog/2012/6/18/google-on-latency-tolerant-systems-making-a-predictable-whol.html) (來自 HighScalability)
* [介紹數據中心結構,下一代 Facebook 數據中心網絡](https://code.facebook.com/posts/360346274145943/introducing-data-center-fabric-the-next-generation-facebook-data-center-network)
* [云系統管理的實踐:設計和操作大型分布式系統](http://the-cloud-book.com/) (看起來像一本好書)
* [十年來 Google 自家的數據中心網絡](http://www.theplatform.net/2015/06/19/inside-a-decade-of-google-homegrown-datacenter-networks/)
* [技術要點 012:Google 的集群管理](http://jturgasen.github.io/2014/10/26/tech-takeaway-012-cluster-management-at-google/)
* [評估倉庫規模計算中的工作包裝](http://www.e-wilkes.com/john/papers/2014-IEEECluster-job-packing.pdf)
* [萬億級計算-事實還是虛構?](http://www.ipdps.org/ipdps2013/SBorkar_IPDPS_May_2013.pdf)
* [使數據中心的高效率和低延遲實現協調](http://web.stanford.edu/~davidlo/resources/2015.thesis.pdf)
* [ONS 2015:星期三主題演講-Mark Russinovich](https://www.youtube.com/watch?v=RffHFIhg5Sc) -微軟在網絡領域的發展。
這是對現代 Web 規模數據中心網絡的很好描述。 Clos 面料又是新的了。
除了谷歌,其他大公司也在做類似的事情。 例如,Microsoft 正在將 BGP 與 SDN 控制器一起使用。
至少可以說,這是進入數據中心工程的激動人心的時刻!
去年在英特爾開發人員論壇(IDF 2014)上宣布了“ Fabrics 上的 NVMe”協議。 它應該標準化對低延遲 NVM 設備的遠程訪問。
在您寫“今天整個互聯網可能接近 200Tb / s”的地方,您的意思可能是 200Pb / s,對嗎?
一篇關于 CloS 面料的好文章。
Google 的體系結構可能適合搜索,但是 Google 的后端存在可靠性問題,只需瀏覽一下 Google Drive 論壇,所有用戶報告丟失的數據即可。
非常有趣的細節!
亞歷山德羅,我回去檢查。 他肯定說大約在 19:26 時,Internet 的速度約為每秒 200 兆位,盡管他說很難知道確切的數字。
@Alessandro Alinone,那條大約 200Tb / s 的線路也把我甩了!
非常好的描述。
- 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 內容平臺的經驗教訓