Google架構(gòu)

文/Todd Hoff 譯/黃翀

Google是可伸縮性控制方面的王者。Google一直的目標(biāo)就是構(gòu)建高性能高伸縮性的基礎(chǔ)組織來支持它們的產(chǎn)品。

平臺

l  Linux

l  開發(fā)語言：Python，Java，C++

狀態(tài)

l  在2006年大約有450,000臺廉價服務(wù)器

l  在2005年Google索引了80億Web頁面，現(xiàn)在沒有人知道數(shù)目

l  目前在Google有超過200個GFS集群。一個集群可以有1000或者甚至5000臺機(jī)器。成千上萬的機(jī)器從運(yùn)行著5000000000000000字節(jié)存儲的GFS集群獲取數(shù)據(jù)，集群總的讀寫吞吐量可以達(dá)到每秒40兆字節(jié)

l  目前在Google有6000個MapReduce程序，而且每個月都寫成百個新程序

l  BigTable伸縮存儲幾十億的URL，幾百千千兆的衛(wèi)星圖片和幾億用戶的參數(shù)選擇

架構(gòu)

Google將它們的基礎(chǔ)架構(gòu)形象化為三層架構(gòu)：

l  產(chǎn)品：搜索，廣告，email，地圖，視頻，聊天，博客

l  分布式系統(tǒng)基礎(chǔ)組織：GFS，MapReduce和BigTable

l  計算平臺：一群不同的數(shù)據(jù)中心里的機(jī)器

l  確保公司里的人們的部署開銷很小

l  在避免丟失日志數(shù)據(jù)的硬件上花費(fèi)較多的錢，其他類型的數(shù)據(jù)則花費(fèi)較少

可信賴的存儲機(jī)制GFS(Google File System)

l  可信賴的伸縮性存儲是任何程序的核心需求。GFS就是Google的核心存儲平臺。

l  Google File System ——大型分布式結(jié)構(gòu)化日志文件系統(tǒng)，Google在里面存儲了大量的數(shù)據(jù)。

l  為什么構(gòu)建GFS而不是利用已有的東西？因為可以自己控制一切，況且這個平臺與別的不一樣，Google需要：

n  跨數(shù)據(jù)中心的高可靠性

n  成千上萬的網(wǎng)絡(luò)節(jié)點的伸縮性

n  大讀寫帶寬的需求

n  支持大塊的數(shù)據(jù)，可能為上千兆字節(jié)

n  高效的跨節(jié)點操作分發(fā)以減少瓶頸

l  Master和Chunk服務(wù)器：

-      Master服務(wù)器在不同的數(shù)據(jù)文件里保持元數(shù)據(jù)。數(shù)據(jù)以64MB為單位存儲在文件系統(tǒng)中。客戶端與Master服務(wù)器的交流則可以在文件上進(jìn)行元數(shù)據(jù)操作并找到包含用戶需要數(shù)據(jù)的那些Chunk服務(wù)器。

-      Chunk服務(wù)器在硬盤上存儲實際數(shù)據(jù)。每個Chunk服務(wù)器跨越3個不同的Chunk服務(wù)器備份以創(chuàng)建冗余來避免服務(wù)器崩潰。一旦經(jīng)Master服務(wù)器指明，客戶端程序就會直接從Chunk服務(wù)器讀取文件。

l  一個上線的新程序可以使用已有的GFS集群或者可以制作自己的GFS集群。

l  關(guān)鍵點在于有足夠的基礎(chǔ)組織可以讓人們對自己的程序有所選擇，GFS可以調(diào)整來適應(yīng)個別程序的需求。

使用MapReduce來處理數(shù)據(jù)

l  你現(xiàn)在已經(jīng)有了一個很好的存儲系統(tǒng)，那么該怎樣處理如此多的數(shù)據(jù)呢？比如大量TB級的數(shù)據(jù)存儲在1000臺機(jī)器上。數(shù)據(jù)庫不能伸縮或者伸縮到這種級別花費(fèi)極大，這就是MapReduce出現(xiàn)的原因。

l  MapReduce是一個處理和生成大量數(shù)據(jù)集的編程模型和相關(guān)實現(xiàn)。用戶指定一個map方法來處理一個鍵/值來生成一個中間的鍵/值，還有一個reduce方法以合并所有關(guān)聯(lián)到同樣的中間鍵的中間值。許多真實世界的任務(wù)都可以使用這種模型來表現(xiàn)。以這種風(fēng)格來寫的程序會自動的在一個擁有大量機(jī)器的集群里并行運(yùn)行。運(yùn)行時系統(tǒng)處理輸入數(shù)據(jù)的劃分、程序在機(jī)器集之間執(zhí)行的調(diào)度、機(jī)器失敗處理和必需的內(nèi)部機(jī)器交流等細(xì)節(jié)。這就允許程序員沒有多少并行和分布式系統(tǒng)的經(jīng)驗就可以很容易使用一個大型分布式系統(tǒng)資源。

l  為什么使用MapReduce？

n  跨越大量機(jī)器分割任務(wù)的好方式。

n  處理機(jī)器失敗。

n  可以與不同類型的程序工作，例如搜索和廣告。幾乎任何程序都有map和reduce類型的操作?？梢灶A(yù)先計算有用的數(shù)據(jù)、查詢字?jǐn)?shù)統(tǒng)計、對TB的數(shù)據(jù)排序等等。

l  MapReduce系統(tǒng)有三種不同類型的服務(wù)器：

n  Master服務(wù)器分配用戶任務(wù)到Map和Reduce服務(wù)器。它也跟蹤任務(wù)的狀態(tài)。

n  Map服務(wù)器接收用戶輸入并在其基礎(chǔ)上處理map操作。結(jié)果寫入中間文件。

n  Reduce服務(wù)器接收Map服務(wù)器產(chǎn)生的中間文件并在其基礎(chǔ)上處理reduce操作。

l  例如，你想統(tǒng)計在所有Web頁面里的字?jǐn)?shù)。你應(yīng)該將存儲在GFS里的所有頁面拋入MapReduce。所有的調(diào)整、工作調(diào)度、失敗處理和數(shù)據(jù)傳輸將在成千上萬臺機(jī)器上同時進(jìn)行并且自動完成。

n  步驟類似于：GFS -> Map -> Shuffle -> Reduction -> Store Results back into GFS。

n  在MapReduce里一個map操作將一些數(shù)據(jù)映射到另一個中，產(chǎn)生一個鍵值對，在我們的例子里就是字和字?jǐn)?shù)。

n  Shuffling操作聚集鍵類型。

n  Reduction操作計算所有鍵值對的綜合并產(chǎn)生最終的結(jié)果。

l  Google索引操作管道有大約20個不同的map和reduction。

l  程序可以非常小，如20到50行代碼。

l  一個問題可能是掉隊者，就是是一個比其他程序慢的計算，阻塞了其他程序。掉隊者可能因為緩慢的IO或者臨時的CPU不能使用而發(fā)生。解決方案是運(yùn)行多個同樣的計算并且當(dāng)一個完成后殺死所有其他的。

l  數(shù)據(jù)在Map和Reduce服務(wù)器之間傳輸時被壓縮了。這可以節(jié)省帶寬和I/O。

在BigTable里存儲結(jié)構(gòu)化數(shù)據(jù)

l  BigTable是一個大伸縮性、容錯的、自管理系統(tǒng)，包含千千兆的內(nèi)存和1000000000000000的存儲。它可以每秒鐘處理百萬數(shù)量級的讀寫操作。

l  BigTable是一個構(gòu)建于GFS之上的分布式Hash機(jī)制，但不是關(guān)系型數(shù)據(jù)庫，不支持join或者SQL類型查詢。

l  提供查詢機(jī)制通過鍵訪問結(jié)構(gòu)化數(shù)據(jù)。GFS存儲存儲不透明的數(shù)據(jù)，而許多程序需求有結(jié)構(gòu)化數(shù)據(jù)。

l  商業(yè)數(shù)據(jù)庫不能達(dá)到這種級別的伸縮性，并且不能在成千上萬臺機(jī)器上工作。

l  通過控制自己的低級存儲系統(tǒng)，Google得到更多的控制權(quán)來改進(jìn)它們的系統(tǒng)。例如，如果想讓跨數(shù)據(jù)中心的操作更簡單這個特性，就可以內(nèi)建它。

l  可以自由的增刪系統(tǒng)運(yùn)行時機(jī)器，而整個系統(tǒng)可以保持正常工作。

l  每個數(shù)據(jù)條目存儲在一個格子里，可以通過一個行key和列key或者時間戳來訪問。

l  每一行存儲在一個或多個tablet中。一個tablet是一個64KB塊的數(shù)據(jù)序列并且格式為SSTable。

l  BigTable有三種類型的服務(wù)器：

n  Master服務(wù)器分配tablet服務(wù)器，它跟蹤tablet在哪里并且如果需要則重新分配任務(wù)

n  Tablet服務(wù)器為tablet處理讀寫請求。當(dāng)tablet超過大小限制(通常是100MB-200MB)時它們拆開tablet。當(dāng)一個Tablet服務(wù)器失敗時，則100個Tablet服務(wù)器各自挑選一個新的tablet然后系統(tǒng)恢復(fù)。

