Twitter工程團(tuán)隊近期提供了Twitter核心技術(shù)的演進(jìn)和擴(kuò)展的詳細(xì)資料，這些核心技術(shù)支撐了Twitter自營數(shù)據(jù)中心的系統(tǒng)架構(gòu)，用于提供社會媒體服務(wù)。他們分享的關(guān)鍵經(jīng)驗包括：超越原始規(guī)格和需求進(jìn)行系統(tǒng)架構(gòu)，并在流量趨向設(shè)計容量上限時迅速做出大刀闊斧的改進(jìn)；不存在所謂的“臨時更改或變通方案”，因為變通方案會成為技術(shù)債務(wù)；聚焦于為任務(wù)提供適合的工具，但這意味合理領(lǐng)會所有可能的用例；對內(nèi)部的和社區(qū)最佳實踐的文檔工作已成為一種“力量倍增器”。
根據(jù)近期Twitter工程博客上的一篇博文，Twitter作為社會網(wǎng)絡(luò)和在線新聞服務(wù)創(chuàng)建于2006年，在那個時期，“統(tǒng)治數(shù)據(jù)中心”的是企業(yè)級實體廠商所提供的硬件。在Twitter運行的頭十年中，快速增長的用戶群已對硬件層提出了很多工程上的挑戰(zhàn)。雖然Twitter在公共云上“運行良好”，但是他們已經(jīng)開始重點投資自身的私營架構(gòu)。至2010年，Twitter已從第三方的主機(jī)托管服務(wù)遷移到自身私營的數(shù)據(jù)中心架構(gòu)，該數(shù)據(jù)中心架構(gòu)在隨后六年中“持續(xù)地設(shè)計和更新……有效地利用了技術(shù)和硬件的最新開放標(biāo)準(zhǔn)”。
至2010底，Twitter最終完成了首個內(nèi)部網(wǎng)絡(luò)架構(gòu)，從設(shè)計上解決了在第三方主機(jī)托管架構(gòu)中所遇到的擴(kuò)展性和服務(wù)問題。最初，深度緩沖（Deep Buffer）機(jī)柜頂部（ToR，Top of Rack）交換機(jī)和電信級核心網(wǎng)絡(luò)交換機(jī)的使用，使Twitter支持了2014年世界杯這樣的全球事件所產(chǎn)生的前所未有的每秒交易（TPS，Transaction Per Second）量。在隨后數(shù)年中，Twitter架構(gòu)團(tuán)隊在五大洲部署了網(wǎng)絡(luò)服務(wù)提供點 （PoPs，point-of-presence）。2015年，Twitter從傳統(tǒng)的層次數(shù)據(jù)中心網(wǎng)絡(luò)拓?fù)浣Y(jié)構(gòu)遷移到使用邊界網(wǎng)關(guān)協(xié)議（BGP，Border Gateway Protocol）路由的Clos網(wǎng)絡(luò)。Clos方法的顯著優(yōu)點包括：更小的設(shè)備單點故障的“波及范圍”、更好的水平帶寬擴(kuò)展能力，以及由更低的CPU開銷導(dǎo)致的更高路由性能。
在Twitter網(wǎng)絡(luò)架構(gòu)擴(kuò)展的過程中，Twitter的工程團(tuán)隊汲取到一些重要的經(jīng)驗教訓(xùn)：
- 超越原始規(guī)格和需求進(jìn)行系統(tǒng)架構(gòu)，并在流量趨向設(shè)計容量上限時迅速做出大刀闊斧的改進(jìn)。
- 根據(jù)數(shù)據(jù)和指標(biāo)做出正確的技術(shù)設(shè)計決策，并確保這些指標(biāo)可被網(wǎng)絡(luò)操作人員理解。這對于托管主機(jī)和云環(huán)境是尤為重要的。
- 并不存在所謂的“臨時更改或變通方案”的東西。在很多情況下，變通方案會成為技術(shù)債務(wù)。
在Twitter架構(gòu)中，45%的規(guī)模用于存儲和消息。架構(gòu)團(tuán)隊為內(nèi)部用戶提供了多種服務(wù)，包括：Hadoop集群、Twitter的Manhattan （Apache Cassandra-esque）分布式數(shù)據(jù)庫集群、FlockDB圖存儲集群（使用了Gizzard和共享MySQL）、Blobstore集群、Twemcache及“Nighthawk”共享Redis緩存集群、DistributedLog消息集群（用于Heron的處理）以及關(guān)系存儲（MySQL、PostgreSQL和Vertica）。在2010年曾使用Cassandra作為度量數(shù)據(jù)存儲的解決方案，但是在2015年4月啟用Manhattan后，就禁用了Cassandra。
幾乎全部的Twitter主緩存已從“裸機(jī)”遷移到大規(guī)模部署的開源集群管理系統(tǒng)Apache Mesos上（Twitter也是Mesos代碼庫的主要貢獻(xiàn)者之一）。推文的時間線緩存Haplo是尚未部署到Mesos的最重要組件。Haplo使用定制版的Redis實現(xiàn)。對于該緩存，最嚴(yán)峻的挑戰(zhàn)在于可擴(kuò)展性和性能，因為Twitter運行上百個集群，合計包速率可達(dá)3.2億包/每秒，每秒為客戶提供120GB的內(nèi)容。為達(dá)到高吞吐量和低延遲的服務(wù)水平目標(biāo)（SLO，Service Level Objective），工程師要持續(xù)測量系統(tǒng)的性能，尋找優(yōu)化效率的方法。例如，Twitter工程師創(chuàng)建了一個測試緩存性能的開源工具rpc-perf，使用它可以更好地了解各種負(fù)載場景下緩存系統(tǒng)的運行情況。
存儲和緩存實現(xiàn)中的主要經(jīng)驗教訓(xùn)包括：
- 為更好地處理特定的流量模式，Twitter的Manhattan分布式數(shù)據(jù)庫中采用了額外的存儲引擎（LSM，B+樹等）。通過發(fā)送背壓信號并允許查詢過濾，防止了對存儲層的濫用。
- 聚焦于為任務(wù)提供適合的工具，這意味合理領(lǐng)會所有可能的用例。“適合各種場景”的解決方案是很少起作用的。對個別極端案例的處理采用臨時解決方案即可，無需過多考慮如何能省時省力。
- 遷移到Mesos對于Twitter是一個“巨大的運營成就”，這允許了對架構(gòu)配置的編纂整理，并使得規(guī)劃部署成為可能。規(guī)劃部署用于維持緩存命中率，并避免導(dǎo)致持久化存儲層故障的問題。