記得剛接觸宮崎駿老爺子的作品是在高中時代，然而當時正值青春年少外加深受灌籃高手等動畫“荼毒”，對宮老爺子的《千與千尋》、《龍貓》、《魔女宅急便》、《天空之城》之流也就完全不感冒了。再次接觸宮老爺子的動畫則是在大學期間，記得當時熬了N個通宵把全集都過了好幾遍，不得不感慨作品只有在相應的情景下才能釋放價值。從這個觀點上看，近日網上流傳的“宮老爺子還能再戰十年!”也并不為過。

NTV電視臺于2013年8月2日晚第14次重播了《天空之城》，當劇情發展到男女主角巴魯和希達共同念出毀滅之咒“Blase”時，一舉將tweet發送峰值帶到了每秒143199次，這個峰值高于2013日本新年33388次/秒，也高于拉登之死(5106次/秒)、東日本大地震(5530次/秒)、美國流行天后碧昂斯宣布懷孕(8868次/秒)。

毀滅之咒“Blase”摧毀了天空之城，同樣也摧毀了經過充分準備的2ch，然而卻鑄就了當下Twitter的***峰值。新的峰值是平均值(5700TPS)的25倍，當下用戶平均每天發送的tweet是500萬條左右。在峰值期間，Twitter一直保持著高可用性，對比3年前世界杯上的表現無疑有著天壤之別。近日Twitter在技術博客上公布了為什么會重鑄Twitter以及新系統打造的相關細節，以下為譯文：

重鑄Twitter決心

當2010年人們將Twitter作為世界杯體驗實時分享工具時，每一腳射門、每一次罰球、以及裁判出示的每一張紅牌或黃牌產生的tweet都會對系統造成不同程度的影響，同時也會造成程序短時間內的不可用。2010世界杯期間，工程師日以繼夜的工作，拼命的改善系統性能。不幸的是，這樣的努力瞬間被Twitter的快速增長淹沒。

有過這次經歷，我們清楚了只有重新架構才能匹配網站的增長，同時讓系統變得更加可靠。隨后我們就開啟了漫漫的重構之路，而當下Twitter已經可以從容應對類似《天空之城》重播、超級碗以及全球新年夜慶典這樣的事件，新的架構不僅能彈性的應對負載，還可以幫助工程團隊快速發布新特性，包括了跨設備的消息同步，Twitter cards可以讓服務變得更加的豐富并擁有更多的內容，同樣還帶來了囊括用戶和故事的搜索體驗。為了實現這些，我們甚至改變了工程組織，下面就來一睹服務打造細節：

三年磨劍鑄輝煌

重新架構

在2010世界杯塵埃落定后，我們審視了整個系統，并發現眾多需要從根本上改善的地方：

1. Twitter曾運行著世界上***的RoR堆棧，并將這個技術推到了一個絕對高度：那個時候，大約200個工程師在為之奮斗，它確實讓Twitter渡過了一個用戶爆發性時期，不管是新用戶的增加，還是負載增加的處理。這個系統一度支撐了所有運作，從管理數據庫、memcache連接到網站的渲染及公共API的呈現，這些全部包含在一個代碼庫里。它不僅讓工程師的整合變的困難，同樣也困擾了工程團隊的管理及并行作業。

2. 存儲系統的吞吐量達到了極限——之前Twitter使用的是純粹的MySQL存儲系統，進行分片，同時系統只有一個主節點。然而從系統展示的速度上來看，tweet的吞吐率確實出現了問題。這樣我們就必須重建一個新的數據庫以應對增長率，因為熱門數據的讀取已越來越頻繁。

3. 取代從工程方面徹底的解決問題，我們曾嘗試過投入更多主機;然而隨后就發現，前端Rbuy主機并不能處理預期(根據性能)的事務量——從以往的經驗看，這些主機完全可以勝任更多的事務。

4. ***，從軟件角度上看，我們發現我們一直在鉆優化這個牛角尖，我們開始在性能和效率與代碼庫的可讀性和靈活性之間做權衡。

綜上所述，系統的重新架構已迫在眉睫，我們給自己定下了3個目標和挑戰：

1. 我們希望打造出兼具性能、效率及靈活性的大型基礎設施——我們希望能改善Twitter上的平均延時，同樣我們希望通過離群值給Twitter帶來統一的體驗。我們希望將賴以運行的服務器降到十分之一。我們希望對故障進行隔離以避免大規模宕機——隨著服務器規模的日益增大，這點就尤為重要，因為集群的變大意味著主機故障將愈來愈頻繁。故障是不可避免的，所以我們希望它們發生在一個更容易控制的模式下。

2. 我們希望通過將相關的代碼放到一起，以獲得更清晰的邊緣——我們已經感受了整片代碼所帶來的困擾，所以我們打造一個松耦合、基于服務的架構。我們目標是封裝和模塊化的***實踐，當然是在系統級，而不是類、模塊或者是包一級。