n  Lock服務(wù)器形成一個分布式鎖服務(wù)。像打開一個tablet來寫、Master調(diào)整和訪問控制檢查等都需要互斥。

l  一個locality組可以將物理上將相關(guān)的數(shù)據(jù)存儲在一起以便得到更好的locality選擇。

l  tablet盡可能的緩存在RAM里。

硬件

l  當(dāng)你有很多機(jī)器時，你怎樣組織它們來達(dá)到成本的有效利用，并發(fā)揮最大效力？

l  使用非常廉價的硬件。

l  使用不可靠的（failure-prone）架構(gòu)方式，而不是在高度可靠的組件上搭建基礎(chǔ)架構(gòu)，你可以獲得1000倍計算能力的提升，而成本卻降低了33倍。你必須在不可靠性之上來構(gòu)建可靠性，以使得這個策略可以起作用。

l  Linux系統(tǒng)，采取內(nèi)部機(jī)架放置的設(shè)計方式，使用PC主板，低端存儲。

l  基于性能來評估能源消耗不是好的方式，會遇到嚴(yán)重的電力和制冷方面的問題。

l  混合使用服務(wù)器，并使用他們自己的數(shù)據(jù)中心。

其他

l  迅速更改而不是等待QA。

l  庫是構(gòu)建程序的卓越方式。

l  一些程序作為服務(wù)提供。

l  通過一個基礎(chǔ)組織處理程序的版本，這樣可以自由發(fā)布而不用害怕會破壞什么東西。

Google將來的方向

l  支持地理位置分布的集群。

l  為所有數(shù)據(jù)創(chuàng)建一個單獨(dú)的全局名字空間，將當(dāng)前的數(shù)據(jù)從集群分離。

l  更多和更好的自動化數(shù)據(jù)遷移和計算。

l  解決使用網(wǎng)絡(luò)劃分做廣闊區(qū)域的備份時的一致性問題(例如保持服務(wù)，即使有一個集群離線維護(hù)或存在一些損耗問題)。

經(jīng)驗教訓(xùn)

l  基礎(chǔ)組織具有競爭性的優(yōu)勢，特別是對Google而言。Google可以很快很廉價的推出新服務(wù)，并且具有其他人很難達(dá)到伸縮性。許多公司采取完全不同的方式。他們認(rèn)為基礎(chǔ)組織開銷太大。Google認(rèn)為自己是一個系統(tǒng)工程公司，這是一個新的看待軟件構(gòu)建的方式。

l  跨越多個數(shù)據(jù)中心仍然是一個未解決的問題。大部分網(wǎng)站都是一個或者最多兩個數(shù)據(jù)中心。我們不得不承認(rèn)怎樣在一些數(shù)據(jù)中心之間完整的分布網(wǎng)站是很需要技巧的。

l  如果你自己沒有時間從零開始重新構(gòu)建所有這些基礎(chǔ)組織，你可以看看Hadoop。Hadoop是這里很多主意的一個開源實現(xiàn)。

l  平臺的一個優(yōu)點是初級開發(fā)人員可以在平臺的基礎(chǔ)上快速并且放心的創(chuàng)建健全的程序。如果每個項目都需要發(fā)明同樣的分布式基礎(chǔ)組織的輪子，那么你將陷入困境。因為知道怎樣完成這項工作的人相對較少。

l  協(xié)同工作不一直是擲骰子。通過讓系統(tǒng)中的所有部分一起工作，則一個部分的改進(jìn)將幫助所有的部分。改進(jìn)文件系統(tǒng)，則每個人從中受益并且是透明的。如果每個項目使用不同的文件系統(tǒng)，則在整個堆棧中享受不到持續(xù)增加的改進(jìn)。

l  構(gòu)建自管理系統(tǒng)讓你沒必要讓系統(tǒng)關(guān)機(jī)。這允許你更容易在服務(wù)器之間平衡資源，動態(tài)添加更大的容量，讓機(jī)器離線和優(yōu)雅的處理升級。

l  創(chuàng)建可進(jìn)化的基礎(chǔ)組織，并行的執(zhí)行消耗時間的操作并采取較好的方案。

l  不要忽略大學(xué)等研究教學(xué)機(jī)構(gòu)。那里有許多沒有轉(zhuǎn)變?yōu)楫a(chǎn)品的好主意。絕大部分Google所實現(xiàn)的領(lǐng)先技術(shù)，其實并不是多么宏大且超前的設(shè)計。

l  考慮壓縮——當(dāng)你有許多CPU而IO有限時，壓縮是一個好的選擇。

Amazon的體系結(jié)構(gòu)

Amazon從一個很小的網(wǎng)上書店發(fā)展成為現(xiàn)今世界上最大的網(wǎng)上書店中。他們開辟了讓顧客來評估，審查和推薦商品的新方式。

平臺

l  Linux

l  Oracle

l  C++

l  Perl

l  Mason

l  Java

l  Jboss

l  Servlets

狀態(tài)

l  超過5500萬活動顧客帳號

l  世界范圍內(nèi)超過100萬活動零售合作商

l  構(gòu)建一個頁面所需訪問的服務(wù)介于100至150個之間

體系結(jié)構(gòu)

l  我們說的可伸縮性到底意味著什么？對于一個服務(wù)來說，當(dāng)我們增加為其分配的系統(tǒng)資源之后，它的性能增長能夠與投入的資源按比例提升，我們就說這個服務(wù)具有可伸縮性。通常意義上的性能提升，意味著能夠提供更多的服務(wù)單元，也可以為更大的工作單元提供服務(wù)，比如增長的數(shù)據(jù)集等。

l  Amazon的架構(gòu)經(jīng)歷了巨大的變化，從一開始時的兩層架構(gòu)，轉(zhuǎn)向了分布式的、去中心化的服務(wù)平臺，提供許多種不同的應(yīng)用。

l  最開始只有一個應(yīng)用來和后端交互，是用C++來完成的。

l  架構(gòu)會隨著時間而演進(jìn)。多年來，Amazon將增容的主要精力放在后端的數(shù)據(jù)庫上，試圖讓其容納更多的商品數(shù)據(jù)，更多的客戶數(shù)據(jù)，更多的訂單數(shù)據(jù)，并讓其支持多個國際站點。到2001年，前端應(yīng)用很明顯不能再做任何增容方面的努力了。數(shù)據(jù)庫被分為很多個小部分，圍繞每個部分會創(chuàng)建一個服務(wù)接口，并且該接口是訪問數(shù)據(jù)的唯一途徑。

l  數(shù)據(jù)庫逐漸演變成共享資源，這樣就很難再在全部業(yè)務(wù)的基礎(chǔ)之上進(jìn)行增容操作了。前端與后端處理的演進(jìn)受到很大限制，因為他們被太多不同的團(tuán)隊和流程所共享了。

l  他們的架構(gòu)是松散耦合的的，并且圍繞著服務(wù)進(jìn)行構(gòu)建。面向服務(wù)的架構(gòu)提供給他們的隔離特性，讓他們能夠快速、獨(dú)立地完成許多軟件組件的開發(fā)。

l  逐漸地，Amazon擁有了數(shù)百個服務(wù)，并有若干應(yīng)用服務(wù)器，從服務(wù)中聚合信息。生成Amazon.com站點頁面的應(yīng)用就位于這樣的一臺應(yīng)用服務(wù)器之上。提供web服務(wù)接口、顧客服務(wù)應(yīng)用以及賣家接口的應(yīng)用也都是類似的情況。

l  許多第三方的技術(shù)難以適用Amazon這種網(wǎng)站的規(guī)模，特別是通訊基礎(chǔ)架構(gòu)技術(shù)。它們在一定范圍內(nèi)工作的很好，但是如果范圍再擴(kuò)大的話，它們就不適用了。因此，Amazon只好自己開發(fā)相應(yīng)的基礎(chǔ)技術(shù)。

l  不在一種技術(shù)上"吊死"。Amazon在有的地方使用jboss/java,不過只是使用servlets，并沒有完全使用j2ee中所涉及到的技術(shù)。

l  C++開發(fā)的程序被用來處理請求。Perl/Mason開發(fā)的程序用來生成頁面中的內(nèi)容。

l  Amazon不喜歡采用中間件技術(shù)，因為它看起來更像一種框架而不是一個工具。如果采用了某種中間件，那么就會被那種中間件所采用的軟件模式所困擾。你也就只能選用他們的軟件。如果你想采用不同的軟件幾乎是不可能的。你被困住了！經(jīng)常發(fā)生的情況就是消息中間件，數(shù)據(jù)持久層中間件，Ajax等等。它們都太復(fù)雜了。如果中間件能夠以更小的組件的方式提供，更像一個工具而不是框架，或許對我們的吸引力會更大一些。

l  SOAP 相關(guān)的web解決方案看起來想再次解決所有分布式系統(tǒng)的問題。

l  Amazon提供SOAP和REST這兩種Web 服務(wù)。大概有30%的用戶采用SOAP這種Web Services。他們看起來似乎是Java和.NET的用戶，而且使用WSDL來生成遠(yuǎn)程對象接口。大概有70%的用戶使用REST。他們看起來似乎是PHP和PERL的用戶。

