Twitter的支撐架構：擴展網絡與存儲並提供服務——架構原則：一次性將事情作對，NFL原則 LSM+B+存儲替代cassandra

Twitter工程團隊近期提供了Twitter核心技術的演進和擴展的詳細資料，這些核心技術支撐了Twitter自營數據中心的系統架構，用於提供社會媒體服務。他們分享的關鍵經驗包括：超越原始規格和需求進行系統架構，並在流量趨向設計容量上限時迅速作出大刀闊斧的改進；不存在所謂的「臨時更改或變通方案」，由於變通方案會成爲技術債務；聚焦於爲任務提供適合的工具，但這意味合理領會全部可能的用例；對內部的和社區最佳實踐的文檔工做已成爲一種「力量倍增器」。

根據近期Twitter工程博客上的一篇博文，Twitter做爲社會網絡和在線新聞服務建立於2006年，在那個時期，「統治數據中心」的是企業級實體廠商所提供的硬件。在Twitter運行的頭十年中，快速增加的用戶羣已對硬件層提出了不少工程上的挑戰。雖然Twitter在公共雲上「運行良好」，可是他們已經開始重點投資自身的私營架構。至2010年，Twitter已從第三方的主機託管服務遷移到自身私營的數據中心架構，該數據中心架構在隨後六年中「持續地設計和更新……有效地利用了技術和硬件的最新開放標準」。

至2010底，Twitter最終完成了首個內部網絡架構，從設計上解決了在第三方主機託管架構中所遇到的擴展性和服務問題。最初，深度緩衝（Deep Buffer）機櫃頂部（ToR，Top of Rack）交換機和電信級核心網絡交換機的使用，使Twitter支持了2014年世界盃這樣的全球事件所產生的史無前例的每秒交易（TPS，Transaction Per Second）量。在隨後數年中，Twitter架構團隊在五大洲部署了網絡服務提供點 （PoPs，point-of-presence）。2015年，Twitter從傳統的層次數據中心網絡拓撲結構遷移到使用邊界網關協議（BGP，Border Gateway Protocol）路由的Clos網絡。Clos方法的顯著優勢包括：更小的設備單點故障的「波及範圍」、更好的水平帶寬擴展能力，以及由更低的CPU開銷致使的更高路由性能。

在Twitter網絡架構擴展的過程當中，Twitter的工程團隊汲取到一些重要的經驗教訓：

• 超越原始規格和需求進行系統架構，並在流量趨向設計容量上限時迅速作出大刀闊斧的改進。
• 根據數據和指標作出正確的技術設計決策，並確保這些指標可被網絡操做人員理解。這對於託管主機和雲環境是尤其重要的。
• 並不存在所謂的「臨時更改或變通方案」的東西。在不少狀況下，變通方案會成爲技術債務。

在Twitter架構中，45%的規模用於存儲和消息。架構團隊爲內部用戶提供了多種服務，包括：Hadoop集羣、Twitter的Manhattan （Apache Cassandra-esque）分佈式數據庫集羣、FlockDB圖存儲集羣（使用了Gizzard和共享MySQL）、Blobstore集羣、Twemcache及「Nighthawk」共享Redis緩存集羣、DistributedLog消息集羣（用於Heron的處理）以及關係存儲（MySQL、PostgreSQL和Vertica）。在2010年曾使用Cassandra做爲度量數據存儲的解決方案，可是在2015年4月啓用Manhattan後，就禁用了Cassandra。

幾乎所有的Twitter主緩存已從「裸機」遷移到大規模部署的開源集羣管理系統Apache Mesos上（Twitter也是Mesos代碼庫的主要貢獻者之一）。推文的時間線緩存Haplo是還沒有部署到Mesos的最重要組件。Haplo使用定製版的Redis實現。對於該緩存，最嚴峻的挑戰在於可擴展性和性能，由於Twitter運行上百個集羣，合計包速率可達3.2億包/每秒，每秒爲客戶提供120GB的內容。爲達到高吞吐量和低延遲的服務水平目標（SLO，Service Level Objective），工程師要持續測量系統的性能，尋找優化效率的方法。例如，Twitter工程師建立了一個測試緩存性能的開源工具rpc-perf，使用它能夠更好地瞭解各類負載場景下緩存系統的運行狀況。

存儲和緩存實現中的主要經驗教訓包括：

• 爲更好地處理特定的流量模式，Twitter的Manhattan分佈式數據庫中採用了額外的存儲引擎（LSM，B+樹等）。經過發送背壓信號並容許查詢過濾，防止了對存儲層的濫用。
• 聚焦於爲任務提供適合的工具，這意味合理領會全部可能的用例。「適合各類場景」的解決方案是不多起做用的。對個別極端案例的處理採用臨時解決方案便可，無需過多考慮如何能省時省力。
• 遷移到Mesos對於Twitter是一個「巨大的運營成就」，這容許了對架構配置的編纂整理，並使得規劃部署成爲可能。規劃部署用於維持緩存命中率，並避免致使持久化存儲層故障的問題。
• 根據用戶、推文、時間線等對緩存作邏輯分區，一般每一個緩存集羣都根據特定的用途作了優化。

Twitter使用Puppet實現全部的系統配置管理和kickstart後的軟件包安裝，Puppet的代碼有500多個模塊，1000多個角色，每月都有100多位提交者。Puppet有三個被其稱爲環境的分支，分別容許實現受控測試、金絲雀測試（Canarying）以及最終推進變動到生產環節。對於不斷增加中的Pupper代碼庫，到目前爲止影響最大的更改是代碼查錯（Code Linting）、代碼模式檢查鉤（Style Check Hook）、最佳實踐的文檔化以及正常辦公時間保持：

• 考慮到整個公司內有100多名Puppet提交者，對內部和社區最佳實踐的文檔工做已經成爲「力量倍增器」。
• 歸一的參考文檔改進了代碼交付的質量和速度。
• 當任務單和交流通道不足以知足交流的須要，或是不能表述要完成的工做總體狀況時，須要保持正常的辦公時間，這樣員工能夠提請援助（有時須要邀請），可進行一對一的交流。

更多擴展Twitter平臺架構的相關信息，參見Twitter工程博客帖子「Twitter後臺架構：擴展」。前期補充的博客帖子「Twitter後臺架構：效率和優化」內容聚焦於Twitter私有平臺即服務（PaaS）的演進。