3. 最重要的是，我們希望能更快的發布特性。我們希望團隊能并行的運作，每一個小組都可以在不依賴其它小組的情況下獨立的完成局部決策，并將特性發布給用戶。

我們POC了新的架構，雖然不是所有的努力最終都能符合上述目標，但是最起碼做到了一部分并且解決了工具問題，當然，還得到了比現下更令人滿意及可靠的基礎設施。#p#

JVM與Ruby Vm

首先我們從CPU、RAM及網絡三個角度評估了前端服務器層，我們發現基于Ruby的架構明顯受限于CPU和內存，然而單機器的請求并沒有達到，網絡帶寬同樣也沒有接近飽和。在那個時候，我們的Rails服務器只能服務單線程，同樣，每次也只能處理一個請求。每個Rails主機都運行了一定數量的Unicom進程，用以提供主機級的并發性，但是重疊率浪費了太多的資源。歸結起來，Rails服務器每臺主機每秒只能處理200到300個請求。

然而Twitter使用率的增長卻并未放緩，這樣一來我們就必須投入海量的主機才能匹配用戶的增長曲線。

在那段時間，Twitter已經擁有部屬超大規模基于JVM服務的經驗——Twitter的搜索引擎就是使用Java編寫，而Streaming API基礎設施以及社交圖系統Flock都是使用Scala編寫，同時我們也迷戀JVM帶來的性能，如果選用Ruby VM的話，那么性能、靈活性以及效率都很難符合我們的目標，所以我們開始編寫可以運行在JVM上的代碼。我們預計重寫代碼庫可以讓我們獲得10倍的性能提升，而今天我們每臺服務器每秒已經可以處理1到2萬的請求。

對JVM的信任還基于公司中有很多工程師有著豐富的JVM經驗，我們有信心將Twitter帶入JVM后可以得到本質上的提升。這樣下面需要做的就是拆分架構，并弄清楚不同服務之間的交互方式。

程序設計模型

在Twitter的Ruby系統中，并發控制被放在進程級——單網絡請求通過進程排隊。這個進程會一直占用資源，直到請求結束。這樣將同時增加復雜性及架構難度，Twitter需要完成基于服務的轉變。同時因為Ruby進程使用單線程模式，后端系統延時將直接影響到響應時間。在Ruby中有很多選擇來增加并發性，然而JVM中卻并沒有一個標準選擇。JVM擁有著支持并發的設計和基元，讓我們可以建立一個真正的并發程序設計平臺。

這樣，就需要一個獨立且統一的方式去思考并發性，特別是網絡的思考。眾所周知，編寫并發代碼(以及并發的網絡代碼)是非常困難的，并且需要使用多種方式。事實上，這方面我們早就有所體會。然而在系統被分解成不同服務的初期，團隊并未使用統一的途徑;比如從客戶端到服務的failure semantics就不能很好交互：我們并沒有一致的back-pressure機制讓服務器給客戶端返回信號，因此出現了客戶端瘋狂重試服務引起的驚群效應。這個經歷讓我們明白統一、互補的客戶端及服務器庫的重要性，它可以在多個方面起到作用：連接池、故障轉移策略以及負載平衡，將我們連成一體，我們把Futures和Finagle拉到了一起。

現在不僅有了統一的方式，同樣合并了系統所需核心庫;如此我們就可以取得更快的進展，而不用過多關注每個系統的操作方式，從而把精力放到應用程序和服務接口上。

獨立系統

Twitter的***改變就是從一個整體的Ruby應用程序轉變為基于服務的架構，我們首先聚焦建立tweet、timeline及用戶服務——這也是Twitter的“核心名詞”。這種轉變讓我們可以更清晰的抽象出邊緣、團隊級所有權和獨立性。在Twitter王國，不僅需要理解整個代碼庫的專家，還有需要模塊以及類級別的所有者。越來越大的代碼庫讓全局理解變得不可能，然而在實際工作中，只有模塊和類級別的所有者根本不能解決問題。我們的代碼庫變得很難被維護，而團隊不停的去挖掘歷史代碼以便清楚某一功能。大規模錯誤發生時，搞清楚狀況就像組織去遠海狩獵鯨魚;到了***，我們在糾錯上花費的時間要遠大于新特性的發布，這是任何人都不愿看到的情況。

我們追求的永遠都是允許并行設計的面向服務架構，我們贊同網絡RPC接口，然后獨立的開發系統內部構件，然而這同樣意味著每個服務的邏輯都必須在內部實現。如果我們需要對tweet相關部分做改變，那么只需要在一個位置做出更改(Tweet 服務)，這種變化就可以貫穿整個操作系統。然而在實際操作中，發現并不能完全實現這個目標，比如：一個Tweet服務中的改變可能會需要其他服務做出相應的改變。雖然沒有做到完全獨立，但是大部分的情況下還是可以的。

