知名網站的技術發展歷程以及實力怎么樣

知名網站的技術發展歷程
Google目前Alexa排名第1。它誕生于1997年，當時是一個研究性項目，每個月build一次索引，build出來的索引通過sharding（shard by doc）的方式分散到多臺服務器（Index Server）上，具體的網頁數據同樣通過sharding的方式分散到多臺服務器（Doc Server）上，當用戶提交請求時，通過前端的一臺服務器將請求提交給Index Server獲得打了分的倒排索引，然后從Doc Server提取具體的網頁信息（例如網頁標題、搜索關鍵詞匹配的片段信息等），最終展現給用戶。

隨著索引的北京網站制作(www.yiyouzhen.cn)增加，這個結構可通過增加Index Server以及Doc Server來存儲索引以及網頁的數據，但仍然會面臨其他很多方面的問題，于是在這之后的十多年的時間里，Google做了很多事情來改進上面的結構。

1999年，Google增加了一個Cache Cluster，用來Cache查詢的索引結果和文檔片段信息，同時將Index Server和Doc Server通過Replicate的方式變成了Cluster。這兩個改造帶來的好處是網站的響應速度、可支撐的訪問量以及可用性（Availability）得到了提升。這個變化造成了成本的增加，Google在硬件方面的風格始終是不用昂貴的高端硬件，而是在軟件層面來保證系統的可靠性及高性能，于是同年，Google開始采用自行設計的服務器來降低成本。2000年，Google開始自行設計DataCenter，采用了各種方法（例如采用其他的制冷方法來替代空調）來優化PUE（能源利用率），同時對自行設計的服務器也做了很多化。2001年，Google對Index的格式進行了修改，將所有的Index放入內存， 這次改造帶來的好處是網站的響應速度以及可支撐的訪問量得到了極大的提升。2003年，Google發表了文章Google Cluster Architecture，其Cluster結構組成為硬件LB+Index Cluster+Doc Cluster+大量廉價服務器（例如IDE硬盤、性價比高的CPU等），通過并行處理+sharding來保證在降低對硬件要求的同時，響應速度仍然很快。同年Google發表了關于Google文件系統的論文（GFS在2000年就已經上線），這篇論文很大程度也體現了Google不用昂貴硬件的風格，通過GFS+大量廉價的服務器即可存儲大量的數據。2004年，Google再次對Index的格式進行了修改，使得網站的響應速度繼續提升。同年Google發表關于MapReduce的論文，通過MapReduce+大量廉價的服務器即可快速完成以前要使用昂貴小型機、中型機甚至是大型機才能完成的計算任務，而這顯然對于Google快速地構建索引提供了很大的幫助。2006年，Google發表了關于BigTable的論文（2003年開始上線），使得海量數據的分析能夠達到在線系統的要求了，這對于Google提升網站的響應速度起到了很大的幫助。

以上3篇論文徹底改變了業界對于海量數據的存儲、分析和檢索的方法（小道消息：Google內部已完成了GFS、MapReduce、BigTable的替換），也奠定了Google在業界的技術領導地位。

在一些場景中，Google也采用MySQL來存儲數據。同樣，Google對MySQL也做了很多修改，它使用的MySQL信息可以從https://code.google.com/p/google-mysql/了解。

2007年，Google將build索引的時間縮短到分鐘級，當新網頁出現后，幾分鐘后即可在Google搜索到，同時將Index Cluster通過Protocol Buffers對外提供Service，以供Google各種搜索（例如網頁、圖片、新聞、書籍等）使用，除了Index Cluster提供的Service外，還有很多其他的Service，例如廣告、詞法檢查等。Google的一次搜索大概需要調用內部50個以上的Service，Service主要用C++或Java來編寫。2009年，Google的一篇《How Google uses Linux》文章，揭示了Google在提升機器利用率方面也做了很多的努力，例如將不同資源消耗類型的應用部署在同一臺機器上。

