根據近期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架構中，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是一個“巨大的運營成就”，這允許了對架構配置的編纂整理，并使得規劃部署成為可能。規劃部署用于維持緩存命中率，并避免導致持久化存儲層故障的問題。 根據用戶、推文、時間線等對緩存做邏輯分區，通常每個緩存集群都根據特定的用途做了優化。考慮到整個公司內有100多名Puppet提交者，對內部和社區最佳實踐的文檔工作已經成為“力量倍增器”。 歸一的參考文檔改進了代碼交付的質量和速度。 當任務單和交流通道不足以滿足交流的需要，或是不能表述要完成的工作整體情況時，需要保持正常的辦公時間，這樣員工可以提請援助（有時需要邀請），可進行一對一的交流。查看英文原文：The Infrastructure Behind Twitter: Scaling Networking, Storage and Provisioning
京公網安備 11010502049343號