Google架構

文/Todd Hoff 譯/黃翀

Google是可伸縮性控制方面的王者。Google一直的目標就是構建高性能高伸縮性的基礎組織來支持它們的產品。

平臺

l  Linux

l  開發語言：Python，Java，C++

狀態

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

l  在2005年Google索引了80億Web頁面，現在沒有人知道數目

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

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

l  BigTable伸縮存儲幾十億的URL，幾百千千兆的衛星圖片和幾億用戶的參數選擇

架構

Google將它們的基礎架構形象化為三層架構：

l  產品：搜索，廣告，email，地圖，視頻，聊天，博客

l  分布式系統基礎組織：GFS，MapReduce和BigTable

l  計算平臺：一群不同的數據中心里的機器

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

l  在避免丟失日志數據的硬件上花費較多的錢，其他類型的數據則花費較少

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

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

l  Google File System ——大型分布式結構化日志文件系統，Google在里面存儲了大量的數據。

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

n  跨數據中心的高可靠性

n  成千上萬的網絡節點的伸縮性

n  大讀寫帶寬的需求

n  支持大塊的數據，可能為上千兆字節

n  高效的跨節點操作分發以減少瓶頸

l  Master和Chunk服務器：

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

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

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

l  關鍵點在于有足夠的基礎組織可以讓人們對自己的程序有所選擇，GFS可以調整來適應個別程序的需求。

使用MapReduce來處理數據

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

l  MapReduce是一個處理和生成大量數據集的編程模型和相關實現。用戶指定一個map方法來處理一個鍵/值來生成一個中間的鍵/值，還有一個reduce方法以合并所有關聯到同樣的中間鍵的中間值。許多真實世界的任務都可以使用這種模型來表現。以這種風格來寫的程序會自動的在一個擁有大量機器的集群里并行運行。運行時系統處理輸入數據的劃分、程序在機器集之間執行的調度、機器失敗處理和必需的內部機器交流等細節。這就允許程序員沒有多少并行和分布式系統的經驗就可以很容易使用一個大型分布式系統資源。

l  為什么使用MapReduce？

n  跨越大量機器分割任務的好方式。

n  處理機器失敗。

n  可以與不同類型的程序工作，例如搜索和廣告。幾乎任何程序都有map和reduce類型的操作。可以預先計算有用的數據、查詢字數統計、對TB的數據排序等等。

l  MapReduce系統有三種不同類型的服務器：

n  Master服務器分配用戶任務到Map和Reduce服務器。它也跟蹤任務的狀態。

n  Map服務器接收用戶輸入并在其基礎上處理map操作。結果寫入中間文件。

n  Reduce服務器接收Map服務器產生的中間文件并在其基礎上處理reduce操作。

l  例如，你想統計在所有Web頁面里的字數。你應該將存儲在GFS里的所有頁面拋入MapReduce。所有的調整、工作調度、失敗處理和數據傳輸將在成千上萬臺機器上同時進行并且自動完成。

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

n  在MapReduce里一個map操作將一些數據映射到另一個中，產生一個鍵值對，在我們的例子里就是字和字數。

n  Shuffling操作聚集鍵類型。

n  Reduction操作計算所有鍵值對的綜合并產生最終的結果。

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

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

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

l  數據在Map和Reduce服務器之間傳輸時被壓縮了。這可以節省帶寬和I/O。

在BigTable里存儲結構化數據

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

l  BigTable是一個構建于GFS之上的分布式Hash機制，但不是關系型數據庫，不支持join或者SQL類型查詢。

l  提供查詢機制通過鍵訪問結構化數據。GFS存儲存儲不透明的數據，而許多程序需求有結構化數據。

l  商業數據庫不能達到這種級別的伸縮性，并且不能在成千上萬臺機器上工作。

l  通過控制自己的低級存儲系統，Google得到更多的控制權來改進它們的系統。例如，如果想讓跨數據中心的操作更簡單這個特性，就可以內建它。

l  可以自由的增刪系統運行時機器，而整個系統可以保持正常工作。

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

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

l  BigTable有三種類型的服務器：

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

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

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

l  一個locality組可以將物理上將相關的數據存儲在一起以便得到更好的locality選擇。

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

硬件

l  當你有很多機器時，你怎樣組織它們來達到成本的有效利用，并發揮最大效力？

l  使用非常廉價的硬件。

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

l  Linux系統，采取內部機架放置的設計方式，使用PC主板，低端存儲。

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

