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

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

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

• 中美網絡環境差別，單IDC和多IDC有不少設計上的不一樣

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

• Twitter對故障的容忍度大，國內公司對服務故障一般更敏感。所以國內架構師會考慮設計方案儘可能簡單可靠，服務須要更穩定。國外開發團隊更傾向追求在工做中應用技術創新，所以會致使架構設計理念的很多差別。

演講的slide以下，登陸slideshare以後能夠下載。

Build scalable microblog qcon beijing 2010

View more presentations from Tim Y.

這裏再補充在qcon演講將來得及考慮成熟的一個方面，用戶規模影響設計，具體是指用戶數每上一個數量級，許多設計須要從新考慮。

10萬用戶級別

• 單服務器，前端、後端、cache、db在一塊兒。

百萬級

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

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

• 前端後端仍是在一塊兒，可是根據業務拆分，每一個業務可分配不一樣數量的服務器

千萬級

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

• 需跨機房部署，前端在遠程增長反向代理加速，數據庫在異地機房使用slave數據庫副本

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

億級

• 架構更細分，或增長數據架構師，cache架構師，分佈式架構師

• 數據庫sharding碰到煩惱，開始考慮分佈式數據服務

• 數據訪問須要根據業務特色細分。

• 開發、運維、測量、調優具有有本身的專有工具。

• 全部服務須要地理多機房分佈，具有IDC容災設計。

• 服務可降級

上面的數字僅供理解「用戶規模影響設計」，數字自己並沒有具體指導價值。