l  無論采用SOAP還是REST，開發(fā)人員都可以得到訪問Amazon的對象接口。開發(fā)人員想要的是把工作完成，而不需要關(guān)心網(wǎng)線上傳輸?shù)氖鞘裁礀|西。

l  Amazon想要圍繞他們的服務(wù)構(gòu)建一個開放的社區(qū)。他們之所以選擇Web Services是因為它的簡單。事實上它是一個面向服務(wù)的體系架構(gòu)。簡單來說，你只有通過接口才能訪問到需要的數(shù)據(jù)，這些接口是用WSDL描述的，不過它們采用自己的封裝和傳輸機(jī)制。

l  架構(gòu)開發(fā)團(tuán)隊都是小規(guī)模團(tuán)隊，而且都是圍繞不同的服務(wù)進(jìn)行組織。

n  在Amazon服務(wù)是獨(dú)立的功能交付單元。這也是Amazon如何組織他的內(nèi)部團(tuán)隊的。

n  如果你有一個新的業(yè)務(wù)建議，或者想解決一個問題，你就可以組織一個團(tuán)隊。由于溝通上的成本，每個團(tuán)隊都限制到8~10個人。他們被稱為two pizza teams。因為用兩個比薩餅，就可以讓團(tuán)隊成員每個人都吃飽了。

n  團(tuán)隊都是小規(guī)模的。他們被授權(quán)可以采取他們所中意的任何方式來解決一個問題或者增強(qiáng)一個服務(wù)。

n  例如，他們創(chuàng)建了這樣一個團(tuán)隊，其功能是在一本書中查找特有的文字和短語。這個團(tuán)隊為那個功能創(chuàng)建了一個獨(dú)立的服務(wù)接口，而且有權(quán)做任何他們認(rèn)為需要做的事情。

l  部署

n  他們創(chuàng)建了一個特殊的基礎(chǔ)設(shè)施，來完成對依賴性的管理和對完成服務(wù)的部署。

n  目標(biāo)是讓所有正確的服務(wù)可以在一個主機(jī)中部署。所有的應(yīng)用代碼、監(jiān)控機(jī)制、許可證機(jī)制等都應(yīng)該在一個“主機(jī)”中。

n  每個人都有一個自己的系統(tǒng)來解決這些問題。

n  部署進(jìn)程的輸出是一個虛擬機(jī)，你可以用EC2來運(yùn)行他們。

l  為了驗證新服務(wù)的效果，從客戶的角度去看待服務(wù)，這樣做是值得的。

n  從客戶的角度去看待服務(wù)，聚焦于你想交付給用戶的價值。

n  強(qiáng)迫開發(fā)人員將關(guān)注點放在交付給客戶的價值上，而不是先考慮如何構(gòu)建技術(shù)再考慮如何使用技術(shù)。

n  從用戶將要看到的簡要特性開始，再從客戶考慮的角度檢查你構(gòu)建的服務(wù)是否有價值。

n  以最小化的設(shè)計來結(jié)束設(shè)計過程。如果想要構(gòu)建一個很大的分布式系統(tǒng)，簡單性是關(guān)鍵。

l  對于大型可伸縮系統(tǒng)來說狀態(tài)管理是核心問題

n  內(nèi)部而言，他們可以提供無限存儲空間。

n  并不是所有的操作是有狀態(tài)的。結(jié)賬的步驟是有狀態(tài)的。

n  通過分析最近點擊過的頁面的SessionID，這種服務(wù)可以為用戶提供推薦商品建議。

n  他們追蹤、保存著所有的數(shù)據(jù)，所以保持狀態(tài)不是一個問題。有一些分離的狀態(tài)需要為一個session來保持。提供的服務(wù)們會一直保留信息，所以你只要使用這些服務(wù)就可以了。

l  Eric Brewers' CAP理論——或稱為系統(tǒng)的三個屬性

n  系統(tǒng)的三個屬性：一致性，可用性，網(wǎng)絡(luò)分區(qū)容忍度。

n  對于任何一個共享數(shù)據(jù)的系統(tǒng)都至少具備這三個屬性中的兩個。

n  網(wǎng)絡(luò)分區(qū)容忍度：把節(jié)點分割成一些小的分組，它們可以看到其他的分組但是無法看到其他全部節(jié)點。

n  一致性：寫入一個值然后再讀出來，你得到的返回值應(yīng)該和寫入的是同一個值。在一個分區(qū)系統(tǒng)中有些情況并非如此。

n  可用性：并非總是可讀或者可寫。系統(tǒng)可能會告訴你無法寫入數(shù)據(jù)因為需要保持?jǐn)?shù)據(jù)的一致性。

n  為了可伸縮性，你必須對系統(tǒng)進(jìn)行分區(qū)，因此針對特定的系統(tǒng)，你要在高一致性或者高可用性之間做出選擇。你必須找到可用性和一致性的恰當(dāng)重疊部分。

n  基于服務(wù)的需要來選擇特定的實現(xiàn)方法。

n  對于結(jié)賬的過程，你總是想讓更多的物品放入顧客的購物車，因為這樣可以產(chǎn)生收入。在這種情況下你需要選擇高可用性。錯誤對顧客是隱藏的，過后才會被拿出來分析。

n  當(dāng)一個顧客提交訂單過來時，我們要將關(guān)注點更多的放在保持高一致性上。因為幾個不同的服務(wù)——信用卡處服務(wù)、配送服務(wù)、報表功能等——在同時訪問那些數(shù)據(jù)。

汲取的教訓(xùn)

l  為了構(gòu)建真正的可伸縮的系統(tǒng)，你必須改變你的想法或者心態(tài)?；煦绶椒ㄔ诟怕室饬x上可能工作的很好。在傳統(tǒng)的系統(tǒng)中我們展示的是一個完美的世界，沒有什么東西會出現(xiàn)問題、停止運(yùn)轉(zhuǎn)，之后我們在這個完美的世界上構(gòu)造復(fù)雜的算法。實際上，事情總是會出問題的，這就是你必須要接受的事實。例如，試著多想想如何快速完成服務(wù)器重啟和如何快速恢復(fù)數(shù)據(jù)。合適的分布數(shù)據(jù)和服務(wù)，你可能向100%無故障又邁進(jìn)了一步。創(chuàng)建可自愈的（self-healing）、自組織的（self-organizing）系統(tǒng)架構(gòu)。    

l  創(chuàng)建一個沒有分享的基礎(chǔ)架構(gòu)。對于開發(fā)和部署來說，基礎(chǔ)架構(gòu)也是共享資源，就像在邏輯層和數(shù)據(jù)層共享的資源一樣，你也會遭遇到出問題的時候?？赡軙?dǎo)致鎖機(jī)制和屏蔽機(jī)制，并產(chǎn)生死鎖。一個面向服務(wù)的架構(gòu)，允許采取并行和分離的開發(fā)流程，這樣可以使得功能特性的開發(fā)也具有“可伸縮性”，與系統(tǒng)的增長相匹配

l  將系統(tǒng)及其API同時開放，這樣你會圍繞著你的應(yīng)用創(chuàng)建了一個生態(tài)系統(tǒng)。

l  管理巨大的分布式系統(tǒng)的唯一方法，就是讓所有的事情盡可能的簡單。保持事情簡單的辦法就是保證設(shè)計的時候沒有隱藏的需求和隱藏的依賴關(guān)系。采用盡可能少的技術(shù)來解決你解決的問題。人為的創(chuàng)造一些不需要的復(fù)雜系統(tǒng)層次架構(gòu)對公司并沒有益處。

l  圍繞服務(wù)進(jìn)行組織可以提供敏捷性。你可以并行的做事情，因為輸出結(jié)果是一個服務(wù)。這使得縮短了產(chǎn)品和服務(wù)投放到市場去的時間。需要創(chuàng)建一個基礎(chǔ)架構(gòu)來保證服務(wù)可以被很快的構(gòu)建起來。

l  任何事情，在有真正的實現(xiàn)之前，就來了一堆炒作消息，這其中肯定存在著問題。

l  在內(nèi)部使用服務(wù)品質(zhì)協(xié)議（Service Level Agreement，簡稱SLA）來管理服務(wù)。

l  任何人都可以很快的為他們的產(chǎn)品添加Web Services。以服務(wù)的形式來實現(xiàn)你的一部分產(chǎn)品，并開始使用這些服務(wù)。

l  由于性能，可靠性和成本控制的原因，可能需要自己來構(gòu)建基礎(chǔ)設(shè)施架構(gòu)。自己構(gòu)建這些基礎(chǔ)架構(gòu)即便Amazon關(guān)門了也不必說是某某公司的錯誤導(dǎo)致的。自己構(gòu)建的系統(tǒng)可能沒有其他的易用，不過相對使用第三方的東西來說，你可以更快地對自己構(gòu)建的基礎(chǔ)架構(gòu)進(jìn)行修補(bǔ)、調(diào)試和部署。

