1. 程式人生 > >淺談facebook伺服器架構

淺談facebook伺服器架構

大體層次劃分

Facebook的架構可以從不同角度來換分層次。

一種是:一邊是PHP整的經典的LAMP stack;另外一個是非PHP整的各種service。

lamp services

Facebook的頁面從剛創立的時候扎克伯格寫的,到現在,都用PHP開發。後端有用各種語言開發的service。它們之間用跨語言的thrift RPC通訊(Scribe也是建立在Thrift之上)。

另外一個角度劃分的層次是:

layers

前面是負載局衡器(沒說是用硬體的還是軟體的);負責分配 前端的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)。

write

讀:

另一個人Alice開啟Facebook,載入主頁,PHP程式向Aggregator伺服器查詢(Thrift呼叫),Aggregator從若干個Leaf Server裡頭讀出Alice的朋友的所有行為動態/action的前四十個,aggregator做聚合和一定的排序,返回給PHP程式。

read 1

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中並沒說這些叢集具體怎麼做分佈和冗餘備份的。