淺談Facebook的伺服器架構
http://blog.csdn.net/yanghehong/archive/2011/06/09/6534452.aspx
大體層次劃分
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中並沒說這些集群具體怎麼做分佈和冗餘備份的。
互聯網上的資料：
http://www.infoq.com/presentations/Scale-at-Facebook
Facebook前工程總監Aditya Agarwal在QCon London 2010 上的演講。
http://www.infoq.com/presentations/Facebook-Software-Stack
Aditya Agarwal在 QCon San Francisco 2008上的演講，和QCon London 2010 上的沒什麼區別…
http://www.infoq.com/presentations/Evolution-of-Code-Design-at-Facebook
Facebook工程師Nick Schrock在QCon London 2011上介紹它們是怎麼寫代碼的。
http://www.infoq.com/presentations/Infrastructure-at-Facebook
Facebook的基礎平臺(Infrastructure )團隊經理Jason Sobel在QCon San Francisco 2010上的演講
Velocity 2010: Tom Cook, "A Day in the Life of Facebook Operations"
http://www.erlang-factory.com/upload/presentations/31/EugeneLetuchy-ErlangatFacebook.pdf
http://www.facebook.com/note.php?note_id=14218138919
