Google 目前 Alexa 排名第1。它誕生於 1997 年，當時是一個研究性項目，每個月 build 一次索引，build 出來的索引通過 sharding（shard by doc）的方式分散到多台服務器（Index Server）上，具體的網頁數據同樣通過 sharding 的方式分散到多台服務器（Doc Server）上，當用戶提交請求時，通過前端的一台服務器將請求提交給 Index Server 獲得打了分的倒排索引，然後從 Doc Server 提取具體的網頁信息（例如網頁標題、搜索關鍵詞匹配的片段信息等），最終展現給用戶。
隨著索引的網頁增加，這個結構可通過增加 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。
來自: www.programmer.com.cn