在之后，Google又研發了Colossus（下一代類GFS文件系統）、Spanner（下一代類BigTable海量存儲和計算架構）、實時搜索（基于Colossus實現），主要都是為了提升搜索的實時性以及存儲更多數據。除了在海量數據相關技術上的革新外，Google也不斷對業界的傳統技術進行創新，例如提高TCP的初始擁塞窗口值、改進HTTP的SPDY協議、新的圖片格式WebP等。

在Google的發展過程中，其技術的改造主要圍繞在可伸縮性、性能、成本和可用性4個方面，Google不采用昂貴硬件的風格以及領先其他網站的數據量決定了其技術改造基本都是對傳統的軟硬件技術的革新。

Facebook目前Alexa排名第2。它采用LAMP構建，隨著業務的發展，它也在技術上做了很多改造。
作為改造的第一步，Facebook首先在LAMP結構中增加了Memcached，用來緩存各種數據，從而大幅度提升系統的響應時間以及可支撐的訪問量，之后又增加了Services層，將News Feed、Search等較通用的功能作為Service提供給前端的PHP系統使用，前端的系統通過Thrift訪問這些Service。Facebook采用了多種語言來編寫各種不同的Service，主要是針對不同的場景選擇合適的語言，例如C++、Java、Erlang。

大量使用Memcached以及訪問量的不斷上漲，導致訪問Memcached的網絡流量太大，交換機無法支撐，Facebook通過改造采用UDP的方式來訪問Memcached，以降低單連接上的網絡流量。除此之外，還有其他一些改造，具體信息可以查看http://on.fb.me/8R0C。

PHP作為腳本語言，優勢是開發簡單、易上手，劣勢是需要消耗較多的CPU和內存。當Facebook的訪問量增長到了一定規模后，這個劣勢就比較突出了，于是從2007年起，Facebook就嘗試多種方法來解決這個問題，最后誕生于Facebook Hackathon的HipHop產品成功地脫穎而出。

HipHop可以自動將PHP轉化為C++代碼，Facebook在使用HipHop后，同等配置的機器，可支撐的請求量是之前的6倍，CPU的使用率平均下降了50%，從而為Facebook節省了大量主機。將來Facebook還會對HipHop進行再次改進，通過HipHop將PHP編譯為bytecode，放入HipHop VM中執行，再由HipHop VM來編譯為機器代碼，方式與JIT類似。

2009年，Facebook研發了BigPipe，借助此系統，Facebook成功讓網站的速度提升了兩倍。隨著Facebook訪問量的上漲，收集眾多服務器上的執行日志也開始面臨挑戰，于是Facebook研發了Scribe來解決此問題。對于存儲在MySQL中的數據，Facebook采用垂直拆分庫和水平拆分表的方式來支撐不斷增長的數據量。作為Facebook技術體系中重要的一環，Facebook也對MySQL進行了很多優化和改進，例如Online Schema Change等，更多信息可見http://www.facebook.com/MySQLAtFacebook。

發展之初的Facebook采用了高端的存儲設備（例如NetApp、Akamai）來存圖片，隨著圖片不斷增加，成本也大幅提高，于是2009年Facebook開發了Haystack來存儲圖片。Haystack可采用廉價的PC Server進行存儲，大幅度降低了成本。

Facebook除了使用MySQL存儲數據外，近幾年也開始摸索采用新的方式。在2008年Facebook開發了Cassandra，在Message Inbox Search中作為新的存儲方式。不過在2010年，Facebook又放棄了Cassandra，轉為采用HBase作為其Messages的存儲，并在2011年將HBase應用在了Facebook更多的項目上（例如Puma、ODS）。據說，現在Facebook更是在嘗試將其用戶以及關系數據從MySQL遷移到HBase。
從2009年開始，Facebook嘗試自行設計DataCenter以及服務器，以降低其運行成本，并對外開放了其構建的PUE僅1.07的DataCenter的相關技術。Facebook在技術方面的基本原則是：“在能用開源產品的情況下就用開源，根據情況對其進行優化并反饋給社區”。從Facebook的技術發展歷程上可以看到這個原則貫徹始終，Facebook的技術改造也主要是圍繞在可伸縮、性能、成本和可用性4個方面。