l  混合使用服務器，并使用他們自己的數據中心。

其他

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

l  庫是構建程序的卓越方式。

l  一些程序作為服務提供。

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

Google將來的方向

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

l  為所有數據創建一個單獨的全局名字空間，將當前的數據從集群分離。

l  更多和更好的自動化數據遷移和計算。

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

經驗教訓

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

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

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

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

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

l  構建自管理系統讓你沒必要讓系統關機。這允許你更容易在服務器之間平衡資源，動態添加更大的容量，讓機器離線和優雅的處理升級。

l  創建可進化的基礎組織，并行的執行消耗時間的操作并采取較好的方案。

l  不要忽略大學等研究教學機構。那里有許多沒有轉變為產品的好主意。絕大部分Google所實現的領先技術，其實并不是多么宏大且超前的設計。

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

Amazon的體系結構

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

平臺

l  Linux

l  Oracle

l  C++

l  Perl

l  Mason

l  Java

l  Jboss

l  Servlets

狀態

l  超過5500萬活動顧客帳號

l  世界范圍內超過100萬活動零售合作商

l  構建一個頁面所需訪問的服務介于100至150個之間

體系結構

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

l  Amazon的架構經歷了巨大的變化，從一開始時的兩層架構，轉向了分布式的、去中心化的服務平臺，提供許多種不同的應用。

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

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

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

l  他們的架構是松散耦合的的，并且圍繞著服務進行構建。面向服務的架構提供給他們的隔離特性，讓他們能夠快速、獨立地完成許多軟件組件的開發。

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

l  許多第三方的技術難以適用Amazon這種網站的規模，特別是通訊基礎架構技術。它們在一定范圍內工作的很好，但是如果范圍再擴大的話，它們就不適用了。因此，Amazon只好自己開發相應的基礎技術。

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

l  C++開發的程序被用來處理請求。Perl/Mason開發的程序用來生成頁面中的內容。

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

l  SOAP 相關的web解決方案看起來想再次解決所有分布式系統的問題。

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

l  無論采用SOAP還是REST，開發人員都可以得到訪問Amazon的對象接口。開發人員想要的是把工作完成，而不需要關心網線上傳輸的是什么東西。

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

l  架構開發團隊都是小規模團隊，而且都是圍繞不同的服務進行組織。

n  在Amazon服務是獨立的功能交付單元。這也是Amazon如何組織他的內部團隊的。

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

n  團隊都是小規模的。他們被授權可以采取他們所中意的任何方式來解決一個問題或者增強一個服務。

n  例如，他們創建了這樣一個團隊，其功能是在一本書中查找特有的文字和短語。這個團隊為那個功能創建了一個獨立的服務接口，而且有權做任何他們認為需要做的事情。

l  部署

n  他們創建了一個特殊的基礎設施，來完成對依賴性的管理和對完成服務的部署。

n  目標是讓所有正確的服務可以在一個主機中部署。所有的應用代碼、監控機制、許可證機制等都應該在一個“主機”中。

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

n  部署進程的輸出是一個虛擬機，你可以用EC2來運行他們。

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

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

n  強迫開發人員將關注點放在交付給客戶的價值上，而不是先考慮如何構建技術再考慮如何使用技術。

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

n  以最小化的設計來結束設計過程。如果想要構建一個很大的分布式系統，簡單性是關鍵。

l  對于大型可伸縮系統來說狀態管理是核心問題

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

n  并不是所有的操作是有狀態的。結賬的步驟是有狀態的。

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

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

l  Eric Brewers' CAP理論——或稱為系統的三個屬性

n  系統的三個屬性：一致性，可用性，網絡分區容忍度。

n  對于任何一個共享數據的系統都至少具備這三個屬性中的兩個。

n  網絡分區容忍度：把節點分割成一些小的分組，它們可以看到其他的分組但是無法看到其他全部節點。

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

n  可用性：并非總是可讀或者可寫。系統可能會告訴你無法寫入數據因為需要保持數據的一致性。

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

n  基于服務的需要來選擇特定的實現方法。

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

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

汲取的教訓

l  為了構建真正的可伸縮的系統，你必須改變你的想法或者心態。混沌方法在概率意義上可能工作的很好。在傳統的系統中我們展示的是一個完美的世界，沒有什么東西會出現問題、停止運轉，之后我們在這個完美的世界上構造復雜的算法。實際上，事情總是會出問題的，這就是你必須要接受的事實。例如，試著多想想如何快速完成服務器重啟和如何快速恢復數據。合適的分布數據和服務，你可能向100%無故障又邁進了一步。創建可自愈的（self-healing）、自組織的（self-organizing）系統架構。    

