網絡流量

2010年初，Twitter團隊開始考慮將集群從第三方主機上遷出，這個決定和動作意味著Twitter團隊需要學習如何構建和運行內部的基礎設施，由于需要在有限的可視化情況下了解核心基礎設施需求，團隊開始調研各種網絡設計、硬件，以及供應商。

到2010年下半年，Twitter團隊完成了第一個網絡體系結構設計，解決了科羅拉多主機集群遇到的擴展性和服務問題。該方案有深度緩沖設計，支持對于突發的流量請求以及確保電信核心交換機在網絡層沒有超載。這個方案支撐了Twitter的早期版本，創造了一些比較出名的業績，例如打破了TPS數據記錄的“天空之城”事件（每秒處理34000條記錄）以及應對2014年世界杯。

此后的幾年時間里，Twitter的數據中心運行在五大洲的成千上萬的服務器，網絡覆蓋很廣。從2015年上半年開始，Twitter開始遭受到了成長過程中的痛苦，由于不斷變化服務系統架構和增加容量需求，最終達到了數據中心物理可擴展性的上線，網狀拓撲結構不再支持通過增加新的機架提升性能，即不再支持增加額外的硬件。另外，Twitter現有的數據中心開始由于不斷增加路由規模和復雜的網絡拓撲結構導致出現不穩定異常情況。

為了解決這個問題，Twitter開始將現有的數據中心轉換為Clos拓撲+BGP，這是一種必須在現場做的網絡轉換工作。盡管很復雜，但是Twitter在一個相對較短的時間內完成了這個轉換，并且對服務影響最小。網絡拓撲圖看起來是這樣的：

　　總結技術亮點如下：

單個設備故障具有較小的影響范圍。

水平帶寬縮放能力。

路由引擎較低的CPU開銷；路由更新更高效的處理能力。

由于較低的CPU開銷，更高的路由容量。

每個設備和鏈路上的更細粒度的路由策略控制。

不再重復發生之前的幾個已知問題：包括增加協議收斂時間、路線流失問題和伴隨固有的OSPF復雜性的不可預期問題。

啟用無影響機架遷移方案。

數據中心

Twitter的第一個數據中心是基于建模分析出的能力和已知系統的運行狀態經驗構建的。但是僅僅幾年之后，數據中心比最初的設計擴大了400%。現在，隨著Twitter應用程序堆棧的演變，Twitter正在變得更加分布式化，運行狀態也在跟著變化。引導Twitter進行網絡設計的最初假設場景已經不復存在了。

業務需求增長過快，導致針對整個數據中心進行重構已經不切實際。所以構建一個高可擴展的體系架構會讓Twitter更容易增加能力，而不是采用叉車式的遷移方案。

高可擴展性的微服務需要高可靠性網絡，可以支持處理各種業務。Twitter的業務范圍從TCP長連接到離線的MapReduce任務，再到超短連接。針對這類多樣性業務需求的應對方案是，部署具有深包緩沖區的網絡設備，但是這樣會帶來一系列問題：更高的成本和更好的硬件復雜度。之后的設計Twitter使用了更加標準化的緩沖區大小，以及在提供切斷開關功能的同時，提供了更好的TCP棧服務器，這樣可以更好的處理網絡風暴問題。

骨干網絡

Twitter的骨干網流量每年都有大幅度正常，并且仍然可以看到數據中心之間的突發數據增長較正常狀態的3-4倍情況存在。這種情況對于老的協議是一個特有的挑戰，這些老的協議，例如MPLSRSVP協議，從來不是為應對突然爆發的網絡風暴而設計的，它的目標是應對漸進式的緩慢的網絡請求增長。為了獲得盡可能快的響應時間，Twitter不得不花費大量的時間調整這些協議。此外，Twitter實現的優先次序可以處理網絡高峰（特別是存儲復制）情況。

Twitter需要確保在任何時候優先客戶的傳輸流量，可以通過延遲低優先級的存儲復制工作滿足這個需求，存儲復制這類工作有一天時間的SLA。這樣就可以使用最大量的網絡資源，讓數據盡可能快速地移動。客戶業務需求比低優先級的后臺業務需求優先級高。而且，為了解決伴隨著RSVP自動帶寬而來的bin-packing問題，Twitter實現了TE++，這個工具當流量增加時創建額外的LSP，當流量下降時則會刪除LSP。這使得Twitter可以有效地管理連接之間的網絡業務，同時減少維護大量的LSP所造成的CPU負擔。

然而主干網從最初開始就缺少任何業務工程設計，后來增加了幫助Twitter可以根據業務增長進行擴展的特性。為了實現這一點，Twitter完成了角色分離，使用單獨的路由器分別處理核心和邊緣路由請求。這也使得Twitter能夠低成本效益地擴展，而不需要購買復雜的帶邊緣功能的路由器。