Twitter目前Alexa排名第8。在2006年誕生之時是采用Ruby On Rails+ MySQL構建的，2007年增加了Memcached作為Cache層，以提升響應速度。基于Ruby on Rails讓Twitter享受到了快速的開發能力，但隨著訪問量的增長，其對CPU和內存的消耗也讓Twitter痛苦不堪，于是Twitter做了不少改造和努力，例如編寫了一個優化版的Ruby GC。

2008年Twitter決定逐步往Java遷移，選擇了Scala作為主力的開發語言（理由是“難以向一屋子的Ruby程序員推銷Java”），采用Thrift作為其主要的通信框架，開發了Finagle作為其Service Framework，可將后端各種功能暴露為Service提供給前端系統使用，使得前端系統無需關心各種不同的通信協議（例如對于使用者可以用同樣的調用服務的方式去訪問Memcache、Redis、Thrift服務端），開發了Kestrel作為其消息中間件（替代之前用Ruby寫的Starling）。

Twitter的數據存儲一直采用MySQL，發展過程中出現的小插曲是，當Facebook開源了Cassandra時，Twitter本計劃使用，但最終還是放棄，仍然保持了使用MySQL，Twitter的MySQL版本已開源（https://github.com/twitter/mysql）。Twitter也是采用分庫分表的方式來支撐大數據量，使用Memcached來Cache tweet，timeline的信息則遷移為用Redis來Cache。
2010年，Twitter在鹽湖城擁有了第一個自建的DataCenter，主要是為了增加可控性。從Twitter的發展過程看，6年來它的技術改造主要圍繞可伸縮以及可用性。

作為一家電子商務網站的員工，請允許我在此介紹這個Alexa排名21的著名電子商務網站的技術演變。
1995年，eBay誕生，當時采用CGI編寫，數據庫采用的是GDBM，最多只能支撐5萬件在線商品。1997年，eBay將操作系統從FreeBSD遷移到Windows NT，另外將數據庫從GDBM遷移為Oracle。1999年，eBay將前端系統改造為Cluster（之前只有一臺主機），采用Resonate作為負載均衡，后端的Oracle機器升級為Sun E1000小型機，同年給數據庫增加了一臺機器作為備庫，提升可用性。前端機器隨著訪問量不斷增加還可以應付，但數據庫機器在1999年11月時已經達到了瓶頸（已經不能再加CPU和內存了），于是在11月開始將數據庫按業務拆分為多個庫。2001-2002年，eBay將數據表進行了水平拆分，例如按類目存儲商品，同時部署Oracle的小型機換為Sun A3500。2002年，將整個網站遷移為用Java構建，在這個階段，做了DAL框架來屏蔽數據庫分庫分表帶來的影響，同時還設計了一個開發框架以供開發人員更好地上手進行功能開發。從eBay的整個發展過程來看，技術改造主要圍繞在可伸縮性和可用性兩點。

騰訊目前Alexa排名第9。最初QQ IM采用的是單臺接入服務器來處理用戶的登錄和狀態保持，但在發展到一百萬用戶同時在線時，這臺服務器已經無法支撐。于是QQ IM將所有單臺服務器改造為了集群，并增加了狀態同步服務器，由其完成集群內狀態的同步，用戶的信息存儲在MySQL中，做了分庫分表，好友關系存儲在自行實現的文件存儲中。為了提升進程間通信的效率，騰訊自行實現了用戶態IPC。之后騰訊將狀態同步服務器也改造為同步集群，以支撐越來越多的在線用戶。在經歷了前面幾次改造后，已基本能支撐千萬級別的用戶同時在線，但可用性比較差，于是騰訊對QQ IM再次進行改造，實現了同城跨IDC的容災，加強了監控和運維系統的建設。此后騰訊決定對QQ IM架構完全重寫（大概是2009年持續到現在），主要是為了增強靈活性、支持跨城市的IDC、支撐千萬級的好友。在這次大的技術改造過程中，騰訊的數據都不再存儲于MySQL中，而是全部存儲在了自己設計的系統里。
從QQ IM的技術演變來看，其技術改造主要是圍繞在可伸縮性和可用性上。