l  創建一個沒有分享的基礎架構。對于開發和部署來說，基礎架構也是共享資源，就像在邏輯層和數據層共享的資源一樣，你也會遭遇到出問題的時候。可能會導致鎖機制和屏蔽機制，并產生死鎖。一個面向服務的架構，允許采取并行和分離的開發流程，這樣可以使得功能特性的開發也具有“可伸縮性”，與系統的增長相匹配

l  將系統及其API同時開放，這樣你會圍繞著你的應用創建了一個生態系統。

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

l  圍繞服務進行組織可以提供敏捷性。你可以并行的做事情，因為輸出結果是一個服務。這使得縮短了產品和服務投放到市場去的時間。需要創建一個基礎架構來保證服務可以被很快的構建起來。

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

l  在內部使用服務品質協議（Service Level Agreement，簡稱SLA）來管理服務。

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

l  由于性能，可靠性和成本控制的原因，可能需要自己來構建基礎設施架構。自己構建這些基礎架構即便Amazon關門了也不必說是某某公司的錯誤導致的。自己構建的系統可能沒有其他的易用，不過相對使用第三方的東西來說，你可以更快地對自己構建的基礎架構進行修補、調試和部署。

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

l  創建一個節儉的環境。例如，Amazon就把門當桌子來用。

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

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

l  在創建產品的過程中，讓每個人都參與進來。在圣誕大采購來臨之時，去倉庫打包圖書吧，這樣才是團隊精神。

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

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

l  如果更新沒有成功的話，要有可以回滾到以前正常的狀態的運作方式。必要的話開發一個工具。

l  轉向更深入的基于服務的架構

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

l  要雇傭這樣的員工，他們有著驚人的調試技術和系統知識，最重要的是，他們可以在高度壓力的狀況下，應對非常棘手的問題。

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

l  創新精神必須無處不在。

l  任何人都應該有機會去嘗試，去學習，去實踐。職位的變遷，服從，傳統的習慣都不應該有多大的權利。創新的蓬勃發展，必須要有一套行之有效的考核辦法。

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

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

l  迅速擴張。像Barnes& Nobel這樣的大型對手緊跟在你的后面。Amazon曾經不是互聯網上最大的書店，不是第二名，甚至也不是第三名。但是他們的遠景規劃和執行方式最終讓他們笑到了最后。

l  在數據中心，員工花在解決基礎設施問題上面的時間只有30%是和利潤創造相關的。其他的70%的時間則是花在"繁重"的硬件采購、軟件管理、負載均衡、維護、應對增容挑戰等其他事情上。

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

l  創建統一的服務訪問機制。這使得服務易于集成，還可以完成請求路由去中心化、分布請求追蹤、以及其他一些高級的基礎架構技術。

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

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

l  不要在工程師身上強加過多的限制。為某些功能的完成提供一些激勵措施，比如與監控系統的集成，或者與其他基礎架構工具的集成等功能。但是對于其他的功能，要保證團隊的獨立性。

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

l  誰構建，誰運行。這讓開發人員與他們所開發的軟件的日常運營工作相聯系。也帶給他們與顧客之間的日常聯系。這種顧客反饋循環對于提升服務質量來說是至關重要的。

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

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

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

eBay的架構

文/Todd Hoff 譯/于曉潮

有誰不想知道eBay是如何開展業務的呢？成為世界上最大的高負荷量的網站之一，這個過程可不容易。創建這樣一個龐然大物，需要真正的工程學：在網站的穩定性、運轉速度、性能和成本之間達到一個平衡。

你可能無法模仿eBay增容系統的方法，但是其中的問題和可能的解決方案是值得我們學習借鑒的。

平臺

Ÿ   Java

Ÿ   Oracle

Ÿ   WebSphere

Ÿ   Horizontal Scaling

Ÿ   Sharding                                       

Ÿ   Mix of Windows and Unix

統計數據

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

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

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

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

Ÿ   數據庫虛擬化，涵蓋分布在100多個服務器集群中的600種產品實例。

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

架構

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

Ÿ   架構被嚴格分成：數據層、應用層、搜索、運行

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

Ÿ   Oracle數據庫，Websphere Java（1.3.1版本）

