隨筆-72  評論-20  文章-0  trackbacks-1

          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ā)展道路呢?

          平臺

          Apache

          l  Python

          Linux (SuSe版本)

          MySQL

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

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

          數(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 譯/張雷

          http://www.yeeyan.com/img/fb_hq.jpg

          (Facebook在Palo Alto市的總部)

          http://www.yeeyan.com/img/fb_z.jpg

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

          http://www.yeeyan.com/img/fb_lg.jpg

          (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)

          http://www.yeeyan.com/img/fb_gifts.JPG

          (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)博客如AppRateInside 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)資料。

          技術(shù)構(gòu)架

          Facebook使用LAMP(Linux、 Apache、 MySQL、 PHP)作為技術(shù)構(gòu)架。Facebook的一個技術(shù)構(gòu)架工程師Steven Grimm在博客中寫到:

          幾乎我們所有的服務(wù)器都運(yùn)行開源軟件。我們的Web服務(wù)器是Linux,Apache和PHP。我們數(shù)據(jù)庫是MySQL。我們使用memchached來保證網(wǎng)站的快速反應(yīng)。一些后臺應(yīng)用Python、Perl和Java,以及一些gcc和Boost。程序員用Subversion和git來進(jìn)行代碼管理。還有很多--象很多網(wǎng)站一樣,從頭到腳都是開源軟件。

          收購傳聞

          2006年隨著MySpace被新聞集團(tuán)收購,關(guān)于Facebook會被一家大的媒體公司收購的傳聞出現(xiàn)。Facebook的創(chuàng)始人Zuckerberg說過他不想出售公司,并否認(rèn)了這些傳聞。他已經(jīng)拒絕了九億七千五百萬美元左右的收購價格,不知還有誰愿意出高出這個的價格收購Facebook。分析師Steve Rosenbush猜測是維亞康姆(Viacom)。2006年9月,F(xiàn)acebook和Yahoo開始進(jìn)行關(guān)于收購的認(rèn)真談判,價格約10億美元。同年10月,隨著Google以16億美元收購YouTube,有傳聞?wù)fGoogle開價23億美元欲從Yahoo手中搶購Facebook。

          Facebook的董事Peter Thiel暗示,根據(jù)2015年10億美元收入的估計,F(xiàn)acebook內(nèi)部的估值是80億美元。這一估值依據(jù)對與Facebook用戶構(gòu)成類似的維亞康姆的MTV品牌的估值。

          2007年9月,微軟向Facebook示好,欲以3-5億美元投資該公司5%的股份。(譯者:這使得Facebook的估值在60-100億美元左右)其他公司,如Google也表示過類似興趣。

          注:原文來自英文維基百科“Facebook”條目

                 譯文來自《譯言-Facebook啟示錄小組》

          posted on 2008-01-15 09:57 前方的路 閱讀(2976) 評論(0)  編輯  收藏 所屬分類: 軟件架構(gòu)Web 2.0
          主站蜘蛛池模板: 冷水江市| 麟游县| 茌平县| 四子王旗| 长宁县| 临洮县| 丰镇市| 家居| 六安市| 兰西县| 莱阳市| 柏乡县| 广饶县| 鄯善县| 黄山市| 泸西县| 绥中县| 陆河县| 台州市| 正镶白旗| 关岭| 招远市| 舞阳县| 兴文县| 喜德县| 长顺县| 隆林| 崇明县| 南川市| 邢台县| 天镇县| 车险| 沈阳市| 龙井市| 建阳市| 巍山| 青海省| 宁武县| 英吉沙县| 雅安市| 大冶市|