2003年，淘寶誕生，直接購買了一個商業的phpAuction的軟件，在此基礎上改造產生了淘寶。2004年，將系統由PHP遷移到Java，MySQL遷移為Oracle（小型機、高端存儲設備），應用服務器采用了WebLogic。2005-2007年的發展過程中，用JBoss替代了WebLogic，對數據庫進行了分庫，基于BDB做了分布式緩存，自行開發了分布式文件系統TFS以支持小文件的存儲，并建設了自己的CDN。2007-2009年對應用系統進行垂直拆分，拆分后的系統都以Service的方式對外提供功能，對數據采用了垂直和水平拆分。
在進行了數據的垂直和水平拆分后，Oracle產生的成本越來越高，于是在之后的幾年，淘寶又開始將數據逐漸從Oracle遷移到MySQL，同時開始嘗試新型的數據存儲方案，例如采用HBase來支撐歷史交易訂單的存儲和檢索等。近幾年淘寶開始進行Linux內核、JVM、Nginx等軟件的修改定制工作，同時也自行設計了低能耗服務器，同時在軟硬件上進行優化，以更好地降低成本。
從淘寶的整個發展過程來看，技術改造主要圍繞在可伸縮性和可用性兩點，現在也開始逐漸將精力投入在了性能和成本上。目前淘寶的Alexa排名為第14。
總結
從上面這些Alexa排名靠前網站的技術發展過程來看，每家網站由于其所承擔的業務不同、團隊人員組成不同、做事風格相異，在技術的不同發展階段中會采用不同的方法來支撐業務的發展，但基本都會圍繞在可伸縮性、可用性、性能以及成本這4點上，在發展到比較大規模后，各網站在技術結構上有了很多的相似點，并且這些結構還將繼續進行演變。
原作者林昊，就職于淘寶，2007-2010年負責設計和實現淘寶的服務框架，此服務框架在淘寶大面積使用，每天承擔了150億+的請求；2011年開始負責HBase在淘寶的落地，目前淘寶已有20個以上的在線項目在使用HBase。
其它: Cassandra
設計Cassandra存儲的時候，書中建議要圍繞著查詢建模，而不是最先對數據進行建模。有人反對這個，認為查詢的類型變化太快了。作者是這樣反駁的：查詢類型和數據本身都有變化的。Cassandra最根本的模型是簡單的kv，所以，還是得盡可能的圍繞查詢建模。這里怎么更好的協調，是一個有挑戰的事情。
Cassandra的column family就像一個表結構，修改了要重啟，一個cf單獨一個文件，一行數據可以有多個column family。user是一個family, user_ext一個family, row key 為uid, 感覺cassandra用起來會更像db，

Youtube的社交趨勢經理Kevin Allocca解釋最火的youtube視頻的三個共同點。1、Tastemakers － 達人的推薦。 2、Community － 志氣相投的群體。 3、Surprise － 意想不到的驚奇。
Cassandra在360的應用，用戶收藏夾、圖床、垂直搜索等在線業務有大量存儲需求，考慮到MySQL不能滿足需求，但是HBase有Availabilty的缺點，所以選擇了Cassandra，目前規模是600~700臺，年底預計1500左右，目前沒有出過大的故障。估計是全球最大規模Cassandra集群

Key-Value，Column oriented，Document oriented三個概念的區別和聯系誰能幫我解釋清楚。看了圖中的劃分，我徹底糊涂了。我一直以為三者是一回事
：息隊列傳輸：kafka，timetunnel，kestrel，scribe；列存儲數據庫領域hbase；kv型數據庫：cassandra，riak，voldemort，tair；文檔數據庫：mongodb，couchdb；圖形數據庫：neo4j，pregel，flockdb；流式計算：storm，iprocess；實時計算：prom；圖形計算：pregel，apache hama；離線計算：hive，spark。

facebook 局部kv過期用復雜的中間層解決
mysql上沒有join查詢，并采用昂貴的Fusion IO。nginx好于lighttpd。scribe是個好東西
本文發布于北京網站制作公司尚品中國http://www.yiyouzhen.cn/