l  采用“‘方法’和‘目的’”這樣的思辨方式，來區(qū)分好與壞。我曾參加過幾次前Amazon員工做的演講，從中發(fā)現(xiàn)，這是Amazon和其他公司很不一樣的獨(dú)特而有趣之處。其深層道理是，通過將選擇的權(quán)利交給真正的顧客，來看哪種做法最合適，并基于這些測試來發(fā)現(xiàn)顧客的真正需要。Avinash Kaushik把這個叫做避免HiPPO（the highest paid people in the room，屋子里拿薪水最高的人）的影響。通過A/B測試和Web Analytics等技術(shù)手段可以達(dá)成目的。如果你對應(yīng)該做什么有疑問，先開發(fā)一些功能，讓人們使用這些功能，再看哪一種變通使用方式能夠帶給你想要的結(jié)果。

l  創(chuàng)建一個節(jié)儉的環(huán)境。例如，Amazon就把門當(dāng)桌子來用。

l  了解你需要什么。Amazon早期有一個很糟糕的經(jīng)歷，就是沒有達(dá)成預(yù)期目標(biāo)的推薦系統(tǒng)： “這不是我們所需要的圖書推薦系統(tǒng)。Amazon需要的是一個可以基于少量分散的數(shù)據(jù)，例如一些顧客的評分和購買記錄，就可以很好的工作的圖書推薦系統(tǒng)。而且它的反應(yīng)速度要足夠快。這個系統(tǒng)也需要適應(yīng)大量的數(shù)據(jù)和大量的圖書類別。而且它還可以幫助讀者發(fā)現(xiàn)一些他們真正需要卻自己無法發(fā)現(xiàn)的圖書需求。”

l  人性化的項目——人們跟隨這個項目是因為他們對其感興趣——可以激發(fā)更多的價值和創(chuàng)造力。不要低估因為興趣而激發(fā)的力量。

l  在創(chuàng)建產(chǎn)品的過程中，讓每個人都參與進(jìn)來。在圣誕大采購來臨之時，去倉庫打包圖書吧，這樣才是團(tuán)隊精神。

l  創(chuàng)建一個可以用來測試的站點，測試通過之后才可以真正的向大眾推出。

l  對于Web服務(wù)器使用的只讀數(shù)據(jù)來說，一個健壯的、集群式的、冗余的、分布式文件系統(tǒng)是完美的。

l  如果更新沒有成功的話，要有可以回滾到以前正常的狀態(tài)的運(yùn)作方式。必要的話開發(fā)一個工具。

l  轉(zhuǎn)向更深入的基于服務(wù)的架構(gòu)

l  面試的時候需要關(guān)注參加面試者的三個要點：熱情，創(chuàng)造力和熟練程度。在Amazon，成功的最大特征就是對工作的熱情。

l  要雇傭這樣的員工，他們有著驚人的調(diào)試技術(shù)和系統(tǒng)知識，最重要的是，他們可以在高度壓力的狀況下，應(yīng)對非常棘手的問題。

l  創(chuàng)新只能來自于底層。最了解問題的人才是最有可能解決問題的人。任何一個依賴于創(chuàng)新的組織必須可以容納一定程度的混沌。忠誠和服從不是你的工具。

l  創(chuàng)新精神必須無處不在。

l  任何人都應(yīng)該有機(jī)會去嘗試，去學(xué)習(xí)，去實踐。職位的變遷，服從，傳統(tǒng)的習(xí)慣都不應(yīng)該有多大的權(quán)利。創(chuàng)新的蓬勃發(fā)展，必須要有一套行之有效的考核辦法。

l  擁抱創(chuàng)新。在整個公司員工的面前，Jeff Bezos會親自頒發(fā)'Just do it'獎，一雙舊的耐克鞋，給那些具有創(chuàng)新精神員工。

l  不要基于績效給付薪酬。給予好的福利和高的薪酬，但是要讓大部分人都能享受到。通過其他的方式來表達(dá)出對一些表現(xiàn)非常優(yōu)異的員工的認(rèn)可。'按勞分配'聽起來不錯，但是在一個大公司內(nèi)是不可能做到公平的。采用一些非貨幣的獎勵，例如一雙舊的耐克鞋其實也是很好的。那也是一種用來表達(dá)感謝的方式，說明有人在關(guān)心他們。

l  迅速擴(kuò)張。像Barnes& Nobel這樣的大型對手緊跟在你的后面。Amazon曾經(jīng)不是互聯(lián)網(wǎng)上最大的書店，不是第二名，甚至也不是第三名。但是他們的遠(yuǎn)景規(guī)劃和執(zhí)行方式最終讓他們笑到了最后。

l  在數(shù)據(jù)中心，員工花在解決基礎(chǔ)設(shè)施問題上面的時間只有30%是和利潤創(chuàng)造相關(guān)的。其他的70%的時間則是花在"繁重"的硬件采購、軟件管理、負(fù)載均衡、維護(hù)、應(yīng)對增容挑戰(zhàn)等其他事情上。

l  嚴(yán)禁客戶直接訪問數(shù)據(jù)。這意味著你可以讓你的服務(wù)具有可伸縮性，并在不影響客戶的前提下，具有更好的可靠性。這有些類似于Google的能力，他們能夠通過對服務(wù)器棧的獨(dú)立、分布的改進(jìn)，來提升所有的應(yīng)用。

l  創(chuàng)建統(tǒng)一的服務(wù)訪問機(jī)制。這使得服務(wù)易于集成，還可以完成請求路由去中心化、分布請求追蹤、以及其他一些高級的基礎(chǔ)架構(gòu)技術(shù)。

l  讓世界上任何開發(fā)人員都能夠通過Web服務(wù)接口，免費(fèi)訪問Amazon.com。這也是成功的一個重要因素。因為它引發(fā)的諸多創(chuàng)新，僅靠Amazon自己的隊伍是無法想象出來或者無法實現(xiàn)的。

l  開發(fā)人員自己知道哪些工具用起來最順手，什么樣的工具最適合目前的工作。

l  不要在工程師身上強(qiáng)加過多的限制。為某些功能的完成提供一些激勵措施，比如與監(jiān)控系統(tǒng)的集成，或者與其他基礎(chǔ)架構(gòu)工具的集成等功能。但是對于其他的功能，要保證團(tuán)隊的獨(dú)立性。

l  開發(fā)人員與藝術(shù)家類似，如果有足夠的自由，他們就可以把工作做到最好，但是他們也需要好的工具。提供盡量多的支持工具，圍繞著服務(wù)的開發(fā)，提供環(huán)境的支持，使得環(huán)境不會成為開發(fā)工作的阻礙。

l  誰構(gòu)建，誰運(yùn)行。這讓開發(fā)人員與他們所開發(fā)的軟件的日常運(yùn)營工作相聯(lián)系。也帶給他們與顧客之間的日常聯(lián)系。這種顧客反饋循環(huán)對于提升服務(wù)質(zhì)量來說是至關(guān)重要的。

l  每隔兩年，開發(fā)人員就應(yīng)該與客戶服務(wù)部門在一起待一段時間。在那里，他們可以聽到真實的客服電話，回答客服電子郵件，并深刻領(lǐng)會他們作為技術(shù)人員所開發(fā)的東西造成的影響。

l  讓大家聆聽“來自顧客的聲音”，內(nèi)容是一個顧客講述自己使用網(wǎng)站所產(chǎn)生的用戶體驗的真實故事。這可以讓管理層和工程師們體會到，我們是在為實實在在的人們開發(fā)這些技術(shù)。通過客服統(tǒng)計數(shù)據(jù)，我們可以提早發(fā)現(xiàn)做錯了哪些事情，或是發(fā)現(xiàn)哪些是客戶的真實痛點。

l  就像Google一樣，Amazon的基礎(chǔ)架構(gòu)是他們的巨大核心競爭力。通過一些相對簡單的底層服務(wù)，他們可以構(gòu)建出非常復(fù)雜的應(yīng)用。他們可以彼此獨(dú)立地完成各個服務(wù)的增容，維護(hù)非并行系統(tǒng)的可用性，并在不需要修改大量系統(tǒng)配置的情況下，快速發(fā)布新的服務(wù)。

eBay的架構(gòu)

文/Todd Hoff 譯/于曉潮

有誰不想知道eBay是如何開展業(yè)務(wù)的呢？成為世界上最大的高負(fù)荷量的網(wǎng)站之一，這個過程可不容易。創(chuàng)建這樣一個龐然大物，需要真正的工程學(xué)：在網(wǎng)站的穩(wěn)定性、運(yùn)轉(zhuǎn)速度、性能和成本之間達(dá)到一個平衡。

你可能無法模仿eBay增容系統(tǒng)的方法，但是其中的問題和可能的解決方案是值得我們學(xué)習(xí)借鑒的。

平臺

Ÿ   Java

Ÿ   Oracle

Ÿ   WebSphere

Ÿ   Horizontal Scaling

Ÿ   Sharding                                       

Ÿ   Mix of Windows and Unix

統(tǒng)計數(shù)據(jù)

Ÿ   每天一般處理260億個SQL請求，對1億件供出售的商品進(jìn)行跟蹤記錄

