研究:Google、Facebook等網(wǎng)站的技術發(fā)展歷程_第1頁
研究:Google、Facebook等網(wǎng)站的技術發(fā)展歷程_第2頁
研究:Google、Facebook等網(wǎng)站的技術發(fā)展歷程_第3頁
已閱讀5頁,還剩3頁未讀 繼續(xù)免費閱讀

下載本文檔

版權說明:本文檔由用戶提供并上傳,收益歸屬內(nèi)容提供方,若內(nèi)容存在侵權,請進行舉報或認領

文檔簡介

研究:Google、Facebook等網(wǎng)站的技術發(fā)展歷程

Google目前Alexa排名第1。它誕生于1997年,當時是一個研究性項目,每個月build一次索引,build出來的索引通過sharding(shardbydoc)的方式分散到多臺服務器(IndexServer)上,具體的網(wǎng)頁數(shù)據(jù)同樣通過sharding的方式分散到多臺服務器(DocServer)上,當用戶提交請求時,通過前端的一臺服務器將請求提交給IndexServer獲得打了分的倒排索引,然后從DocServer提取具體的網(wǎng)頁信息(例如網(wǎng)頁標題、搜索關鍵詞匹配的片段信息等),最終展現(xiàn)給用戶。隨著索引的網(wǎng)頁增加,這個結構可通過增加IndexServer以及DocServer來存儲索引以及網(wǎng)頁的數(shù)據(jù),但仍然會面臨其他很多方面的問題,于是在這之后的十多年的時間里,Google做了很多事情來改進上面的結構。1999年,Google增加了一個CacheCluster,用來Cache查詢的索引結果和文檔片段信息,同時將IndexServer和DocServer通過Replicate的方式變成了Cluster。這兩個改造帶來的好處是網(wǎng)站的響應速度、可支撐的訪問量以及可用性(Availability)得到了提升。這個變化造成了成本的增加,Google在硬件方面的風格始終是不用昂貴的高端硬件,而是在軟件層面來保證系統(tǒng)的可靠性及高性能,于是同年,Google開始采用自行設計的服務器來降低成本。2000年,Google開始自行設計DataCenter,采用了各種方法(例如采用其他的制冷方法來替代空調(diào))來優(yōu)化PUE(能源利用率),同時對自行設計的服務器也做了很多化。2001年,Google對Index的格式進行了修改,將所有的Index放入內(nèi)存,這次改造帶來的好處是網(wǎng)站的響應速度以及可支撐的訪問量得到了極大的提升。2003年,Google發(fā)表了文章GoogleClusterArchitecture,其Cluster結構組成為硬件LB+IndexCluster+DocCluster+大量廉價服務器(例如IDE硬盤、性價比高的CPU等),通過并行處理+sharding來保證在降低對硬件要求的同時,響應速度仍然很快。同年Google發(fā)表了關于Google文件系統(tǒng)的論文(GFS在2000年就已經(jīng)上線),這篇論文很大程度也體現(xiàn)了Google不用昂貴硬件的風格,通過GFS+大量廉價的服務器即可存儲大量的數(shù)據(jù)。2004年,Google再次對Index的格式進行了修改,使得網(wǎng)站的響應速度繼續(xù)提升。同年Google發(fā)表關于MapReduce的論文,通過MapReduce+大量廉價的服務器即可快速完成以前要使用昂貴小型機、中型機甚至是大型機才能完成的計算任務,而這顯然對于Google快速地構建索引提供了很大的幫助。2006年,Google發(fā)表了關于BigTable的論文(2003年開始上線),使得海量數(shù)據(jù)的分析能夠達到在線系統(tǒng)的要求了,這對于Google提升網(wǎng)站的響應速度起到了很大的幫助。以上3篇論文徹底改變了業(yè)界對于海量數(shù)據(jù)的存儲、分析和檢索的方法(小道消息:Google內(nèi)部已完成了GFS、MapReduce、BigTable的替換),也奠定了Google在業(yè)界的技術領導地位。在一些場景中,Google也采用MySQL來存儲數(shù)據(jù)。同樣,Google對MySQL也做了很多修改,它使用的MySQL信息可以從/p/google-mysql/了解。2007年,Google將build索引的時間縮短到分鐘級,當新網(wǎng)頁出現(xiàn)后,幾分鐘后即可在Google搜索到,同時將IndexCluster通過ProtocolBuffers對外提供Service,以供Google各種搜索(例如網(wǎng)頁、圖片、新聞、書籍等)使用,除了IndexCluster提供的Service外,還有很多其他的Service,例如廣告、詞法檢查等。Google的一次搜索大概需要調(diào)用內(nèi)部50個以上的Service,Service主要用C++或Java來編寫。2009年,Google的一篇《HowGoogleusesLinux》文章,揭示了Google在提升機器利用率方面也做了很多的努力,例如將不同資源消耗類型的應用部署在同一臺機器上。在之后,Google又研發(fā)了Colossus(下一代類GFS文件系統(tǒng))、Spanner(下一代類BigTable海量存儲和計算架構)、實時搜索(基于Colossus實現(xiàn)),主要都是為了提升搜索的實時性以及存儲更多數(shù)據(jù)。除了在海量數(shù)據(jù)相關技術上的革新外,Google也不斷對業(yè)界的傳統(tǒng)技術進行創(chuàng)新,例如提高TCP的初始擁塞窗口值、改進HTTP的SPDY協(xié)議、新的圖片格式WebP等。在Google的發(fā)展過程中,其技術的改造主要圍繞在可伸縮性、性能、成本和可用性4個方面,Google不采用昂貴硬件的風格以及領先其他網(wǎng)站的數(shù)據(jù)量決定了其技術改造基本都是對傳統(tǒng)的軟硬件技術的革新。Facebook目前Alexa排名第2。它采用LAMP構建,隨著業(yè)務的發(fā)展,它也在技術上做了很多改造。作為改造的第一步,F(xiàn)acebook首先在LAMP結構中增加了Memcached,用來緩存各種數(shù)據(jù),從而大幅度提升系統(tǒng)的響應時間以及可支撐的訪問量,之后又增加了Services層,將NewsFeed、Search等較通用的功能作為Service提供給前端的PHP系統(tǒng)使用,前端的系統(tǒng)通過Thrift訪問這些Service。Facebook采用了多種語言來編寫各種不同的Service,主要是針對不同的場景選擇合適的語言,例如C++、Java、Erlang。大量使用Memcached以及訪問量的不斷上漲,導致訪問Memcached的網(wǎng)絡流量太大,交換機無法支撐,F(xiàn)acebook通過改造采用UDP的方式來訪問Memcached,以降低單連接上的網(wǎng)絡流量。除此之外,還有其他一些改造,具體信息可以查看http://on.fb.me/8R0C。PHP作為腳本語言,優(yōu)勢是開發(fā)簡單、易上手,劣勢是需要消耗較多的CPU和內(nèi)存。當Facebook的訪問量增長到了一定規(guī)模后,這個劣勢就比較突出了,于是從2007年起,F(xiàn)acebook就嘗試多種方法來解決這個問題,最后誕生于FacebookHackathon的HipHop產(chǎn)品成功地脫穎而出。HipHop可以自動將PHP轉(zhuǎn)化為C++代碼,F(xiàn)acebook在使用HipHop后,同等配置的機器,可支撐的請求量是之前的6倍,CPU的使用率平均下降了50%,從而為Facebook節(jié)省了大量主機。將來Facebook還會對HipHop進行再次改進,通過HipHop將PHP編譯為bytecode,放入HipHopVM中執(zhí)行,再由HipHopVM來編譯為機器代碼,方式與JIT類似。Twitter目前Alexa排名第8。在2006年誕生之時是采用RubyOnRails+MySQL構建的,2007年增加了Memcached作為Cache層,以提升響應速度。基于RubyonRails讓Twitter享受到了快速的開發(fā)能力,但隨著訪問量的增長,其對CPU和內(nèi)存的消耗也讓Twitter痛苦不堪,于是Twitter做了不少改造和努力,例如編寫了一個優(yōu)化版的RubyGC。2008年Twitter決定逐步往Java遷移,選擇了Scala作為主力的開發(fā)語言(理由是“難以向一屋子的Ruby程序員推銷Java”),采用Thrift作為其主要的通信框架,開發(fā)了Finagle作為其ServiceFramework,可將后端各種功能暴露為Service提供給前端系統(tǒng)使用,使得前端系統(tǒng)無需關心各種不同的通信協(xié)議(例如對于使用者可以用同樣的調(diào)用服務的方式去訪問Memcache、Redis、Thrift服務端),開發(fā)了Kestrel作為其消息中間件(替代之前用Ruby寫的Starling)。Twitter的數(shù)據(jù)存儲一直采用MySQL,發(fā)展過程中出現(xiàn)的小插曲是,當Facebook開源了Cassandra時,Twitter本計劃使用,但最終還是放棄,仍然保持了使用MySQL,Twitter的MySQL版本已開源(/twitter/mysql)。Twitter也是采用分庫分表的方式來支撐大數(shù)據(jù)量,使用Memcached來Cachetweet,timeline的信息則遷移為用Redis來Cache。2010年,Twitter在鹽湖城擁有了第一個自建的DataCenter,主要是為了增加可控性。從Twitter的發(fā)展過程看,6年來它的技術改造主要圍繞可伸縮以及可用性。作為一家電子商務網(wǎng)站的員工,請允許我在此介紹這個Alexa排名21的著名電子商務網(wǎng)站的技術演變。1995年,eBay誕生,當時采用CGI編寫,數(shù)據(jù)庫采用的是GDBM,最多只能支撐5萬件在線商品。1997年,eBay將操作系統(tǒng)從FreeBSD遷移到WindowsNT,另外將數(shù)據(jù)庫從GDBM遷移為Oracle。1999年,eBay將前端系統(tǒng)改造為Cluster(之前只有一臺主機),采用Resonate作為負載均衡,后端的Oracle機器升級為SunE1000小型機,同年給數(shù)據(jù)庫增加了一臺機器作為備庫,提升可用性。前端機器隨著訪問量不斷增加還可以應付,但數(shù)據(jù)庫機器在1999年11月時已經(jīng)達到了瓶頸(已經(jīng)不能再加CPU和內(nèi)存了),于是在11月開始將數(shù)據(jù)庫按業(yè)務拆分為多個庫。2001-2002年,eBay將數(shù)據(jù)表進行了水平拆分,例如按類目存儲商品,同時部署Oracle的小型機換為SunA3500。2002年,將整個網(wǎng)站遷移為用Java構建,在這個階段,做了DAL框架來屏蔽數(shù)據(jù)庫分庫分表帶來的影響,同時還設計了一個開發(fā)框架以供開發(fā)人員更好地上手進行功能開發(fā)。從eBay的整個發(fā)展過程來看,技術改造主要圍繞在可伸縮性和可用性兩點。騰訊目前Alexa排名第9。最初QQIM采用的是單臺接入服務器來處理用戶的登錄和狀態(tài)保持,但在發(fā)展到一百萬用戶同時在線時,這臺服務器已經(jīng)無法支撐。于是QQIM將所有單臺服務器改造為了集群,并增加了狀態(tài)同步服務器,由其完成集群內(nèi)狀態(tài)的同步,用戶的信息存儲在MySQL中,做了分庫分表,好友關系存儲在自行實現(xiàn)的文件存儲中。為了提升進程間通信的效率,騰訊自行實現(xiàn)了用戶態(tài)IPC。之后騰訊將狀態(tài)同步服務器也改造為同步集群,以支撐越來越多的在線用戶。在經(jīng)歷了前面幾次改造后,已基本能支撐千萬級別的用戶同時在線,但可用性比較差,于是騰訊對QQIM再次進行改造,實現(xiàn)了同城跨IDC的容災,加強了監(jiān)控和運維系統(tǒng)的建設。此后騰訊決定對QQIM架構完全重寫(大概是2009年持續(xù)到現(xiàn)在),主要是為了增強靈活性、支持跨城市的IDC、支撐千萬級的好友。在這次大的技術改造過程中,騰訊的數(shù)據(jù)都不再存儲于MySQL中,而是全部存儲在了自己設計的系統(tǒng)里。從QQIM的技術演變來看,其技術改造主要是圍繞在可伸縮性和可用性上。2003年,淘寶誕生,直接購買了一個商業(yè)的phpAuction的軟件,在此基礎上改造產(chǎn)生了淘寶。2004年,將系統(tǒng)由PHP遷移到Java,MySQL遷移為Oracle(小型機、高端存儲設備),應用服務器采用了WebLogic。2005-2007年的發(fā)展過程中,用JBoss替代了WebLogic,對數(shù)據(jù)庫進行了分庫,基于BDB做了分布式緩存,自行開發(fā)了分布式文件系統(tǒng)TFS以支持小文件的存儲,并建設了自己的CDN。2007-2009年對應用系統(tǒng)進行垂直拆分,拆分后的系統(tǒng)都以Service的方式對外提供功能,對數(shù)據(jù)采用了垂直和水平拆分。在進行

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯(lián)系上傳者。文件的所有權益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網(wǎng)頁內(nèi)容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
  • 4. 未經(jīng)權益所有人同意不得將文件中的內(nèi)容挪作商業(yè)或盈利用途。
  • 5. 人人文庫網(wǎng)僅提供信息存儲空間,僅對用戶上傳內(nèi)容的表現(xiàn)方式做保護處理,對用戶上傳分享的文檔內(nèi)容本身不做任何修改或編輯,并不能對任何下載內(nèi)容負責。
  • 6. 下載文件中如有侵權或不適當內(nèi)容,請與我們聯(lián)系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論