淺談facebook的服務器架構
大體層次劃分
Facebook的架構可以從不同角度來換分層次。
一種是：一邊是PHP整的經典的LAMP stack；另外一個是非PHP整的各種service。
Facebook的頁面從剛創立的時候扎克伯格寫的，到現在，都用PHP開發。後端有用各種語言開發的service。它們之間用跨語言的thrift RPC通信(Scribe也是建立在Thrift之上)。
另外一個角度劃分的層次是：
前面是負載局衡器(沒說是用硬件的還是軟件的)；負責分配 前端的Web服務器， Web服務器是用PHP來聚合數據；最後面是 Services，Memcached和數據庫。
有意思的是對後面三種的定性：
Services – 快速，複雜； 自己開發的業務進程，來實現複雜的業務邏輯，速度快。
Memchached – 快速，簡單；Memchached做簡單的key-value緩存，服務應用快速的讀請求。
數據庫 – 緩慢，持久。數據庫做持久存儲，磁盤IO自然慢，不過有memcached做緩存沒關係。
NewsFeed的架構
寫：
Bob更新狀態，Web服務器上的PHP程序除了將內容到MySQL數據庫之外，也將該行爲動態的ID通過Scribe發到一個Leaf Server上(根據Bob的用戶ID選的Leaf Server)。
讀：
另一個人Alice打開Facebook，加載主頁，PHP程序向Aggregator服務器查詢(Thrift調用)，Aggregator從若干個Leaf Server裏頭讀出Alice的朋友的所有行爲動態/action的前四十個，aggregator做聚合和一定的排序，返回給PHP程序。
PHP程序獲得這些行爲動態的ID之後，從Memcached中讀出這些ID對應的內容，如Memcached沒有則從MySQL數據庫中讀，匯聚後生成HTML返回給瀏覽器。
Chat的架構
頁面請求，仍WEB服務器處理(PHP)處理，當然也依賴web tier之後的各種Service。比如查看消息歷史啊，在線用戶列表啊，發送聊天消息啊。
接收聊天消息，則沒通過PHP服務器，而是專用的用Erlang寫的Channel服務器來處理，通過long-polling來接收聊天消息。Channel服務器是Chat服務的核心部件。發送的消息通過web tier發到Channel服務器。
後方有用C++寫的chatlogger服務器來做歷史記錄的讀寫。
同樣也用C++寫了presence服務器來從channel服務器彙集在線狀態。
系統的簡化結構如下圖所示：
Web tier, chatlogger, presence, channel 都是多個服務器組成的集羣。
Channel服務器有根據User ID做分區，每個分區由一個高可用的Channel集羣服務。
Web tier, chatlogger, presence，在公開的文章和PPT中並沒說這些集羣具體怎麼做分佈和冗餘備份的。