【轉】構建可擴充的微博架構(qcon beijing 2010演講) by Tim Yang

標籤：

在使用Twitter幾年的時間裡面，經常思考微博如何更好的實現，恰好最近幾個月也參與了相關工作，大部分都是工程實踐，總結實踐會促生更具實際價值的理論。因此在QCon Beijing 2010這次演講參考了不少網友的意見後選擇了《構建可擴充微博架構》的題目。  
由於在決定選題時知道來自Twitter總部有30萬followers的@nk也會講一個類似的題目，心中當時有點忐忑，最大的顧慮就是要講的領域更他重疊，如果他講得更深入，我就沒必要班門弄斧了。後來考慮到以下幾個原因還是決定繼續

• Twitter架構是單IDC設計，從它遞增的tweet id就可以看出，後來當面向@nk提問也得到了證實。

• 中美網路環境差異，單IDC和多IDC有很多設計上的不同

• 大部分參會人員未必能對英文演講有深入理解及感悟，中文的演講可以講一些細節解釋更透徹。

• Twitter對故障的容忍度大，國內公司對服務故障通常更敏感。因此國內架構師會考慮設計方案盡量簡單可靠，服務需要更穩定。國外Team Dev更傾向追求在工作中應用技術創新，因此會導致架構設計理念的不少差異。

演講的slide如下，登入slideshare之後可以下載。

Build scalable microblog qcon beijing 2010

View more presentations from Tim Y.

這裡再補充在qcon演講未來得及考慮成熟的一個方面，使用者規模影響設計，具體是指使用者數每上一個數量級，許多設計需要重新考慮。

10萬使用者層級

• 單伺服器，前端、後端、cache、db在一起。

百萬級

• db和cache單獨部署伺服器，db或按業務進行拆分(sharding)

• cache或使用一致性hash擴充。

• 前端後端還是在一起，但是根據業務拆分，每個業務可分配不同數量的伺服器

千萬級

• 開始重視架構設計，有專門技術架構師

• 需跨機房部署，前端在遠程增加反向 Proxy加速，資料庫在異地機房使用slave資料庫副本

• 後端拆分出來，系統內部需要遠程調用，內部需遠程調用協議。

億級

• 架構更細分，或增加資料架構師，cache架構師，分布式架構師

• 資料庫sharding碰到煩惱，開始考慮分布式資料服務

• 資料訪問需要根據業務特點細分。

• 開發、營運、測量、調優具備有自己的專有工具。

• 所有服務需要地理多機房分布，具備IDC容災設計。

• 服務可降級

上面的數字僅供理解“使用者規模影響設計”，數字本身並無具體指導價值。

【轉】構建可擴充的微博架構(qcon beijing 2010演講) by Tim Yang