淺談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集群服務。
Webtier, chatlogger, presence，在公開的文章和PPT中并沒說這些集群具體怎么做分布和冗余備份的。
互聯網上的資料：
http://www.infoq.com/presentations/Scale-at-Facebook
Facebook前工程總監Aditya Agarwal在QCon London2010 上的演講。
http://www.infoq.com/presentations/Facebook-Software-Stack
Aditya Agarwal在 QCon SanFrancisco 2008上的演講，和QCon London 2010 上的沒什么區別...
http://www.infoq.com/presentations/Evolution-of-Code-Design-at-Facebook
Facebook工程師Nick Schrock在QCon London2011上介紹它們是怎么寫代碼的。
http://www.infoq.com/presentations/Infrastructure-at-Facebook
Facebook的基礎平臺(Infrastructure)團隊經理Jason Sobel在QCon San Francisco 2010上的演講。
http://www.youtube.com/watch?v=T-Xr_PJdNmQ&feature=player_embedded
Velocity 2010: Tom Cook, "A Day in theLife of Facebook Operations"
http://www.erlang-factory.com/upload/presentations/31/EugeneLetuchy-ErlangatFacebook.pdf
留言列表
