設計原則
1儘可能的使用開源軟件，並且在需要優化的時候進行優化
2Unix 哲學。包括，模塊化原則；整合化原則；清晰化原則等
3任何組件具備擴展性
4最小化故障影響
5簡化，簡化，簡化！
架構概覽
Facebook 是 LAMP 的堅定支持者，也差不多是用 LAMP （或許用 LAM2P 更適合） 實現的最大的動態站點。
基礎組件加上服務，中間用自己實現的一些工具進行粘合。其中關於運維細節的事情基本不會說出來的，這是很多公司的軟實力所在。
PHP 經驗
參見《Facebook 的 PHP 性能與擴展性》
MySQL 經驗
1主要用於做 Key-Value 類型的存儲操作，數據隨機分佈在多臺邏輯實例上，訪問多數基於全局 ID 。
2邏輯實例分散在多臺物理主機上（超過1800臺），負載均衡在物理層進行。
3不做讀複製。
4儘量不做邏輯數據遷移（成本太高）。
5不做 JOIN 操作 （豆瓣在 QCon 上也闡述了這一點）。數據是隨機分佈的，關聯操作反而帶來了極大的複雜度。
6對於數據訪問，主要的操作集中在最新的數據上，針對這部分做優化，舊的數據進行歸檔。
7在中心 DB 絕不存儲非靜態數據。
8使用服務或者 Memcached 進行全局查詢。
Memcached 經驗
參見我以前的筆記：Facebook 的 Memcached 擴展經驗。Facebook 對 Memcached 做了不小的改進。另外，順便說一下，前兩天 Memcached 剛在 1.2.7 發佈幾天之後又發佈了新版本 1.2.8，修正了一些問題。
一個比較有價值的是關於個人頁面數據的獲取的描述。這個就完全是需要做單頁面 Benchmark 的細緻活兒了，可能還需要產品經理能夠理解工程師的“抵抗”。
1獲取個人信息數據：通過Cache，隱性通過用戶所在的 DB 獲取（基於 User-ID 獲知 DB）
2獲取朋友連接信息：通過Cache，否則的話通過DB（基於 User-ID 獲知 DB）
3並行抓取每個朋友的 10個照片相冊 ID ，從Cache抓取，如果失效，再從 DB 抓取（基於相冊 ID）
4並行抓取最近相冊中的照片數據
5運行PHP 把整個業務邏輯跑出來
6返回數據給用戶
然後是對 Facebook 非 LAMP 體系的東西做了一番介紹，基本上也開源了。最後參考兩個架構圖。
Facebook NewsFeed 的架構示意圖
Facebook 搜索功能的架構示意圖