在邊緣路由層，Twitter有一個核心連接所有網絡，并且可以支持水平擴展，例如每個站點有很多路由器，不止兩個，因為Twitter有一個核心層互聯所有的設備。

為什么擴展路由器的RIB（路由信息庫，即Routing InformationBase），Twitter引入了路由反射機制，這樣就可以適配擴展需求，但是在做這個的過程中，需要移植到變更設計，Twitter也做了路由反射的客戶端！

存儲設計

每天有數以百萬計的的推文（微博）被發送出來。這些推文需要被處理、存儲、緩存、服務以及分析。對于如此龐大的信息內容，Twitter需要一個穩定的基礎設施。存儲和消息占據了45%的Twitter的基礎設施空間。

存儲和消息團隊提供了如下服務：

用于運行計算和HDFS的Hadoop集群

用于所有的低延遲鍵值存儲的Manhattan集群

Graph用于存儲MySQL集群存儲分片

Blobstore集群用于所有的大型對象（視頻、圖片、二進制文件等等）

緩存集群

消息集群

關系型存儲（MySQL、PostgreSQL以及Vertica）

在這個規模的多租戶領域，Twitter遇到了一些困難，其中有一個是必須解決的問題。很多時候客戶有一些很奇怪的用例，這些用例實施后會影響其他租戶，這種案例帶來了專有集群設計。許多專有集群增加了運行的工作量用于保持程序運行。

Hadoop：Twitter有多個集群存儲了超過500PB的數據，這些數據被分為四組（實時數據、處理數據、數據倉庫，以及冷數據倉庫）。Twitter最大的集群有超過1萬個節點組成。該集群每天運行15萬個應用程序，啟動13億個容器。

Manhattan（Tweets、直接消息、Twitter賬號以及其他一些東西的后端）：Twitter運行了一些集群針對不同的用例，例如大型多租戶、小型的非常用功能、只讀的，以及針對重寫/重讀業務模式下的讀寫。只讀集群可以處理幾千萬QPS，而讀/寫集群可以處理百萬級的QPS。Twitter觀察到的性能最好的集群每天處理幾十萬的寫請求。

Graph：Gizzard/MySQL這樣的基于分片的集群用于存儲Twitter的圖片。這個集群可以管理頂峰時間段千萬級別的QPS，平均到每臺MySQL服務器大約3萬-4.5萬QPS。

Blobstore：Twitter的圖片、視頻，以及大型文件的存儲量已經達到了數以百億計。

Cache：Redis和Memcache集群，緩存Twiiter用戶、時間表、推文，以及其他一些內容。

SQL：包括MySQL、PostgreSQL和Vertica。MySQL/PosgreSQL被用于強一致性場景，就像內部工具一樣管理廣告活動、廣告切換。

Hadoop/HDFS也是日志管道的后端存儲，但是在過渡到Apache Flume的最后的測試階段，作為一種替換方案解決了選擇客戶端聚合時缺乏速率限制、缺乏傳遞類型保證等局限性，并且解決了內存奔潰問題。Twitter每天處理一兆條信息，并且所有的信息被處理后超過500個類別，然后有選擇地在所有集群內拷貝。

緩存設計

雖然緩存只占用基礎設施的3%，但是它確實對于Twitter很關鍵。緩存保護后端存儲層遠離業務風暴，允許存儲流動成本很高的對象。Twitter在巨型規模內使用了幾款緩存技術，例如Redis和Twemcache。更具體地說，Twitter有一個專用和多租戶混用的Memcached（twemcache）集群，以及夜鷹集群（分布式Redis）。Twitter也遷移了幾乎所有的主要的緩存到Mesos，以降低運行成本。

對于Cache來說，擴展性和性能是首要挑戰。Twitter運營了數個集群，總計每秒320M數據包的數據包速率，提供超過120GB/s的數據給客戶，Twitter的目標是即便在高峰段，也要確保每次響應的延遲約束在0.1%到0.01%之間。

為了滿足Twitter的高吞吐量和低延遲服務水平目標（SLO），Twitter需要持續測試系統性能，尋找更有效的優化方案。為了幫助內部做到這一點，Twitter寫了rpc-perf工具，更好地理解緩存系統是如何工作的。當Twitter嘗試從專有機器上遷移到現在的Mesos基礎設施時這個工具的作用就很重要了，幫助制定了容量規劃。這些優化努力的結果是Twitter在沒有延遲的基礎上每臺機器的吞吐量提升了一倍以上。Twitter仍然堅信存在很大的調優空間。

Twitter作為一家互聯網服務提供商，它在建設通信軟件服務時遇到的網絡問題、軟件系統架構問題、軟件技術選型等等都值得我們學習。Twitter發表的文章有助于讀者從整體理解互聯網軟件開發、發布、問題解決等整個體系結構相關知識，也幫助讀者從側面完成技術選型。