矽谷之路7：Twitter架構進化之路

設計Twitter的方法論是什麼？

當我們面對一個很大的難題時，我們可以試著將這個大難題切分成小的、可以解決的子問題，然後解決它，這就是divide & conquer的思想。程序員的牛逼之處就在於懂得如何切分大難題。

首先我們觀看一下twitter最初的架構，非常的簡單：前端用一大坨Ruby代碼負責業務邏輯，後端用MySQL資料庫提供支持。

不要小瞧這個架構，這個簡單的架構在初期其實是能滿足需求的，但是隨著twitter的成長，很多困難顯現了出來：首先MySQL很難拓展，因為數據被分成各種關係存在資料庫里，每次查詢都需要進行join操作，而當數據太多被存在不同的機器上時，join會帶來很多麻煩。另外每台伺服器都運行著同樣的代碼，隨著服務不斷升級，部署新的任務要部署在所有機器上，這樣會耗費很多時間。還有因為架構過於簡單混沌，機器性能很差。

t所以現在我們面對的大難題就是如何scale這個系統，讓我們來庖丁解牛將這個問題細分。第一刀先將存儲切開，把整個資料庫切分成不用的存儲單元（Tweets Services, Users Services, Timelines Services, Social Graph Services），適合用MySQL的部分可以用MySQL存儲，不適合的用別的資料庫存儲。第二刀將路由、展示和邏輯切開，路由對請求進行分發，展示層提供Web服務和API等功能，邏輯層處理邏輯關聯。

我們用一個具體的例子來講這個架構。假設Lady Gaga發了一條twitter，會發生什麼呢？

首先Lady Gaga通過write API寫了推文，伺服器收到推文後要將這條推文（timeline）發送給所有訂閱Lady Gaga的粉絲。twitter使用的是fanout模型，每個用戶都有一個收件箱，伺服器會將這條推文ID發到所有關注Lady Gaga的人的收件箱里，這不是一個小數目，Lady Gaga有四百萬粉絲，這條tweet會發送到四百萬收件箱里，驚不驚人！所以twitter想了很多辦法來加快這個過程。

t首先timeline是存儲在redis資料庫里的，我們知道redis是基於內存的資料庫，查找起來十分迅猛。當粉絲查看推文時，會調用timeline服務，timeline會從redis里查找相應的timeline呈現給用戶。搜索是通過Earlybird這個模塊，對推文建立索引來實現的。彈出提示有新tweet這個功能是當有了新推文之後，使用HTTP Push這個Rest API來實現的。

如何搭建這樣的服務？大家感興趣的話可以去看一看Twitter-server這個開源庫。

開源項目twitter

• 配置服務

• 管理服務

• 日誌服務

• 生命周期服務

• 監控服務

各個服務之間如何交流？開源項目Finagle

• 服務發現

• 負載均衡

• 重試

• 線程池/鏈接池

• 統計收集

• 分布調試