Ÿ   2.12億名注冊用戶，10億張照片

Ÿ   每天10億次頁面訪問量，產(chǎn)生1.05億張列表，2PB的數(shù)據(jù)。每月30億應(yīng)用程序接口呼叫。1999年6月到2006年第三季度間，頁面瀏覽量、郵件的發(fā)送量、帶寬增長了35倍。

Ÿ   99.94%的可用性，通過“每個人都可以使用網(wǎng)站的所有部分”與“在某個地方有些用戶無法使用網(wǎng)站的至少一個部分”對比計算得出。

Ÿ   數(shù)據(jù)庫虛擬化，涵蓋分布在100多個服務(wù)器集群中的600種產(chǎn)品實例。

Ÿ   15,000個J2EE應(yīng)用服務(wù)器。大概100組的功能（又叫做apps）。“池”的概念：處理所有銷售業(yè)務(wù)的機(jī)器。[DSJ1] 

架構(gòu)

Ÿ   一切設(shè)計都依照“如果負(fù)荷增長十幾倍會怎么樣”來考慮。采取平行性增容而非垂直性增容，即擁有很多平行的盒子。

Ÿ   架構(gòu)被嚴(yán)格分成：數(shù)據(jù)層、應(yīng)用層、搜索、運(yùn)行

Ÿ   表示層使用MSXML框架（即使在Java中）

Ÿ   Oracle數(shù)據(jù)庫，Websphere Java（1.3.1版本）

Ÿ   依照主訪問路徑、以及對一個主鍵的模數(shù)為界限，劃分?jǐn)?shù)據(jù)庫

Ÿ   每個數(shù)據(jù)庫至少有三個在線數(shù)據(jù)庫，分布在8個數(shù)據(jù)中心。

Ÿ   一些數(shù)據(jù)庫備份在15分鐘、4個小時之后運(yùn)行

Ÿ   數(shù)據(jù)庫依照功能分割為70余項，包括：用戶、項目賬戶、反饋、交易等。

Ÿ   不使用存儲過程，有一些非常簡單的觸發(fā)機(jī)制。   

Ÿ   密集使用CPU的任務(wù)從數(shù)據(jù)庫層移到應(yīng)用層。因為應(yīng)用服務(wù)器便宜而數(shù)據(jù)庫則是制約瓶頸，所以參照完整性、連接和分類在應(yīng)用層完成。

Ÿ   沒有客戶端事務(wù)處理和分布式事務(wù)處理。

Ÿ   J2EE：使用servlets、JDBC、連接池（具有重新寫入功能），其它很少使用。

Ÿ   應(yīng)用層中沒有狀態(tài)信息。狀態(tài)信息存在于cookie或者scratch數(shù)據(jù)庫中。

Ÿ   應(yīng)用服務(wù)器之間沒有對話——采用嚴(yán)格的架構(gòu)分層。

Ÿ   網(wǎng)站上的一般商品在賣出之前其搜索數(shù)據(jù)（比如價格）改變5次，因此實時的搜索結(jié)果非常重要。

Ÿ    Voyager——eBay建立的實時反饋架構(gòu)。使用基本數(shù)據(jù)庫提供的的可靠的多點映射機(jī)制（multicast），來完成節(jié)點搜索、內(nèi)存中的搜索索引、水平分割、N切片、在M個實例中平衡負(fù)載、存儲請求等功能。

經(jīng)驗總結(jié)：

Ÿ   減容，而不是擴(kuò)容

——在每一層上平行增容

——功能分解

Ÿ   推薦異步整合

——最小化可用性耦合

——增加增容的選擇

Ÿ   虛擬組件

——降低物理依存

——提高配置彈性

Ÿ   應(yīng)對故障的設(shè)計

——自動的故障檢測和通知

——在商務(wù)特性中采用“失效保護(hù)模式”

Ÿ   因為數(shù)據(jù)庫是制約瓶頸，所以將任務(wù)從數(shù)據(jù)庫移到應(yīng)用層。Ebay在這方面做的非常極端。我們看到其它的架構(gòu)使用緩存和文件系統(tǒng)來解決數(shù)據(jù)庫的瓶頸問題，而Ebay甚至用應(yīng)用層處理很多傳統(tǒng)的數(shù)據(jù)庫操作（如表連接）。

Ÿ   按自己的意愿使用和舍棄，不必采用全套框架，只使用對你有用的。eBay沒有使用完整的J2EE stack，只是采用servlets、JDBC、連接池等。

Ÿ   不要害怕構(gòu)建滿足你的需求并按需求發(fā)展的解決方案。每一個現(xiàn)成的解決方案都不可能完全讓你高枕無憂，你必須自己走完剩下的路。

Ÿ   隨著業(yè)務(wù)的成長，運(yùn)行控制成為增容的越來越大的一部分。如果運(yùn)行一個即時使用的系統(tǒng)，你必須考慮如何升級、配置和監(jiān)視數(shù)以千計的機(jī)器。

Ÿ   架構(gòu)進(jìn)化——任何一個成長中的網(wǎng)站面臨的主要挑戰(zhàn)。在保持現(xiàn)有網(wǎng)站運(yùn)行的同時，需要有改變、改善和開發(fā)新系統(tǒng)的能力。

Ÿ   一開始就過于擔(dān)心可增容性是錯誤的。因為分析和擔(dān)心可能永遠(yuǎn)也不會發(fā)生的流量而陷入恐慌是不必要的。

Ÿ   完全不考慮可增容性是不對的。事情永遠(yuǎn)不會做完，系統(tǒng)總是在進(jìn)化和改變，你需要建立一個有能力應(yīng)付架構(gòu)進(jìn)化的組織。并且一開始就把這些期望和能力融入你的業(yè)務(wù)中去，不要讓人和組織成為你網(wǎng)站癱瘓的原因。不要認(rèn)為系統(tǒng)一開始就應(yīng)該是完美的，一個好的系統(tǒng)是在解決真正的問題和擔(dān)憂中成長起來的，期待改變，適應(yīng)改變才是正確的態(tài)度。

YouTube網(wǎng)站架構(gòu)

文/Todd Hoff譯/羅小平

YouTube的成長速度驚人，目前每天視頻訪問量已達(dá)1億，但站點維護(hù)人員很少。他們是如何管理，以實現(xiàn)如此強(qiáng)大供應(yīng)能力的？被Google收購后，又在走什么樣的發(fā)展道路呢？

平臺

l  Apache

l  Python

l  Linux (SuSe版本)

l  MySQL

l  psyco（python->C動態(tài)編譯器）

l  lighttpd（取代Apache作為視頻服務(wù)器）

統(tǒng)計數(shù)據(jù)

l  每天高達(dá)1億的視頻訪問量。

l  創(chuàng)建于2005年2月。

l  2006年3月，每日視頻訪問量達(dá)到3千萬。

l  2006年7月，每日視頻訪問量達(dá)到1億。

l  2個系統(tǒng)管理員，2個系統(tǒng)擴(kuò)展架構(gòu)師。

l  2個產(chǎn)品功能開發(fā)人員，2個網(wǎng)絡(luò)工程師，1個DBA。

性能監(jiān)控手段

網(wǎng)站維護(hù)人員每天多次重復(fù)的工作，類似于執(zhí)行下面這段代碼。

while (true)

{

identify_and_fix_bottlenecks();

drink();

sleep();

notice_new_bottleneck();

}

Web服務(wù)器

l  NetScalar用于實現(xiàn)負(fù)載均衡和對靜態(tài)內(nèi)容的緩存。

l  Apache運(yùn)行于mod_fast_cgi模式。

l  一臺Python應(yīng)用服務(wù)器專門負(fù)責(zé)Web請求的路由。

l  應(yīng)用服務(wù)器與各個數(shù)據(jù)庫和其他類型信息源建立會話，取得所需數(shù)據(jù)并生成HTML頁面。

l  通過增加服務(wù)器，一般就可以實現(xiàn)對Web層的擴(kuò)展。

l  Python代碼的效率一般不是瓶頸所在，真正瓶頸在于RPC請求。

l  Python應(yīng)用的開發(fā)和發(fā)布快速靈活，這是他們能夠應(yīng)對激烈競爭的重要保證。

l  正常情況下，能將每個頁面的響應(yīng)時間控制在100ms以內(nèi)。

l  利用psyco（python->C的動態(tài)編譯器），通過JIT編譯方法實現(xiàn)內(nèi)部循環(huán)的優(yōu)化。

l  在CPU高敏感的活動（如加密）中使用C擴(kuò)展。

l  預(yù)生成某些HTML頁面并緩存。

l  在數(shù)據(jù)庫中實現(xiàn)行級緩存。

l  對Python結(jié)果對象緩存。

l  預(yù)先計算某些數(shù)據(jù)，并發(fā)送至對應(yīng)應(yīng)用，以形成本地緩存。這項策略目前還未大規(guī)模運(yùn)用。不需要每個應(yīng)用服務(wù)器都花很多時間將預(yù)先計算，并將結(jié)果數(shù)據(jù)發(fā)送到所有服務(wù)器。有一個代理機(jī)專門負(fù)責(zé)此項工作——監(jiān)控數(shù)據(jù)的變化情況，預(yù)先計算并發(fā)送。

