PS：Google，無疑是互聯網時代最閃亮的明星。截止到今天爲止，Google美國主站在Alexa排名已經連續3年第一，Alexa Top100中，各國的Google分站居然霸佔了超過20多個名額，不得不使人感嘆Google的強大。不論什麼時候，不論何地，也不論你搜索多麼冷門的詞彙，只要你的電腦鏈接互聯網，只要你輕輕點擊「google搜索」，那麼這一切相關內容google都會在1秒鐘以內所有搞定，這甚至比你查詢「個人文檔」都要快捷。這也就是爲何Google創業12年，市值超過2000億美圓的緣由。python
有人可能認爲Google擁有幾臺「藍色基因」那樣的超級計算機來處理各類數據和搜索，事實是怎樣的呢？下面咱們就將詳細解析神奇Google的神奇架構。linux
硬件：git
截止到2010年，Google大約有100萬臺服務器，有超過500個計算機集羣，處理不一樣地域的不一樣任務。惋惜服務器的詳細配置和最新集羣的具體狀況，在多個文獻庫裏面都查詢不到，我我的理解，這可能屬於商業機密。大概也是由於機密的緣故，強大的Google計算機集羣並無遞交Top500計算機的申請，多年來咱們在Top500中都看不到Google的影子。(進入Top500須要提交而且公開本身計算機系統的詳細配置)不過根據文獻資料，能夠確定的是，這100萬臺服務器都不是什麼昂貴的服務器，而是很是普通的PC級別服務器，其中的服務器硬盤在兩年前還廣泛是IDE接口、而且採用PC級主板而非昂貴的服務器專用主板。Google的集羣也所有是本身搭建的，沒有采用Myricom 的 Myrinet或者Giganet 的 cLAN等先進昂貴的集羣鏈接技術，Google各個數據中心和服務器間不一樣的耦合程度都隨需而定自行鏈接。
那麼Google的存儲呢？Google存儲着海量的資訊，近千億個網頁、數百億張圖片。早在2004年，Google的存儲容量就已經達到了5PB。可能不少讀者一開始都認爲Google採用了諸如EMC Symmetrix系列磁盤陣列來保存大量的資訊，可是Google的實際作法又一次讓咱們大跌眼鏡——Google沒有使用任何磁盤陣列，哪怕是低端的磁盤陣列也沒用。Google的方法是將集羣中的每一臺PC級服務器，配備兩個普通IDE硬盤來存儲。不過Google倒也不是都是什麼設備都落後，至少這些硬盤的轉速都很高，並且每臺服務器的內存也還算比較大。最大的電腦DIY消費者是誰？恐怕Google又登上了這個DIY寶座。Google的絕大部分服務器甚至也不是採購什麼大品牌，而是購買各類廉價零件然後自行裝配的。有趣的是，Google很是不滿意現存的各類PC電源的功耗，甚至還自行設計了Google專用服務器電源。程序員
很快，咱們就有了疑問。這樣的一個以PC級別服務器搭建起來的系統，怎麼能承受巨大的工做負載呢？怎麼能保證高可用性呢？的確，這些低端的服務器常常出現故障——硬盤壞道、系統宕機這類的事故其實天天都在100萬臺服務器中發生。而Google的方法是設立鏡像站。以Google主站爲例，2003年就在美國硅谷和弗吉尼亞設立了多個鏡像站。這些鏡像站其實不是傳統的鏡像站。真正的鏡像站是雙機熱備，當一臺服務器宕機時，另外一臺服務器接管相關任務。而Google的鏡像站其實真正的職責是DNS負載均衡，因此有的Google鏡像站自己還有本身的鏡像站。這裏舉例說明Google鏡像站的做用：一個訪問，DNS正常解析到A處，但當A處負載過大時，DNS服務就將域名解析到B處，這樣既達到了冗餘，也縮減了投資。因爲不是雙機熱備，某一時間，鏡像站的內容可能略有不一樣，不過對於精確度要求不那麼高的普通檢索而言，並非問題。數據庫
平臺：GFS/MapReduce/ BigTable/Linux編程
GFS/MapReduce/ BigTable/這三個平臺，是Google最引覺得傲的平臺，所有架構在Linux之上。緩存
首先咱們來看一看GFS（Google File System）Google文件系統。咱們知道，通常的數據中心檢索時候須要用到數據庫系統。可是Google的狀況很特殊——Google擁有全球上百億個Web文檔，若是用常規數據庫系統檢索，那麼檢索速度就可想而知了。所以，當Crawlers採集到許多新的Web後，Google將不少的Web都聚集到一個文件裏進行存儲管理，並且Google將Web文件壓縮成Chunk塊，進一步減小佔用空間(64MB一個chunk)。最後，Google只檢索壓縮後的部分。而GFS(Google File System）正是在這樣的檢索技術上構建的文件系統，GFS包括了GFS Master服務器和Chunk服務器。以下圖所示，系統的流程從GFS客戶端開始：GFS客戶端以chunk偏移量製做目錄索引而且發送請求——GFS Master收到請求經過chunk映射表映射反饋客戶端——客戶端有了chunk handle和chunk 位置，並將文件名和chunk的目錄索引緩存，向chunk服務器發送請求——chunk服務器回覆請求傳輸chunk數據。服務器
若是讀者您讀着有點迷糊，這很正常，由於只有少數搜索引擎企業才採用這樣的技術。簡單來講是這樣：Google運用GFS大大簡化了檢索的難度。網絡
除了GFS，MapReduce對Google也是功不可沒。Google擁有很多於100萬臺服務器，看起來每臺服務器的職能都很是明確，可是其中卻有重要的協同問題有待解決：如何併發計算，如何分佈數據，如何處理失敗，如何負載均衡？咱們能夠預見，無數的代碼將被用在協同問題上，並且極可能效率低下。這時候，MapReduce就派上用場了。MapReduce是Google開發的C++編程工具，用於大規模數據集的並行運算。MapReduce主要功能是提供了一個簡單強大的接口，能夠將計算自動的併發和分佈執行。這樣一來，就能夠經過普通PC的集羣，實現高性能。MapReduce主要從兩方面提高了系統：首先是失效的計算機問題。若是某一臺計算機失效了，或者是I/O出現了問題——這在Google以廉價服務器組建的集羣中極爲常見，MapReduce的解決方法是用多個計算機同時計算一個任務，一旦一臺計算機有告終果，其它計算機就中止該任務，而進入下一任務。另外，在MapReduce之間傳輸的數據都是通過壓縮的，節省了不少帶寬資源。至於BigTable，這是一個用來處理大數據量的系統，適合處理半結構化的數據。架構
Google心經：
Google老是嘗試用最少的錢，作最多的事情。不要小看那些便宜、不牢靠的PC級服務器，一臺服務器也許確實不牢靠，可是100萬臺的服務器集成卻成爲了全球最完善、最穩定的系統之一。在採購服務器方面，Google也從未一次性大量購買，都是有了需求再選購。另外一個可以體現Google精打細算的方面是Google儘可能壓縮全部可以壓縮的文件。
包括軟件和硬件，Google的設計構想都很前衛，Google嘗試過許多還在實驗室裏的萌芽技術，如上文所說，不少都取得了巨大成功。Google早先的目標是0.5秒鐘作出搜索結果，但實際上目前的平均時間已經縮減到了0.25秒。並且，Google歷來沒有中止研究的腳步，如今還在測試OpenSoalris，觀察OpenSoalris是否可以替代Linux。
Google的行爲很是踏實。不參加Top500評選，文獻裏也鮮有相關資料。可見Google不吹噓、也沒有過分宣傳，只是勤勤懇懇的更新程序、優化集羣。今天，Google收錄了絕大多數人類語言的網頁，而且在多數國家都創建了Google分站，收錄的網頁也是與日俱增，全球影響力更是不言而喻。
向Google的架構學習，向Google的成就致敬。
Google是伸縮性的王者。Google一直的目標就是構建高性能高伸縮性的基礎架構來支撐它們的產品。
平臺
Linux
大量語言：Python，Java，C++
狀態
在2006年大約有450,000臺廉價服務器，這個數量到2010年增長到了1,000,000臺。
在2005年Google索引了80億Web頁面，如今沒有人知道具體數目，近千億並不斷增加中。
目前在Google有超過500個GFS集羣。一個集羣能夠有1000或者甚至5000臺機器。成千上萬的機器從運行着100PB以上字節存儲的GFS集羣獲取數據，集羣總的讀寫吞吐量能夠達到每秒40萬億字節
目前在Google有6000個MapReduce程序，並且每月都寫成百個新程序
BigTable伸縮存儲幾十億的URL，幾百千千兆的衛星圖片和幾億用戶的參數選擇
堆棧
Google形象化它們的基礎組織爲三層架構：
1，產品：搜索，廣告，email，地圖，視頻，聊天，博客
2，分佈式系統基礎組織：GFS，MapReduce和BigTable
3，計算平臺：一羣不一樣的數據中內心的機器
4，確保公司裏的人們部署起來開銷很小
5，花費更多的錢在避免丟失日誌數據的硬件上，其餘類型的數據則花費較少
可信賴的存儲機制GFS(Google File System)
1，可信賴的伸縮性存儲是任何程序的核心需求。GFS就是Google的核心存儲平臺
2，Google File System – 大型分佈式結構化日誌文件系統，Google在裏面扔了大量的數據
3，爲何構建GFS而不是利用已有的東西？由於能夠本身控制一切而且這個平臺與別的不同，Google須要：
-跨數據中心的高可靠性
-成千上萬的網絡節點的伸縮性
-大讀寫帶寬的需求
-支持大塊的數據，可能爲上千兆字節
-高效的跨節點操做分發來減小瓶頸
4，系統有Master和Chunk服務器
-Master服務器在不一樣的數據文件裏保持元數據。數據以64MB爲單位存儲在文件系統中。客戶端與Master服務器交流來在文件上作元數據操做而且找到包含用戶須要數據的那些Chunk服務器
-Chunk服務器在硬盤上存儲實際數據。每一個Chunk服務器跨越3個不一樣的Chunk服務器備份以建立冗餘來避免服務器崩潰。一旦被Master服務器指明，客戶端程序就會直接從Chunk服務器讀取文件
6，一個上線的新程序能夠使用已有的GFS集羣或者能夠製做本身的GFS集羣
7，關鍵點在於有足夠的基礎組織來讓人們對本身的程序有所選擇，GFS能夠調整來適應個別程序的需求
使用MapReduce來處理數據
1，如今你已經有了一個很好的存儲系統，你該怎樣處理如此多的數據呢？好比你有許多TB的數據存儲在1000臺機器上。數據庫不能伸縮或者伸縮到這種級別花費極大，這就是MapReduce出現的緣由
2，MapReduce是一個處理和生成大量數據集的編程模型和相關實現。用戶指定一個map方法來處理一個鍵/值對來生成一箇中間的鍵/值對，還有一個reduce方法來合併全部關聯到一樣的中間鍵的中間值。許多真實世界的任務均可以使用這種模型來表現。以這種風格來寫的程序會自動並行的在一個大量機器的集羣裏運行。運行時系統照顧輸入數據劃分、程序在機器集之間執行的調度、機器失敗處理和必需的內部機器交流等細節。這容許程序員沒有多少並行和分佈式系統的經驗就能夠很容易使用一個大型分佈式系統資源
3，爲何使用MapReduce？
-跨越大量機器分割任務的好方式
-處理機器失敗
-能夠與不一樣類型的程序工做，例如搜索和廣告。幾乎任何程序都有map和reduce類型的操做。你能夠預先計算有用的數據、查詢字數統計、對TB的數據排序等等
4，MapReduce系統有三種不一樣類型的服務器
-Master服務器分配用戶任務到Map和Reduce服務器。它也跟蹤任務的狀態
-Map服務器接收用戶輸入並在其基礎上處理map操做。結果寫入中間文件
-Reduce服務器接收Map服務器產生的中間文件並在其基礎上處理reduce操做
5，例如，你想在全部Web頁面裏的字數。你將存儲在GFS裏的全部頁面拋入MapReduce。這將在成千上萬臺機器上同時進行而且全部的調整、工做調度、失敗處理和數據傳輸將自動完成
-步驟相似於：GFS -> Map -> Shuffle -> Reduction -> Store Results back into GFS
-在MapReduce裏一個map操做將一些數據映射到另外一箇中，產生一個鍵值對，在咱們的例子裏就是字和字數
-Shuffling操做彙集鍵類型
-Reduction操做計算全部鍵值對的綜合併產生最終的結果
6，Google索引操做管道有大約20個不一樣的map和reduction。
7，程序能夠很是小，如20到50行代碼
8，一個問題是掉隊者。掉隊者是一個比其餘程序慢的計算，它阻塞了其餘程序。掉隊者可能由於緩慢的IO或者臨時的CPU不能使用而發生。解決方案是運行多個一樣的計算而且當一個完成後殺死全部其餘的
9，數據在Map和Reduce服務器之間傳輸時被壓縮了。這能夠節省帶寬和I/O。
在BigTable裏存儲結構化數據
1，BigTable是一個大伸縮性、錯誤容忍、自管理的系統，它包含千千兆的內存和1000000000000000的存儲。它能夠每秒鐘處理百萬的讀寫
2，BigTable是一個構建於GFS之上的分佈式哈希機制。它不是關係型數據庫。它不支持join或者SQL類型查詢
3，它提供查詢機制來經過鍵訪問結構化數據。GFS存儲存儲不透明的數據而許多程序需求有結構化數據
4，商業數據庫不能達到這種級別的伸縮性而且不能在成千上萬臺機器上工做
5，經過控制它們本身的低級存儲系統Google獲得更多的控制權來改進它們的系統。例如，若是它們想讓跨數據中心的操做更簡單這個特性，它們能夠內建它
6，系統運行時機器能夠自由的增刪而整個系統保持工做
7，每一個數據條目存儲在一個格子裏，它能夠經過一個行key和列key或者時間戳來訪問
8，每一行存儲在一個或多個tablet中。一個tablet是一個64KB塊的數據序列而且格式爲SSTable
9，BigTable有三種類型的服務器：
-Master服務器分配tablet服務器，它跟蹤tablet在哪裏而且若是須要則從新分配任務
-Tablet服務器爲tablet處理讀寫請求。當tablet超過大小限制(一般是100MB-200MB)時它們拆開tablet。當一個Tablet服務器失敗時，則100個Tablet服務器各自挑選一個新的tablet而後系統恢復。
-Lock服務器造成一個分佈式鎖服務。像打開一個tablet來寫、Master調整和訪問控制檢查等都須要互斥
10，一個locality組能夠用來在物理上將相關的數據存儲在一塊兒來獲得更好的locality選擇
11，tablet儘量的緩存在RAM裏
硬件
1，當你有不少機器時你怎樣組織它們來使得使用和花費有效？
2，使用很是廉價的硬件
3，A 1,000-fold computer power increase can be had for a 33 times lower cost if you you use a failure-prone infrastructure rather than an infrastructure built on highly reliable components. You must build reliability on top of unreliability for this strategy to work.
4，Linux，in-house rack design，PC主板，低端存儲
5，Price per wattage on performance basis isn’t getting better. Have huge power and cooling issues
6，使用一些collocation和Google本身的數據中心
其餘
1，迅速更改而不是等待QA
2，庫是構建程序的卓越方式
3，一些程序做爲服務提供
4，一個基礎組織處理程序的版本，這樣它們能夠發佈而不用懼怕會破壞什麼東西
Google未來的方向
1，支持地理位置分佈的集羣
2，爲全部數據建立一個單獨的全局名字空間。當前的數據由集羣分離
3，更多和更好的自動化數據遷移和計算
4，解決當使用網絡劃分來作廣闊區域的備份時的一致性問題(例如保持服務即便一個集羣離線維護或因爲一些損耗問題)
學到的東西
1，基礎組織是有競爭性的優點。特別是對Google而言。Google能夠很快很廉價的推出新服務，而且伸縮性其餘人很難達到。許多公司採起徹底不一樣的方式。許多公司認爲基礎組織開銷太大。Google認爲本身是一個系統工程公司，這是一個新的看待軟件構建的方式
2，跨越多個數據中心仍然是一個未解決的問題。大部分網站都是一個或者最多兩個數據中心。咱們不得不認可怎樣在一些數據中心之間完整的分佈網站是很須要技巧的
3，若是你本身沒有時間從零開始從新構建全部這些基礎組織你能夠看看Hadoop。Hadoop是這裏不少一樣的主意的一個開源實現
4，平臺的一個優勢是初級開發人員能夠在平臺的基礎上快速而且放心的建立健全的程序。若是每一個項目都須要發明一樣的分佈式基礎組織的輪子，那麼你將陷入困境由於知道怎樣完成這項工做的人相對較少
5，協同工做不一直是擲骰子。經過讓系統中的全部部分一塊兒工做則一個部分的改進將幫助全部的部分。改進文件系統則每一個人從中受益並且是透明的。若是每一個項目使用不一樣的文件系統則在整個堆棧中享受不到持續增長的改進
6，構建自管理系統讓你不必讓系統關機。這容許你更容易在服務器之間平衡資源、動態添加更大的容量、讓機器離線和優雅的處理升級
7，建立可進化的基礎組織，並行的執行消耗時間的操做並採起較好的方案
8，不要忽略學院。學院有許多沒有轉變爲產品的好主意。Most of what Google has done has prior art, just not prior large scale deployment.
9，考慮壓縮。當你有許多CPU而IO有限時壓縮是一個好的選擇。
Google主要以GFS、MapReduce、BigTable這三大平臺來支撐其龐大的業務系統，我稱他們爲Google三劍客，網上也有說是Google的三架馬車。
1、GFS（Google File System）
這是Google獨特的一個面向大規模數據密集型應用的、可伸縮的分佈式文件系統，因爲這個文件系統是經過軟件調度來實現的，因此Google能夠把GFS部署在不少廉價的PC機上，來達到用昂貴服務器同樣的效果。
下面是一張Google GFS的架構圖：
從上圖咱們可看到Google的GFS主要由一個master和不少chunkserver組成，master主要是負責維護系統中的名字空間、訪問控制信息、從文件到塊的映射以及塊的當前位置等元素據，並經過心跳信號與chunkserver通訊，蒐集並保存chunkserver的狀態信息。chunkserver主要是用來存儲數據塊，google把每一個數據塊的大小設計成64M，至於爲何這麼大後面會提到，每一個chunk是由master分配的chunk-handle來標識的，爲了提升系統的可靠性，每一個chunk會被複制3個副本放到不一樣的chunkserver中。
固然這樣的單master設計也會帶來單點故障問題和性能瓶頸問題，Google是經過減小client與master的交互來解決的，client均是直接與chunkserver通訊，master僅僅提供查詢數據塊所在的chunkserver以及詳細位置。下面是在GFS上查詢的通常流程：
一、client使用固定的塊大小將應用程序指定的文件名和字節偏移轉換成文件的一個塊索引（chunk index）。
二、給master發送一個包含文件名和塊索引的請求。
三、master迴應對應的chunk handle和副本的位置（多個副本）。
四、client以文件名和塊索引爲鍵緩存這些信息。（handle和副本的位置）。
五、Client 向其中一個副本發送一個請求，極可能是最近的一個副本。請求指定了chunk handle（chunkserver以chunk handle標識chunk）和塊內的一個字節區間。
六、除非緩存的信息再也不有效（cache for a limited time）或文件被從新打開，不然之後對同一個塊的讀操做再也不須要client和master間的交互。
不過我仍是有疑問，google能夠經過減小client與master通訊來解決性能瓶頸問題，但單點問題呢，一臺master掛掉豈不是完蛋了，總感受不太放心，多是我瞭解不夠透徹，不知道哪位朋友能解釋一下，謝謝：）
2、MapReduce，Google的分佈式並行計算系統
若是上面的GFS解決了Google的海量數據的存儲，那這個MapReduce則是解決了如何從這些海量數據中快速計算並獲取指定數據的問題。咱們知道，Google的每一次搜索都在零點零幾秒，能在這麼短期裏環遊世界一週，這裏MapReduce有很大的功勞。
Map即映射，Reduce即規約，由master服務器把map和reduce任務分發到各自worker服務器中運行計算，最後把結果規約合併後返回給用戶。這個過程能夠由下圖來講明。
按照本身的理解，簡單對上圖加點說明：
一、首先把用戶請求的數據文件切割成多份，每一份（即每個split）被拷貝在集羣中不一樣機器上，而後由集羣啓動程序中的多份拷貝。
二、master把map和reduce任務交給相對空閒的worker處理，並阻塞等待處理結果。
三、處理map任務的worker接到任務後，把以key/value形式的輸入數據傳遞給map函數進行處理，並將處理結果也以key/value的形式輸出，並保存在內存中。
四、上一步內存中的結果是要進行reduce的，因而這些map worker就把這些數據的位置返回給master，這樣master知道數據位置就能夠繼續分配reduce任務，起到了鏈接map和reduce函數的做用。
五、reduce worker知道這些數據的位置後就去相應位置讀取這些數據，並對這些數據按key進行排序。將排序後的數據序列放入reduce函數中進行合併和規約，最後每一個reduce任務輸出一個結果文件。
六、任務結束，master解除阻塞，喚醒用戶。
以上是我的的一些理解，有不對的地方請指出。
3、BigTable，分佈式的結構化數據存儲系統？
BigTable是基於GFS和MapReduce之上的，那麼google既然已經有了GFS，爲什麼還要有BigTable呢（也是我原先的一個疑問）？後來想一想這和已經有操做系統文件系統爲什麼還要有SQL SERVER數據庫同樣的道理，GFS是更底層的文件系統，而BigTable創建在其上面，不只能夠存儲結構化的數據，並且能夠更好的管理和作出負載均衡決策。
如下是BigTable的架構圖：
它徹底是一個基於key/value的數據庫，和通常的關係型數據庫不一樣，google之因此採用BigTable，由於它在知足需求的同時簡化了系統，好比去掉了事務、死鎖檢測等模塊，讓系統更高效。更重要的一點是在BigTable中數據是沒有格式的，它僅僅是一個個key/value的pairs，用戶能夠本身去定義數據的格式，這也大大提升了BigTable的靈活性和擴展性。
4、總結
這篇隨筆主要是一些總結性的內容，Google架構遠遠不止這些。
原文：Google Architecture
附：Google背後的IT架構策略揭祕
Google是不同凡響的。它的獨特不只僅表現於革新的思惟和充滿創意的應用 (好比那個大堂裏的地球模型)，更在於其有別常規的IT策略……
加利福尼亞州山景城(Mountain View)Google公司(Google，下稱Google)總部有一個43號大樓，該建築的中央大屏幕上顯示着一個與Google地球(Google Earth)相仿的世界地圖，一個轉動的地球上不停地閃動着五光十色的光點，恍如羅馬宮廷的千萬燭燈，每一次閃動標誌着地球的這個角落一名Google用戶發起了一次新的搜索。
這同時意味着Google又一次知足了人們對未知信息的好奇與渴望。
Google是不同凡響的。它的獨特不只僅表現於革新的思惟和充滿創意的應用 (好比那個大堂裏的地球模型)，更在於其有別常規的IT策略。從人們的常理來看，簡單的硬件商品和免費軟件是沒法構建出一個帝國的，可是Google作到了。在性能調整後，Google把它們變成一個無可比擬的分佈式計算平臺，該平臺可以支持大規模的搜索和不斷涌現的新興應用。咱們本來認爲這些應用都是我的消費級別的，可是Google改變了這一切。如今商業世界也在使用它們，這就令這家搜索公司顯得那麼不同凡響。
GoogleWeb 服務背後的IT架構對無數使用搜索引擎的用戶來講也許並非很是重要，但它是Google幾百位致力於把全球信息組織起來，實現「隨處可達，隨時可用」目標的工程師們的最核心工做。這就須要一個在覆蓋範圍和野心上都與Google的商業願景徹底相符的IT藍圖做爲支撐。
Google 的經理們一直對公司的IT策略話題保持沉默，他們厭惡談及特定的廠商或者產品，當被問到他們的服務器和數據中心時，他們老是閉口不談。但與幾位 Google的IT領導一塊兒呆了一天後，咱們最終得以揭示該公司的IT是如何運做的，那可不只僅是一個運行在無數服務器集羣上的、表面看來很是簡單的搜索引擎。在其簡單的外表下，蘊涵着許多內部研發軟件、定製硬件、人工智能，以及對性能的執着追求和打破常規的人力管理模式。
IT理念方面，Google對同行有一條建議：儘可能避免那些人人都在使用的系統和軟件，以本身的方式作事會更有獨特的競爭優點。
「企業文化決定了你的作事方式。」道格拉斯」美林(Douglas Merrill)，這位Google工程副總裁和事實上的首席信息官(CIO) 指出，「到了咱們這樣的發展階段，企業觀念和文化很是不同凡響，這也反過來鞭策咱們必需要採用不同凡響的方式來運行那些他人看來很常規的系統。」
Google 最大的IT優點在於它能建造出既富於性價比(並不是廉價)又能承受極高負載的高性能系統。所以IT顧問史蒂芬」阿諾德(Stephen Arnold)指出，Google與競爭對手，如亞馬遜網站(Amazon)、電子港灣公司(eBay)、微軟公司(Microsoft，下稱微軟)和雅虎公司 (Yahoo，下稱雅虎)等公司相比，具備更大的成本優點。Google程序員的效率比其餘Web公司同行們高出50%～100%，緣由是Google已經開發出了一整套專用於支持大規模並行系統編程的定製軟件庫。據他估算，其餘競爭公司可能要花上四倍的時間才能得到同等的效果。
打造服務器
Google 到底是怎樣作到這點的呢?其中一個手段，美林認爲，「是由於咱們本身動手打造硬件。」Google並不製造計算機系統，但它根據本身的參數定製硬件，而後像MTV的節目「靚車打造」(Pimp My Ride)那樣本身安裝和調整硬件系統。開源程序經理克里斯」迪博納(Chris DiBona)評論道：「咱們很善於購買商業服務器，而且改造他們爲咱們所用，最後把性能壓榨和發揮到極致，以至有時候他們熱得像要融化了似的。」
這種親手打造的方式，來源於Google從車庫誕生時與生俱來的節儉風格，更與Google那超大型的系統規模息息相關，良好的習慣一直延續至今。聽說 Google在65個數據中心擁有20萬～45萬臺服務器—這個數目會有誤差(取決於你如何定義服務器和由誰來作這項統計)。可是，不變的是持續上升的趨勢。
Google不會去討論這些資產，由於它認爲保密也是一種競爭優點。事實上，Google之因此喜歡開源軟件也是由於它的私密性。「若是咱們購買了軟件許可或代碼許可，人們只要對號入座，就能夠猜出Google的IT基礎架構。」迪博納分析說， 「使用開源軟件，就使咱們多了一條把握本身命運的途徑。」
Google喜歡規模化的服務器運行方式。當有成百上千臺機器時，定製服務器的優點也會成倍增長，效果也會更趨明顯。Google正在俄勒岡州哥倫比亞河邊的達勒斯市建造一個佔地30畝的數據中心，在那兒它能夠得到運算和降溫須要的低價水力電力能源(參見邊欄《Google數據中心自有一套》)。
Google以「單元」(Cell)的形式組織這些運行 Linux操做系統的服務器，迪博納把這種形式比喻成互聯網服務的「磁盤驅動器」(但別和一直謠傳的Google存儲服務Gdrive混淆了，「並無 Gdrive這回事。」一位Google女發言人明確表示。)，公司的軟件程序都駐紮在這些並不昂貴的電腦機箱裏，由程序員決定它們的冗餘工做量。這種由不少單元組成的文件系統代替了商業存儲設備;迪博納表示Google這些單元設備更易於建造和維護，他還暗示他們能處理更大規模的數據。
Google 不會漏過對任何技術細節的關注。多年來，公司的工程師就在研究微處理器的內部工做機制，隨着Google規模的持續壯大，必然會用到特別定製和調節過的芯片。知名工程師路易斯」巴羅索(Luiz Barroso)去年在一篇發表在工業雜誌上的論文中證明，近年來Google的主要負荷都由單核設計的系統承擔着。但許多服務器端的應用，如 Google搜索索引服務，所需的並行計算在單核芯片的指令級別上執行得並很差。
曾在數據設備公司(Digital Equipment)和康柏公司(Compaq)當過芯片設計師的巴羅索認爲，隨着AMD公司、英特爾公司(Intel)、太陽計算機系統公司(Sun)開始製造多核芯片，必將會出現愈來愈多芯片級別的並行計算。
Google 也曾考慮過本身製造計算機芯片，但從業界潮流來看，這個冒險的舉動彷佛不是很必要。「微處理器的設計很是複雜並且成本昂貴，」運營高級副總裁烏爾斯」霍爾茨勒(Urs Holzle)表示。Google寧願與芯片製造商合做，讓他們去理解本身的應用並設計適合的芯片。這是一種客戶建議式的設計，其關注點在於整體吞吐量、效能，以及耗電比，而不是看單線程的峯值性能。霍爾茨勒表示，「這也是最近多核CPU的設計潮流與將來方向。」
裁縫般地定製軟件
爲了能儘可能壓榨硬件性能，Google開發了至關數量的定製軟件。創新產品主要包括用於簡化處理和建立大規模數據集的編程模型MapReduce;用於存儲和管理大規模數據的系統BigTable;分析分佈式運算環境中大規模數據集的解釋編程語言Sawzall;用於數據密集型應用的分佈式文件系統的 「Google文件系統」(Google File System);還有爲處理分佈式系統隊列分組和任務調度的「Google工做隊列」(Google Workqueue)。
正是從Sawzall這些工具裏體現出Google對計算效率的執著關注。並非每家公司都能從底層去解決效率問題，可是對Google來講，爲常規關係型數據庫沒法容納的大規模數據集專門設計一種編程語言是徹底合理的。即便其餘編程工具能夠解決問題，Google的工程師們仍然會爲了追求效率而另外開發一套定製方案。Google工程師認爲，Sawzall能與C++中的MapReduce相媲美，並且它更容易編寫一些。
Google 對效率的關注使它不可能對標準Linux內核感到滿意;Google會根據本身的須要運行修改過的內核版本。經過調整Linux的底層性能，Google 工程師們在提升了總體系統可靠性的基礎上，還一併解決了數據損壞和數據瓶頸等一系列棘手問題。對內核的修改也使Google的計算機集羣系統由於通訊效率的提升而運行得更快。
固然，Google偶爾也會出現系統故障，狀況一旦發生，無數的用戶就會受到影響了。三年前一次持續30分鐘的系統故障使20%的搜索流量受到影響。
Google 開發了本身的網站服務器卻沒有使用開源的Apache服務器，儘管它在網站服務器的市場佔有率超過60%。迪博納認爲，Google的網站服務器能夠運行在更多數量的主機上，對Google站點上內容龐大又彼此互相依賴的應用程序來講，這種服務器的負載均衡能力遠比Apache的能力更高。同時，在用標準公共網關接口(CGI)訪問數據庫動態網頁方面，Google服務器的編程難度要比 Apache更高，可是最終運行速度卻更快。「若是咱們可以壓榨出10%～20%的性能，咱們就能夠節省出更多系統資源、電量和人力了。」迪博納在總結中指出。
Google還設計了本身的客戶關係管理(CRM)系統用於支持本身基於競價和點擊的互聯網廣告收費業務。但對是否須要設計本身的工具，Google的態度也不是一成不變的。好比在財會軟件上，它就使用了甲骨文公司(Oracle)的Financials軟件。
美林拿着一隻叉子舉例說明現成的產品也能夠帶來價值。但在有些場合現成的軟件產品就不必定適用了。「咱們的文化在各個層面對咱們的運做都有深遠影響，」他表示，「因此咱們不想讓購買所得的工具改變咱們的工做方式和文化層面。」
參考：http://highscalability.com/google-architecture