這個系統架構就是我們一直期待的，每個團隊都可以獨立和快速的運轉。這就意味著團隊可以調用后端系統對所屬服務進行操作，非常有益大型應用程序運營。#p#

儲存

即使應用程序被切分成服務，存儲上仍然存在非常大的瓶頸。這時的Twitter使用的還是一個主MySQL數據庫，為此我們采取了臨時策略——將每條tweet都儲存為數據庫中的一行并進行順序存儲，當數據庫容量耗盡時會建立一個新的數據庫，并在應用中進行配置。這個策略為我們爭取到了一定的時間，但是峰值時的tweet吞吐量瓶頸依然存在，因為他們總是被順序的存儲到一個單獨的數據庫主節點中，所以讀負載只被分擔到一小部分的數據庫主機中。因此，我們需要為Tweet的存儲選擇一個不同的分片策略。

我們開發了Gizzard，幫助我們建立分片及容錯的分布式數據庫，用它來服務tweet。我們還建立了T-Bird。這種情況下，Gizzard需要處理大量的MySQL數據庫——當tweet被傳入系統時，Gizzard會首先得到它，然后選擇一個合適的數據庫。當然，這就意味喪失了MySQL的唯一ID生成能力。Snowflake被開發用以解決這個問題，它可以幫助建立tweet的ID。一旦有了標識符，就可以依靠Gizzard進行存儲。如果哈希算法非常有效，并且tweet接近均勻分布，那么就可以通過增加目標數據庫的數量來提高吞吐量。讀取同樣均勻的分布在整個集群上，而不是被綁在“最近”的數據庫上，這同樣是高吞吐量的保障。

可觀察及統計

雖然已經對整體應用程序進行更健壯的封裝，但是依然存在很多復雜性。為了管理如此規模的應用程序，工具也是個煞費苦心的領域。鑒于新服務的發布速度，快速收集每個服務運行數據的能力是必不可少的。一般情況下，我們希望做數據驅動策略，所以必須無縫獲得盡可能詳細的數據。

鑒于我們需要在一個不斷變大的系統上建立越來越多的服務，我們必須讓這個操作變得非常簡單。為此，Runtime Systems團隊為工程師建立了兩個工具：Viz和Zipkin。這兩個工具都對Finagle可見并與之整合，這樣所有使用Finagle建立的系統都可以自動通信。

如上顯示，一個服務通過短短的3行代碼就可以給Viz報告統計信息。這樣一來，任何人使用Viz都可以查詢自己感興趣的數據，比如request_latency_ms中第55和99百分位數據。

運行時配置和測試

***，當我們實現以上所有步驟時，卻遭遇了兩個看似無關緊要的障礙：發布特性必須在不同的服務之間做一系列協調，而Twitter的規模之也導致服務階段測試能力的喪失。依賴部署去開啟用戶層代碼已不再可行，取而代之的是必須在整個應用程序上做協調;此外，考慮到Twitter的相對體積，在整個隔離環境下進行有意義的測試變得非常困難。相對而言，我們并沒有在隔離系統中進行測試——我們使用了運行時配置來應對。

我們在服務中整合了被稱為Decider的系統，它允在服務中改變發生時，以近實時的方式將這個改變擴散到整個系統。這意味著一旦準備就緒，軟件和多個系統就可以投入使用。然而一個特性不應該是“神出鬼沒”的，Decider同樣允許我們靈活的去做基于二進制或者百分位的轉換，比如讓某個特性只針對百分之多少的傳輸或者用戶生效。我們可以將代碼配置成完全“off”或者是安全設置，然后逐漸的將它打開或者關閉，直到可以確信它正常工作并且系統可以支撐新的負載。這樣做可以降低隊伍之間協調的工作量，取而代之的是我們在運行時進行設置。

Twitter系統的現狀

比之3年前，當下Twitter系統的性能、有效性和可靠性都得到了顯著提高，從下圖不難看到，在集群使用率在50%到99.9%的情況下，網站的性能都得到了大幅度的提升，然而機器的數量卻減少了5至12倍。過去6個月，服務的可用性更達到了4個9(99.99%)。

模仿軟件堆棧去設置工程團隊，讓團隊長期獲得一個服務的所有權，有助于這部分基礎設施專家的形成。團隊有著自己的接口及問題域，舉個例子：不是所有的團隊都需要去關心tweet的擴展問題，只有涉及tweet子系統(tweet服務團隊、儲存團隊、緩存團隊等)運行的團隊必須去擴展tweet的寫入和讀出，其它的團隊只需要懂得使用現成的API就可以了。