視頻服務(wù)

l  成本，包括帶寬、硬件購置和電力的消耗。

l  每段視頻均通過刀片群集（mini-cluster）服務(wù)器管理，也就是說由多個機(jī)器聯(lián)合提供視頻內(nèi)容服務(wù)。

l  刀片群集管理的優(yōu)勢：

n  多個磁盤提供內(nèi)容服務(wù)，意味著更快的速度。

n  提供了動態(tài)余量。一臺機(jī)器停止服務(wù)，其他可以接管。

n  實現(xiàn)了在線備份。

l  使用lighttpd作為視頻的Web服務(wù)器：

n  Apache的成本太高。

n  使用epoll同時操作多個fds（文件描述符）。

n  從單進(jìn)程切換到多進(jìn)程，以處理更多連接。

l  將頻繁訪問的內(nèi)容轉(zhuǎn)移到CDN（content delivery network）：

n  CDN將內(nèi)容復(fù)制到多個源，因此對用戶來說，獲取數(shù)據(jù)時可以選擇最優(yōu)路徑。

n  CDN服務(wù)器主要依靠內(nèi)存提供服務(wù)，否則因訪問頻繁，可能引起抖動。

l  低訪問量的內(nèi)容（每天1-20的訪問量），YouTube服務(wù)器以colo模式管理。

n  長尾效應(yīng)。單個視頻的訪問量不高，但大量視頻合起來就不一樣了。各磁盤塊被訪問到的概率是隨機(jī)的。

n  在這種情況下，花費(fèi)了大量投入的緩存，作用并不大。這個問題是當(dāng)前研究的一個熱點。如果你有一個長尾型的產(chǎn)品，請記住緩存不見得就是解決性能問題的救世主。

n  優(yōu)化調(diào)整RAID控制器，在底層策略上下功夫。

n  調(diào)整每臺服務(wù)器上的內(nèi)存，不要太大也不要太小。

視頻服務(wù)中的幾個關(guān)鍵點

l  整體方案力求簡潔、廉價。

l  網(wǎng)絡(luò)路徑保持最短，不要在內(nèi)容和終端用戶間部署太多設(shè)備。路由器、交換機(jī)等可能承受不了這么高的負(fù)載。

l  盡量采用普通硬件。高檔硬件的支撐設(shè)備很昂貴，實際中往往發(fā)現(xiàn)它們的作用并不大。

l  使用簡單、通用的工具。YouTube優(yōu)先考慮Linux自帶的大多數(shù)工具。

l  正確處理隨機(jī)尋道問題（采用SATA、優(yōu)化調(diào)整等）。

視頻截圖的處理

l  實現(xiàn)視頻截圖和縮略圖的高效訪問，有著驚人的難度。

l  如果每視頻平均4個縮略圖，那么總圖量是非常龐大的。

l  縮略圖存儲在有限幾臺機(jī)器上。

l  大量小型對象服務(wù)中存在的難點問題：

n   磁盤尋道頻繁，操作系統(tǒng)級inode（譯者注：Linux/Unix系統(tǒng)中記錄文件信息的對象）緩存和頁緩存多。

n  每個目錄受到最大文件數(shù)限制。Ext3文件系統(tǒng)可管理的目錄層級非常多，即便依托2.6內(nèi)核將大目錄處理性能提高100倍左右，在文件系統(tǒng)中存儲大量文件情況下，仍然不是一個值得稱許的解決策略。

n  平均含60個縮略圖的頁面的訪問量很大。

n  在如此高負(fù)載條件下，Apache的性能急劇下降。

n  使用squid（反向代理）作為Apache的前端，能起到一定作用。但隨著負(fù)載的上升，性能最終會呈下降趨勢——處理能力由原來的300個/s降為20個/s。

n  嘗試使用lighttpd。這是一個單進(jìn)程且單線程的應(yīng)用，每個進(jìn)程擁有獨(dú)立緩存。為了提高性能，需要運(yùn)行多個進(jìn)程實例。如此一來，造成了資源浪費(fèi)和性能限制等問題。

n  大量圖片需要處理的情況下，向系統(tǒng)新增一臺機(jī)器，需要24個小時。

n  重啟機(jī)器后，系統(tǒng)需要花費(fèi)6-10小時，來將內(nèi)容從磁盤載入緩存。

l  為了解決這些問題，他們使用了Google的分布式數(shù)據(jù)存儲策略——BigTable：

n  將文件攏在一起，避免了小文件問題。

n  速度快；即使運(yùn)行在不可靠網(wǎng)絡(luò)上，其錯誤率也是可以容忍的。

n  未知風(fēng)險小，因為它使用了分布式的多級緩存。緩存工作于colo結(jié)構(gòu)上。

數(shù)據(jù)庫[DSJ2] 

l  早期：

n  使用MySQL存儲用戶、標(biāo)簽和詳細(xì)描述等原數(shù)據(jù)。

n  數(shù)據(jù)存儲在掛10磁盤、10卷的單片RAID上。

n  租借硬件。負(fù)載上升，添加新設(shè)備時他們需要數(shù)天時間。

n  和其他很多系統(tǒng)一樣，他們走過了這樣一段歷史：單服務(wù)器，主從服務(wù)器（單臺主服務(wù)器，依靠多臺從服務(wù)器實現(xiàn)讀數(shù)據(jù)的負(fù)載均衡），數(shù)據(jù)庫分割（逐漸穩(wěn)定于分割模式）。

n  存在數(shù)據(jù)復(fù)制延遲的問題。主服務(wù)器是多線程的，硬件條件好，性能高；而從服務(wù)器運(yùn)行于單線程模式，且硬件條件差一些。數(shù)據(jù)從主服務(wù)器到從服務(wù)器的復(fù)制是異步的，因此從服務(wù)器上的數(shù)據(jù)往往嚴(yán)重滯后于主服務(wù)器。

n  數(shù)據(jù)更新后，緩存將被清除，需從I/O更慢的磁盤讀取，從而造成復(fù)制更為緩慢。

n  在這種以數(shù)據(jù)復(fù)制為中心的架構(gòu)下，稍微提升寫性能，都必須付出巨大成本。

n  他們的解決辦法之一是將數(shù)據(jù)分割到兩個不同群集，從而分解訪問壓力：一個視頻池和一個普通群集。這個解決方案的出發(fā)點是：訪問者最想看到的是視頻，因此應(yīng)該為這些功能分配最多資源；而YouTube社交功能是次重要的，因此做次優(yōu)配置。

l  后來：

n  繼續(xù)執(zhí)行數(shù)據(jù)庫分割策略。

n  按用戶劃分?jǐn)?shù)據(jù)。

n  數(shù)據(jù)的讀、寫操作分離。

n  改進(jìn)了緩存數(shù)據(jù)定位策略，減少I/O。

n  所需硬件減少了30%。

n  數(shù)據(jù)復(fù)制延遲降為0。

n  現(xiàn)在幾乎能做到對數(shù)據(jù)庫任意擴(kuò)展。

數(shù)據(jù)中心策略

l  開始的時候使用托管機(jī)房。除非事先簽訂了協(xié)議，不能自行擴(kuò)展硬件和網(wǎng)絡(luò)系統(tǒng)。因此，他們后來選擇了colo，可以完全按照自己的設(shè)計要求部署系統(tǒng)。

l  使用5/6個數(shù)據(jù)中心，外加CDN。視頻的來源可以是任何一個數(shù)據(jù)中心，而非就近選擇等模式。若訪問頻度很高，則移至CDN。

l  視頻的訪問性能依賴于帶寬，而不是其他因素。對于圖片，其他因素的影響就很大（例如頁面平均圖片數(shù)）。

l  利用BigTable將圖片復(fù)制到各個數(shù)據(jù)中心。

經(jīng)驗教訓(xùn)

l  敢于堅持。 局部創(chuàng)新和一些有一定風(fēng)險的策略，能夠解決短期問題。如果一直堅持下去，就一定能找到長期解決方案。

l  確定事情的優(yōu)先級。找出服務(wù)中的關(guān)鍵部分，優(yōu)先為其配置資源、投入力量。

l  學(xué)會選擇與合作。不要害怕將項目的關(guān)鍵部分外包。YouTube使用CDN向廣大用戶提供內(nèi)容。如果完全依靠自己建設(shè)這樣一個網(wǎng)絡(luò)，需要花費(fèi)的成本和時間都是驚人的。在你的系統(tǒng)中，應(yīng)該可以存在這類同樣的部件。

l  一切從簡! 簡單，將保證系統(tǒng)具有良好的可重構(gòu)性以及對問題的快速響應(yīng)。沒有人真正知道怎么樣才算是簡單，如果在需要做出改變時，相關(guān)人員沒有產(chǎn)生畏難情緒，就說明達(dá)到了簡單的目標(biāo)。

l  數(shù)據(jù)分割。數(shù)據(jù)分割策略將實現(xiàn)對磁盤、CPU、內(nèi)存和IO實體和指標(biāo)的優(yōu)化配置，改善的不僅僅是寫數(shù)據(jù)的性能。