Ÿ   依照主訪問路徑、以及對一個主鍵的模數為界限，劃分數據庫

Ÿ   每個數據庫至少有三個在線數據庫，分布在8個數據中心。

Ÿ   一些數據庫備份在15分鐘、4個小時之后運行

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

Ÿ   不使用存儲過程，有一些非常簡單的觸發機制。   

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

Ÿ   沒有客戶端事務處理和分布式事務處理。

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

Ÿ   應用層中沒有狀態信息。狀態信息存在于cookie或者scratch數據庫中。

Ÿ   應用服務器之間沒有對話——采用嚴格的架構分層。

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

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

經驗總結：

Ÿ   減容，而不是擴容

——在每一層上平行增容

——功能分解

Ÿ   推薦異步整合

——最小化可用性耦合

——增加增容的選擇

Ÿ   虛擬組件

——降低物理依存

——提高配置彈性

Ÿ   應對故障的設計

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

——在商務特性中采用“失效保護模式”

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

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

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

Ÿ   隨著業務的成長，運行控制成為增容的越來越大的一部分。如果運行一個即時使用的系統，你必須考慮如何升級、配置和監視數以千計的機器。

Ÿ   架構進化——任何一個成長中的網站面臨的主要挑戰。在保持現有網站運行的同時，需要有改變、改善和開發新系統的能力。

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

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

YouTube網站架構

文/Todd Hoff譯/羅小平

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

平臺

l  Apache

l  Python

l  Linux (SuSe版本)

l  MySQL

l  psyco（python->C動態編譯器）

l  lighttpd（取代Apache作為視頻服務器）

統計數據

l  每天高達1億的視頻訪問量。

l  創建于2005年2月。

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

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

l  2個系統管理員，2個系統擴展架構師。

l  2個產品功能開發人員，2個網絡工程師，1個DBA。

性能監控手段

網站維護人員每天多次重復的工作，類似于執行下面這段代碼。

while (true)

{

identify_and_fix_bottlenecks();

drink();

sleep();

notice_new_bottleneck();

}

Web服務器

l  NetScalar用于實現負載均衡和對靜態內容的緩存。

l  Apache運行于mod_fast_cgi模式。

l  一臺Python應用服務器專門負責Web請求的路由。

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

l  通過增加服務器，一般就可以實現對Web層的擴展。

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

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

l  正常情況下，能將每個頁面的響應時間控制在100ms以內。

l  利用psyco（python->C的動態編譯器），通過JIT編譯方法實現內部循環的優化。

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

l  預生成某些HTML頁面并緩存。

l  在數據庫中實現行級緩存。

l  對Python結果對象緩存。

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

視頻服務

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

l  每段視頻均通過刀片群集（mini-cluster）服務器管理，也就是說由多個機器聯合提供視頻內容服務。

l  刀片群集管理的優勢：

n  多個磁盤提供內容服務，意味著更快的速度。

n  提供了動態余量。一臺機器停止服務，其他可以接管。

n  實現了在線備份。

l  使用lighttpd作為視頻的Web服務器：

n  Apache的成本太高。

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

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

l  將頻繁訪問的內容轉移到CDN（content delivery network）：

n  CDN將內容復制到多個源，因此對用戶來說，獲取數據時可以選擇最優路徑。

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

l  低訪問量的內容（每天1-20的訪問量），YouTube服務器以colo模式管理。

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

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

n  優化調整RAID控制器，在底層策略上下功夫。

n  調整每臺服務器上的內存，不要太大也不要太小。

視頻服務中的幾個關鍵點

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

l  網絡路徑保持最短，不要在內容和終端用戶間部署太多設備。路由器、交換機等可能承受不了這么高的負載。

l  盡量采用普通硬件。高檔硬件的支撐設備很昂貴，實際中往往發現它們的作用并不大。

l  使用簡單、通用的工具。YouTube優先考慮Linux自帶的大多數工具。

l  正確處理隨機尋道問題（采用SATA、優化調整等）。

視頻截圖的處理

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

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

l  縮略圖存儲在有限幾臺機器上。

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

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

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

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

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

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

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

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

n  重啟機器后，系統需要花費6-10小時，來將內容從磁盤載入緩存。

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

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

n  速度快；即使運行在不可靠網絡上，其錯誤率也是可以容忍的。

n  未知風險小，因為它使用了分布式的多級緩存。緩存工作于colo結構上。

