推ter新系統架構性能大幅度提升

        8 月 3 日《天空之城》在日本的熱播創下每秒新增 143119 條推文的 推ter 峰值記錄，是 推ter 平均每秒發推數（TPS）5700 條的 25 倍。

        值得注意的是，在這次毫無征兆的“洪峰”到來時，推ter 全新的系統平臺并沒有被潮水般涌來的推文堵塞而產生任何延遲甚至宕機。

推ter 舊架構與新架構的性能對比

        僅僅三年前，在 2010 年世界杯上，一個點球和一張紅牌產生的“推文風暴”都可能導致 推ter 服務暫時失去響應，號稱地球脈搏的 推ter 經常“心肌梗塞”。過去三年 推ter 的工程師們夜以繼日的工作，試圖用“縫縫補補”的方式完善 推ter 系統，但最終隨著 推ter 的快速發展，這些方法的收效轉瞬即逝。

        最終，推ter 痛下決心重新架構為人詬病的 IT 系統，新平臺上線運行后在性能和可靠性上都取得的翻天覆地的進步。無論是《天空之城》熱播還是超級碗決賽都沒能卡住 推ter，而且新的架構也為 推ter 推出多媒體推文卡片，跨設備消息同步等新功能的推出提供了有力的支撐。

        最近，推ter 平臺工程副總裁 Raffi Krikorian（@raffi）在 推ter 官方博客撰文分享了 推ter 新架構的方法和經驗，摘要如下：

        重新架構的緣由與問題癥結

        2010 年世界杯多次卡殼后，我們重新審視了系統，有以下幾點發現：

        我們運行著全球最大的 Ruby on Rails 應用，200 名工程師負責開發運維這個系統，但隨著用戶規模和服務數量的快速增長，系統所有的數據庫管理、Memcache 鏈接以及公共 API 的代碼屬于同一個代碼庫。這給工程師的學習、管理和并行開發都帶來巨大困難。

        我們的 MySQL 存儲系統已經遇到性能瓶頸。整個數據庫中到處都是讀寫熱點。

        通過添置硬件已經無法解決根本的系統問題——我們的前端 Ruby 服務器每秒處理交易的數量大大低于我們的預期，也與其硬件性能不成比例。

        從軟件的角度看，我們陷入了“優化的陷阱”。我們是在犧牲代碼庫的可讀性和靈活性來換取性能和效率。

        重新檢視系統，并設定三大目標/挑戰

        一、新架構必須在性能、效率和可靠性上表現優異，減少延遲大幅提升客戶體驗；同時將服務器數量減少到原來的十分之一；新系統能夠隔離硬件問題防止其演變為大規模宕機。

        二、解決單一代碼庫的種種弊端，嘗試松耦合的面向服務模型。我們的目標是鼓勵封裝與模塊化的最佳實踐，但這次是在系統層面，而不是類庫、模塊和數據包的層面。

        三、最重要的是能夠支持新功能的快速發布。我們希望能夠由一些充分授權的小團隊能做出自主決策，并獨立發布一些用戶功能。

        我們在動手前部分開發了一些概念驗證模型，最終我們確定了重建的原則、工具和架構。

        系統重建的關鍵措施

        一、前端服務：用 JVM 取代 Ruby VM。通過重寫代碼庫將 Ruby VM 服務移植到 JVM，性能提高了 10 倍，如今性能達到 10-20k 請求/秒/主機。

        二、編程模型：按服務類型對系統進行結構，建立一個統一的客戶端服務器庫并與負載均衡、故障轉移策略等綁定，從而讓工程師們能更加專注于應用和服務界面。

        三、采用 SOA 面向服務架構，使并行開發成為可能。

        四、推文的分布式存儲。即使將整塊單一應用分解成不同的“服務”，存儲依然是個巨大的瓶頸。過去 推ter 采用的單一 MySQL 主數據庫只能線性寫入推文，推ter 決定在推文的存儲上采用全新的分區策略，用 Gizzard 框架創建容錯的分片分布式數據庫存儲推文，但這樣一來就沒有辦法使用 MySQL 的唯一 ID 生成功能。推ter 用 Snowflake 解決了這個問題。

        五、監測與統計。將單一應用轉化為復雜的 SOA 應用后，需要購買匹配的工具才能夠駕馭。推ter 的服務推出速度很快，同時還需要實現數據化的決策支持，推ter 的 Runtime 系統團隊為工程師開發了兩個工具 Viz 和 Zipkin。