l  對瓶頸資源做持續(xù)改善：

n  軟件層：數(shù)據(jù)庫、緩存

n  操作系統(tǒng)層：磁盤I/O

n  硬件層：內(nèi)存、RAID

l  團(tuán)隊是成功的基礎(chǔ)。在一個有良好紀(jì)律的團(tuán)隊中，所有成員都能夠準(zhǔn)確把握整個系統(tǒng)，了解深層問題。擁有一個好的團(tuán)隊，將無往而不勝。

Facebook 詳解

文/ wikipedia 譯/張雷

（Facebook在Palo Alto市的總部）

（Facebook創(chuàng)始人兼CEO Mark Zuckerberg）

（Facebook最初的Logo）

簡介

Facebook是一個社會化網(wǎng)絡(luò)站點。它于2004年2月4日上線。

Facebook的創(chuàng)始人是Mark Zuckerberg，他是哈佛大學(xué)的學(xué)生，畢業(yè)于Asdsley高中。最初，網(wǎng)站的注冊僅限于哈佛學(xué)院（譯者注：哈佛大學(xué)的本科生部）的學(xué)生。在之后的兩個月內(nèi)，注冊擴(kuò)展到波士頓地區(qū)的其他高校（波士頓學(xué)院 Boston College、波士頓大學(xué) Boston University、麻省理工學(xué)院 MIT、特福茨大學(xué) Tufts）以及羅切斯特大學(xué) Rochester、斯坦福大學(xué)Stanford、紐約大學(xué) NYU、西北大學(xué)和所有的常春藤名校。第二年，很多其他學(xué)校也加入進(jìn)來。最終，在全球范圍內(nèi)只要有一個大學(xué)后綴電子郵箱的人（如 .edu，.ac.uk等）都可以注冊。之后，在Facebook中也可以建立起高中和公司的社會化網(wǎng)絡(luò)。從2006年9月11日起，任何用戶輸入有效電子郵件地址和自己的年齡段，即可加入。用戶可以選擇加入一個或多個網(wǎng)絡(luò)，比如中學(xué)的、公司的或地區(qū)的。

據(jù)2007年7月數(shù)據(jù)，F(xiàn)acebook在所有以服務(wù)于大學(xué)生為主要業(yè)務(wù)的網(wǎng)站中，擁有最多的用戶——三千四百萬活躍用戶（包括在非大學(xué)網(wǎng)絡(luò)中的用戶）。從2006年9月到2007年9月間，該網(wǎng)站在全美網(wǎng)站中的排名由第60名上升至第7名。同時Facebook也是美國排名第一的照片分享站點，每天上載八百五十萬張照片。這甚至超過其他專門的照片分享站點，如Flickr。

網(wǎng)站的名字Facebook來自傳統(tǒng)的紙質(zhì)“花名冊”。通常美國的大學(xué)和預(yù)科學(xué)校把這種印有學(xué)校社區(qū)所有成員的“花名冊”發(fā)放給新來的學(xué)生和教職員工，幫助大家認(rèn)識學(xué)校的其他成員。

運(yùn)營狀況

網(wǎng)站對用戶是免費(fèi)的，其收入來自廣告。廣告包括橫幅廣告和由商家贊助的小組（2006年4月，有消息稱Facebook每周的收入超過一百五十萬美元）。用戶建立自己的檔案頁，其中包括照片和個人興趣；用戶之間可以進(jìn)行公開或私下留言；用戶還可以加入其他朋友的小組。用戶詳細(xì)的個人信息只有同一個社交網(wǎng)絡(luò)（如學(xué)?；蚬荆┑挠脩艋虮徽J(rèn)證了的朋友才可以查看。據(jù)TechCrunch（譯者：硅谷最著名的IT新聞博客）報道，“在Facebook覆蓋的所有學(xué)校中，85%的學(xué)生有Facebook檔案；（所有這些加入Facebook的學(xué)生中）60%每天都登陸Facebook，85%至少每周登陸一次，93%至少每個月一次。”據(jù)Facebooke 發(fā)言人Chris Hughes說，“用戶平均每天在Facebook上花19分鐘。”據(jù)新澤西州一家專門進(jìn)行大學(xué)市場調(diào)研的公司“學(xué)生監(jiān)聽”在2006年進(jìn)行的調(diào)查顯示，F(xiàn)acebook在“本科生認(rèn)為最in的事”中排名第二，僅次于蘋果的iPod，和啤酒與性并列。

起步

Mark Zuckerberg在Andrew McCollum和Eduardo Saverin的支持下，于2004年2月創(chuàng)辦了“The Facebook”。當(dāng)時他是哈佛大學(xué)的學(xué)生。月底的時候，半數(shù)以上的哈佛本科生已經(jīng)成了注冊用戶。同時，Dustin Moskovitz和Chris Hughes也加入進(jìn)來，幫助推廣網(wǎng)站，將Facebook擴(kuò)展到麻省理工學(xué)院、波士頓大學(xué)和波士頓學(xué)院。擴(kuò)展一直持續(xù)到2004年4月，包括了所有長春藤院校和其他一些學(xué)校。之后的一個月，Zuckerberg，McCollum和Moskovitz搬到加利福尼亞州的Palo Alto市（譯者：斯坦福大學(xué)所在地，硅谷的發(fā)源地），在Adam D'Angelo和Sean Parker（譯者：著名的第一代P2P音樂分享網(wǎng)站Napster的創(chuàng)始人）的幫助下繼續(xù)Facebook的發(fā)展。同年9月，另一個社會化網(wǎng)絡(luò)站點ConnectU的合伙人Divya Narendra，Cameron Winklevoss和Tyler Winlevoss把Facebook告上法庭。他們稱Zuckerberg非法使用了他們在讓他幫助建站時開發(fā)的源代碼。與此同時，F(xiàn)acebook獲得了PayPal創(chuàng)始人Peter Thiel提供的約五十萬美金的天使投資。到12月時，F(xiàn)acebook的用戶數(shù)超過100萬。

2005

2005年5月，F(xiàn)acebook獲得Accel Partners的一千兩百七十萬美元風(fēng)險投資。2005年8月23日，F(xiàn)acebook從AboutFace公司手中以20萬美元購得facebook.com域名，從此從名字中把The去掉了。網(wǎng)站當(dāng)時進(jìn)行了重大改進(jìn)。據(jù)Zuckerberg稱，目的是提高用戶檔案頁面的用戶友好性。這個月，McCollum回哈佛大學(xué)繼續(xù)進(jìn)修，同時仍舊以顧問的身份為Facebook工作，并在暑假來公司工作。Hughes則繼續(xù)在劍橋市（譯者：哈佛大學(xué)所在地）履行他公司發(fā)言人的職責(zé)。2005年9月2日，Zuckerberg推出了Facebook高中版，并稱這是最合乎邏輯的下一步。最初，F(xiàn)acebook高中版雖然被定位為需要邀請才能加入的社區(qū)，但是僅15天以后大部分高中的網(wǎng)絡(luò)不需要密碼也可以加入了（雖然Facebook賬戶還是需要的）。到10月份，F(xiàn)acebook已經(jīng)擴(kuò)展到大部分美國和加拿大的規(guī)模更小的大學(xué)和學(xué)院。除此之外，還擴(kuò)展到英國的21所大學(xué)、墨西哥的ITESM、波多黎各大學(xué)以及維京群島大學(xué)。2005年12月11日，澳大利亞和新西蘭的大學(xué)也加入了Facebook。至此，F(xiàn)acebook中共有超過2000所大學(xué)和高中。

2006

2006年2月27日，應(yīng)用戶要求，F(xiàn)acebook允許大學(xué)生把高中生加為他們的朋友。約一個月后，2006年3月28日，《新聞周刊》報道Facebook可能被收購，談判正在進(jìn)行中。據(jù)報道，F(xiàn)acebook拒絕了一個七億五千萬美金的收購條件，甚至有傳聞收購價格達(dá)到了20億美金。同年四月，Peter Thiel、Greylock Partners和Meritech Capital Partners額外投資了兩千五百萬美元。5月，F(xiàn)acebook擴(kuò)展到印度的印度理工學(xué)院和印度管理學(xué)院。6月，F(xiàn)acebook狀告Quizsender.com抄襲其設(shè)計風(fēng)格，要求賠償十萬美元。7月25日，F(xiàn)acebook增加了更多提高收入機(jī)會的功能。在同蘋果iTunes合作的推廣活動中，加入“蘋果學(xué)生小組”的用戶可以在9月10日之前每周下載25首單曲。這個推廣活動的目的是讓學(xué)生們在秋季學(xué)期開學(xué)前對蘋果和Facebook的服務(wù)都更熟悉和喜愛。8月，F(xiàn)acebook又加入了德國的大學(xué)和以色列的高中。8月22日，F(xiàn)acebook推出Facebook記事本功能——一個可以添加標(biāo)簽、嵌入圖片和評論的博客服務(wù)。同時用戶可以從其他博客服務(wù)中導(dǎo)入。2006年9月11日，F(xiàn)acebook對所有互聯(lián)網(wǎng)用戶開放，這引起了很多現(xiàn)有用戶的抗議。但兩周后，F(xiàn)acebook注冊仍舊對所有擁有有效電子郵件地址的人開放。