數據庫[DSJ2] 

l  早期：

n  使用MySQL存儲用戶、標簽和詳細描述等原數據。

n  數據存儲在掛10磁盤、10卷的單片RAID上。

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

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

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

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

n  在這種以數據復制為中心的架構下，稍微提升寫性能，都必須付出巨大成本。

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

l  后來：

n  繼續執行數據庫分割策略。

n  按用戶劃分數據。

n  數據的讀、寫操作分離。

n  改進了緩存數據定位策略，減少I/O。

n  所需硬件減少了30%。

n  數據復制延遲降為0。

n  現在幾乎能做到對數據庫任意擴展。

數據中心策略

l  開始的時候使用托管機房。除非事先簽訂了協議，不能自行擴展硬件和網絡系統。因此，他們后來選擇了colo，可以完全按照自己的設計要求部署系統。

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

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

l  利用BigTable將圖片復制到各個數據中心。

經驗教訓

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

l  確定事情的優先級。找出服務中的關鍵部分，優先為其配置資源、投入力量。

l  學會選擇與合作。不要害怕將項目的關鍵部分外包。YouTube使用CDN向廣大用戶提供內容。如果完全依靠自己建設這樣一個網絡，需要花費的成本和時間都是驚人的。在你的系統中，應該可以存在這類同樣的部件。

l  一切從簡! 簡單，將保證系統具有良好的可重構性以及對問題的快速響應。沒有人真正知道怎么樣才算是簡單，如果在需要做出改變時，相關人員沒有產生畏難情緒，就說明達到了簡單的目標。

l  數據分割。數據分割策略將實現對磁盤、CPU、內存和IO實體和指標的優化配置，改善的不僅僅是寫數據的性能。

l  對瓶頸資源做持續改善：

n  軟件層：數據庫、緩存

n  操作系統層：磁盤I/O

n  硬件層：內存、RAID

l  團隊是成功的基礎。在一個有良好紀律的團隊中，所有成員都能夠準確把握整個系統，了解深層問題。擁有一個好的團隊，將無往而不勝。

Facebook 詳解

文/ wikipedia 譯/張雷

（Facebook在Palo Alto市的總部）

（Facebook創始人兼CEO Mark Zuckerberg）

（Facebook最初的Logo）

簡介

Facebook是一個社會化網絡站點。它于2004年2月4日上線。

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

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

網站的名字Facebook來自傳統的紙質“花名冊”。通常美國的大學和預科學校把這種印有學校社區所有成員的“花名冊”發放給新來的學生和教職員工，幫助大家認識學校的其他成員。

運營狀況

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

起步

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

2005

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

2006

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

2007

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

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

網站功能

墻（The Wall）

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

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

禮物（Gift）

（Facebook禮物）

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

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

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

市場（Marketplace）

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

捅（Pokes）

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

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

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

狀態（Status）

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

活動（Events）

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

開放平臺上的應用（Application）

2007年5月24日，Facebook推出Facebook 開放平臺。利用這個框架，第三方軟件開發者可以開發與Facebook核心功能集成的應用程序。

最流行的應用程序包括：

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

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

我喜歡：一個社會化音樂發現和分享服務，包括音樂會信息和有關音樂知識的小游戲

甚至有象棋、拼字游戲之類的游戲出現。而第三方網站如進行Facebook應用數據統計的Adonomics，相關博客如AppRate、Inside Facebook、Face Reviews等等或應運而生或對Facebook應用青眼有加。

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

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

截止2007年9月26日，共有超過4500個Facebook應用出現。

Facebook標識語言（Facebook Markup Language）

Facebook 標識語言是HTML的子集。Facebook應用的開發者可以用這種語言定制他們的應用程序的外觀。

Facebook視頻

與Facebook開放平臺同時推出的，還有一個Facebook自己開發的應用程序－－視頻分享。用戶可以上傳視頻、通過“Facebook移動”上傳手機視頻，以及用攝像頭錄像。同時用戶可以給視頻中的朋友加“標簽”。這一功能被認為會與MySpace的相關功能競爭。但Facebook的視頻只能在Facebook網絡內觀看。然而，一段發表在Userscripts.org上的Greasemonkey代碼讓用戶可以下載Facebook視頻或將之轉貼在其他網站。

Facebook的域模型

下圖用UML類圖的形式，顯示了Facebook系統所管理的信息。它提煉出了Facebook數據庫中的實體、關系、字段。

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

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