2007

2007年5月10日，F(xiàn)acebook宣布了一個提供免費(fèi)分類廣告的計劃，直接和其他分類廣告站點，如Craigslist競爭。這個被稱為“Facebook市場”的功能于2007年5月14日上線。2007年5月24日，F(xiàn)acebook推出應(yīng)用編程接口（API）。通過這個API，第三方軟件開發(fā)者可以開發(fā)在Facebook網(wǎng)站運(yùn)行的應(yīng)用程序。這被稱為Facebook開放平臺（Facebook Platform）。同年6月，和iTunes的合作繼續(xù)為用戶提供免費(fèi)音樂單曲下載。7月，F(xiàn)acebook完成了第一次對其他公司的收購，從Blake Ross和Joe Hewitt手中收購了Parakey（譯者：Ross和Hewitt是火狐瀏覽器的作者，Parakey是一個被稱為網(wǎng)絡(luò)操作系統(tǒng)的平臺）。7月24日，F(xiàn)acebook聘用YouTube的前CFO Gideon Yu為CFO，替換了Michael Sheridan。8月，F(xiàn)acebook成為新聞周刊的封面故事。

2007年9月25日，微軟宣布他們可能會收購Facebook的部分股份。據(jù)稱Facebook被完全收購可能性不大，因為其創(chuàng)始人Mark Zuckerberg希望保持獨(dú)立。

網(wǎng)站功能

墻（The Wall）

墻就是用戶檔案頁上的留言板。有權(quán)瀏覽某一個用戶完整檔案頁的其他用戶，都可以看到該用戶的墻。用戶墻上的留言還會用Feed輸出。很多用戶通過他們朋友的墻，留短信兒。更私秘的交流則通過“消息（Messages）”進(jìn)行。消息發(fā)送到用戶的個人信箱，就象電子郵件，只有收信人和發(fā)信人可以看到。

2007年7月起，用戶可以在墻上貼附件。之前，只允許文本內(nèi)容。

禮物（Gift）

（Facebook禮物）

2007年2月，F(xiàn)acebook新增了“禮物”功能。朋友們可以互送“禮物”－－一些由前蘋果設(shè)計師Susan Kare設(shè)計的有趣的小圖標(biāo)。禮物從Facebook的虛擬禮品店選擇，贈送時附上一條消息。收到的禮物以及所附的消息會顯示在收禮者的“墻”上，除非送禮者設(shè)定這個禮物是私秘的。另外，在墻的上方還有一個“禮盒”。用戶收到的所有禮物都在禮盒中。公開的禮物顯示送禮者的名字，私秘的禮物則顯示“私人”。

另有一個“匿名”的選項。雖然所有人都可以看到禮物，但只有收禮者可以看到送禮者的名字和消息。這種禮物只在禮盒中，而不在墻上顯示。

Facebook用戶注冊時免費(fèi)獲得一個禮物，以后送出每個禮物需要花費(fèi)一美元。最初推出的禮物是有關(guān)“情人節(jié)”的。同年2月由此產(chǎn)生收入的50%捐獻(xiàn)給Susan G. Komen乳腺癌基金會。之后，F(xiàn)acebook每天推出一款新禮物，大多數(shù)都是限量版，或只是限期供應(yīng)。用戶個人主頁會顯示每日禮物的廣告。隨著Facebook開放平臺應(yīng)用程序的出現(xiàn)，第三方開發(fā)的應(yīng)用程序?qū)?美元購買禮物的模式構(gòu)成威脅。請注意，Zachary Allia（譯者：一個第三方程序開發(fā)員）開發(fā)的“免費(fèi)禮物”，與Facebook的官方禮物是不同的。

市場（Marketplace）

2007年5月，F(xiàn)acebook推出Facebook 市場。用戶可以免費(fèi)發(fā)布下列分類廣告：賣二手貨、租房、工作等。供求兩方均可發(fā)布。所有Facebook用戶都可以使用這個功能。目前是免費(fèi)的。

捅（Pokes）

Facebook提供一個“捅（Poke）”的用戶功能，用戶可以給別人發(fā)送一個“Poke”。Facebook常見問題中這樣解釋：“Poke是你和朋友互動的一種方式。當(dāng)我們設(shè)計這個功能時，我們覺得提供這么一個什么意思也沒有的功能其時挺酷。用戶們給Poke不同的解釋。我們鼓勵你給它你自己的解釋。”實際上這個功能的目的只是讓用戶能引起別的用戶的注意。盡管很多用戶確實用這個功能來引起別的用戶注意，或只說聲“嘿“，但有些用戶仍把它理解為“性”的意味。這個解釋造成了一個很熱門的Facebook小組的產(chǎn)生－－“Poke”夠了，咱們干脆做愛吧。到2007年9月，這個小組共有二十五萬用戶。

有時朋友之間會進(jìn)行一種被稱為“Poke仗”的游戲－－兩個用戶間用“Poke”功能，互相Poke來Poke去。

另有一些衍生出來的新功能，如“X 我”，和“超級Poke”，讓用戶可以把Poke替換成任何動作。

狀態(tài)（Status）

狀態(tài)，讓用戶向他們的朋友和Facebook社區(qū)顯示他們現(xiàn)在在哪里、做什么。Facebook讓用戶填入狀態(tài)的提示是“（某某用戶）正在。。。”，用戶填入剩下的部分。在用戶好友列表的“新近更新”區(qū)，顯示這些狀態(tài)。

活動（Events）

Facebook活動的功能幫助用戶通知朋友們將發(fā)生的活動，幫助用戶組織線下的社交活動。

開放平臺上的應(yīng)用（Application）

2007年5月24日，F(xiàn)acebook推出Facebook 開放平臺。利用這個框架，第三方軟件開發(fā)者可以開發(fā)與Facebook核心功能集成的應(yīng)用程序。

最流行的應(yīng)用程序包括：

頂級朋友：用戶可以選擇和顯示他們最好的朋友

涂鴉板：一個圖形效果的“墻”

我喜歡：一個社會化音樂發(fā)現(xiàn)和分享服務(wù)，包括音樂會信息和有關(guān)音樂知識的小游戲

甚至有象棋、拼字游戲之類的游戲出現(xiàn)。而第三方網(wǎng)站如進(jìn)行Facebook應(yīng)用數(shù)據(jù)統(tǒng)計的Adonomics，相關(guān)博客如AppRate、Inside Facebook、Face Reviews等等或應(yīng)運(yùn)而生或?qū)acebook應(yīng)用青眼有加。

2007年7月4日，Altura 風(fēng)投宣布“Altura 1 Facebook投資基金”，成為第一個只投資Facebook相關(guān)項目的風(fēng)險投資。2007年7月10日，Bay Partners宣布成立“應(yīng)用工廠（AppFactory）”，一個只投資Facebook應(yīng)用的種子基金。

2007年8月29日，F(xiàn)acebook改變了他們對應(yīng)用程序熱度的衡量標(biāo)準(zhǔn)，更傾斜于那些有深度價值的應(yīng)用。因為之前，衡量標(biāo)準(zhǔn)僅以用戶數(shù)為標(biāo)準(zhǔn)，使得那些高度“病毒傳播”（譯者：指極易于在用戶間口口相傳）但沒什么用處的程序排名很高。著名IT博客Valleywag曾批評Facebook 應(yīng)用是“一大堆垃圾”。

截止2007年9月26日，共有超過4500個Facebook應(yīng)用出現(xiàn)。

Facebook標(biāo)識語言（Facebook Markup Language）

Facebook 標(biāo)識語言是HTML的子集。Facebook應(yīng)用的開發(fā)者可以用這種語言定制他們的應(yīng)用程序的外觀。

Facebook視頻

與Facebook開放平臺同時推出的，還有一個Facebook自己開發(fā)的應(yīng)用程序－－視頻分享。用戶可以上傳視頻、通過“Facebook移動”上傳手機(jī)視頻，以及用攝像頭錄像。同時用戶可以給視頻中的朋友加“標(biāo)簽”。這一功能被認(rèn)為會與MySpace的相關(guān)功能競爭。但Facebook的視頻只能在Facebook網(wǎng)絡(luò)內(nèi)觀看。然而，一段發(fā)表在Userscripts.org上的Greasemonkey代碼讓用戶可以下載Facebook視頻或?qū)⒅D(zhuǎn)貼在其他網(wǎng)站。

Facebook的域模型

下圖用UML類圖的形式，顯示了Facebook系統(tǒng)所管理的信息。它提煉出了Facebook數(shù)據(jù)庫中的實體、關(guān)系、字段。

比如，圖中顯示了有關(guān)工作、學(xué)校、信用卡、顯示用戶名等的字段。（黃色方框代表類）

請注意該圖為概念類圖，而不是具體實施的細(xì)節(jié)。如欲了解更多數(shù)據(jù)模型的細(xì)節(jié)，請參考Facebook查詢語言（FQL）－－一種類似SQL的查詢語言的相關(guān)資料。