20+ Twitter開源軟體精選

oschina發表於2016-07-06

從Twitter的GitHub賬戶中可以看到，Twitter已經開源的開源專案有近200個，領域涉及分散式架構、大資料、非同步網路傳輸（客戶端、服務端）、Web、工具等。Twitter可以稱為構建於開源專案之上，該公司開源負責人Chris Aniszczyk表示，如果沒有開源軟體，Twitter將不會存在，使用者在移動端和PC端傳送和接收的每一條推文都會需要開源軟體。

Typeahead.js——自動文字補齊jQuery外掛

這款jQuery外掛來自於Twitter的一個新的專案，支援遠端和本地的資料集。比較有特色的地方在於你可以將資料集使用本地儲存(local storage)來儲存在本地，有效的提高使用者體驗。同時也擁有很多遠端資料集的處理選項，例如（請求頻率，最大的併發請求數，等等）。

主要特性：

支援資料本地儲存，客戶端載入，優化載入速度
支援多語言，並且支援阿拉伯文
支援Hogan.js模板引擎整合
支援多資料集拼裝
支援本地和遠端的資料集

原始碼地址：https://github.com/twitter/typeahead.js

Twemoji——Twitter 的 Emoji 表情

TTwemoji 是 Twitter 開源的其完整的 Emoji 表情圖片。開發者可以去GitHub下載完整的表情庫，並把這些表情加入到自己的應用或網頁中。

原始碼地址：https://github.com/twitter/twemoji

Hogan.js——JS模板引擎

Hogan.js是Twitter團隊所製作的一個針對mustache模板的語法解析器。Hogan.js不依賴其他任何庫或框架，同時保證了高效率的模板解析，而其體積卻僅有2.5K。用它作為你的一部分資產打包編譯模板提前或將它包括在你的瀏覽器來處理動態模板。

原始碼地址：http://twitter.github.com/hogan.js

Effective Scala——Scala語言

Scala是Twitter的主要應用程式語言之一，大部分基礎架構是使用Scala編寫，有幾個大型庫包在支援應用，Scala是一種大型高效語言，在實踐中要謹慎使用。它的陷阱在哪裡，哪個特性我們很喜歡，另外哪些應該注意迴避？當在實現“純函式風格”時，又要注意些什麼呢？Scala主要是建立大量形成分散式系統的服務。

Scala提供了需要工具用於簡化表達，少打字代表少閱讀，少閱讀代表能快速閱讀，簡潔能夠增加清晰度（大道至簡）。但是簡潔也是一種雙刃劍，會導致其反面效果，導致閱讀者的正確理解度不夠。

原始碼地址：https://github.com/twitter/effectivescala

Finagle——RPC框架

Finagle 是一個容錯的、與協議無關的用於JVM 的RPC系統。Finagle 使用 sbt 進行構建。Finagle 來自 Twitter ！它使得在 Java、Scala 或任何基於 JVM 的語言重構建魯棒的客戶端和伺服器非常容易。Finagle 支援廣泛的基於請求/答覆的 RPC 協議和很多型別的流協議

使用 Finagle 可以快速實現非同步的遠端方法呼叫 RPC 客戶端和伺服器端，本身足夠靈活支援多種 RPC 變種，包括請求響應式、流和管道模式，如 HTTP 管道和 Redis 管道，也可輕鬆的有狀態的 RPC 一起執行，例如那些需要認證的 RPC 服務。

原始碼地址：https://github.com/twitter/finagle

FlockDB——分散式圖形資料庫

FlockDB將圖儲存為一個邊的集合，每條邊用兩個代表頂點的64位整數表示。對於一個社會化網路圖，這些頂點ID即使用者ID，但是對於“收藏”推文這樣的邊，其目標頂點(destination id)則是一條推文的ID。每一條邊都被一個64位的位置資訊標識，用於排序。(Twitter在“關注”類的邊上用了時間戳標識，所以你的關注者列表時按時間排序的，最新的在最前面。）

原始碼地址：https://github.com/twitter/flockdb

Snowflake——分散式自增ID演算法

Twitter在把儲存系統從MySQL遷移到Cassandra的過程中，由於Cassandra沒有順序ID生成機制，於是自己開發了一套全域性唯一ID生成服務：Snowflake。優點是：高效能，低延遲；獨立的應用；按時間有序。缺點是：需要獨立的開發和部署。

41位的時間序列（精確到毫秒，41位的長度可以使用69年）；

10位的機器標識（10位的長度最多支援部署1024個節點）；

12位的計數順序號（12位的計數順序號支援每個節點每毫秒產生4096個ID序號）最高位是符號位，始終為0。

高效很方便的GUID產生演算法，一個int64_t欄位就可以勝任，不像現在主流128bit的GUID演算法，即使無法保證嚴格的ID序列性，但是對於特定的業務，比如用做遊戲伺服器端的GUID產生會很方便。另外，在多執行緒的環境下，序列號使用Atomic可以在程式碼實現上有效減少鎖的密度。

原始碼地址：https://github.com/twitter/snowflake

Diffy——自動化測試工具

Diffy是一個開源的自動化測試工具，它能夠自動檢測基於Apache Thrift或者基於HTTP的服務。使用Diffy，只需要進行簡單的配置，之後不需要再編寫測試程式碼。

Diffy主要基於穩定版本和它的副本的輸出，對候選版本的輸出進行比較，以檢查候選版本是否正確。因此，Diffy首先假設候選版本應該和穩定版本有“相似”的輸出。即不論候選版本和穩定版本系統模組是否相同，他們的最終輸出應該是“相似”的。這裡一直使用“相似”，而不是使用相同，是因為相同請求可能會有一些Diffy不需要關心的干擾，比如：

響應中包含伺服器生成的時間戳；
程式碼中使用了隨機數；
系統服務間有條件競爭。

原始碼地址：https://github.com/twitter/diffy

Scalding——Scala庫

Scalding 是一個 Scala 庫簡化了 Hadoop MapReduce 作業開發。基於 Cascading 構建。Scalding 跟 Pig 類似，但提供更緊密的 Scala 整合。

Hadoop 是一個統計詞（counting words）的分散式系統。

原始碼地址：https://github.com/twitter/scalding

Gizzard——通用資料切分中介軟體

Gizzard是Twitter在2011年4月份新推出的一個通用資料切分中介軟體，在Twitter的架構中佔重要的作用。Twitter還公佈了Gizzard的完整程式碼。有了Gizzard，初創公司和小公司就可以更好更快地處理大量資料，從而利用更少的資源滿足使用者需求。Gizzard的主要功能如下：

支援不同的底層資料儲存，Redis/Memcache/Mysql等都支援，原則上只要寫操作冪等（也就是寫操作與順序無關）則都可以支援；
通用資料拆分支援，支援一致性hash、主鍵mod、自定義拆分函式等多種方式；
通過replication tree實現不同節點資料的備份機制；
容錯機制，在一臺機器出問題後，會自動儲存更新延遲佇列，在恢復後重新執行，從而保證一致性；
快速遷移。

原始碼地址：https://github.com/twitter/gizzard

Summingbird——流處理框架

Summingbird是MapReduce流處理框架，一個大規模資料處理系統，支援開發者以批處理模式（基於Hadoop/MapReduce）或流處理模式（基於Storm）或混合模式（即組合前兩種模式）以統一的方式執行程式碼。它基於Apache 2許可釋出，用於解決工程師使用現有方法遇到的實際問題：

兩個不同系統中的兩組聚合邏輯必須保持同步；
在每個系統和客戶端之間，鍵和值必須一致地進行序列化；
客戶端要負責從兩個資料儲存讀取資料、執行最後的聚合並提供合併結果。

原始碼地址：https://github.com/twitter/summingbird

Algebird——Scala的抽象代數工具

Algebird是用於Scala的抽象代數。這些程式碼主要是用於建立聚合系統（通過Scalding或Storm）。Algebird跟Summingbird這個元件相關：利用一些概率演算法HyperLogLog來提高計算速度。

原始碼地址：https://github.com/twitter/algebird

Iago——網站負載測試工具

Iago是一個網站負載測試工具，Iago針對一個給定的網站進行訪問錄製併合成流量資料。它不同於其他的負載生成工具，它試圖保持恆定的請求率。例如，如果你想按每分鐘100K來請求你的服務，Iago會試圖保持這個速度進行測試。

原始碼地址：https://github.com/twitter/iagox

Heron——資料實時分析平臺

2016年5月25日，Twitter正式宣佈Heron開源。Heron的基本原理和方法：實時流系統是在大規模資料分析的基礎上實現系統性的分析。另外，它還需要：每分鐘處理數十億事件的能力、有秒級延遲，和行為可預見；在故障時保證資料的準確性，在達到流量峰值時是彈性的，並且易於除錯和在共享的基礎設施上實現簡單部署。

為了滿足這些需求，Twitter討論出了幾種方案，包括：擴充套件Storm、使用其他的開源系統、開發一個全新的平臺。因為有幾個需求是要求改變 Storm的核心架構，所以對它進行擴充套件需要一個很長的開發週期。其他的開源流處理框架並不能完美滿足Twitter對於規模、吞吐量和延遲的需求。而且，這些系統也不能相容Storm API——適應一個新的API需要重寫幾個topologies和修改高階的abstractions，這會導致一個很長的遷移過程。所以，Twitter決定建立一個新的系統來滿足以上提到需求和相容Storm API。

在Twitter，Heron作為主要的流媒體系統，執行數以百萬計的開發和生產topologies。由於Heron可高效使用資源，在遷移Twitter所有的topologies後，整體硬體減少了3倍，導致Twitter的基礎設定效率有了顯著的提升。

原始碼地址：https://github.com/twitter/heron

DistributedLog——分散式日誌複製服務

DistributedLog（DL）是一個高效能的日誌複製服務，提供了持久化、複製以及強一致性的功能，這對於構建可靠的分散式系統都是至關重要的，如複製狀態機（replicated-state-machines）、通用的釋出/訂閱系統、分散式資料庫以及分散式佇列。DL會分類維護記錄的序列（sequences of records），並將其稱為Log（又叫做Log Stream），將記錄寫入到DL Log的程式稱之為Writer，從Log中讀取並處理記錄的程式稱之為Reader。DL的優勢可以總結為:

高效能：面對大量的併發日誌時，在可持久化的Writer上DL能夠提供毫秒級的延遲，同時還能應對上千客戶端每秒大量的讀取和寫入操作；
持久化和一致性：訊息會持久化到磁碟上，並且以副本的形式儲存多份，從而避免丟失。通過嚴格的順序，保證Writer和Reader之間的一致性；
各種工作負載：DL支援各種負載，包括延遲敏感的線上事務處理（OLTP）應用（如分散式資料庫的WAL和基於記憶體的複製狀態機）、實時的流提取和計算以及分析處理；
多租戶：針對實際的工作負載，DL的設計是I/O隔離的，從而支援多租戶的大規模日誌；
分層架構：DL有一個現代化的分層設計，它將有狀態的儲存層與無狀態的服務提供層進行了分離，能夠使儲存的擴充套件獨立於CPU和記憶體，因此支援大規模的寫入fan-in和讀取fan-out。

原始碼地址：https://github.com/twitter/distributedlog

Ambrose——視覺化監視系統

Ambrose是Twitter釋出的開源MapReduce視覺化監視系統。它可以監視Hadoop叢集上（目前只限於Apache Pig）的MapReduce任務。Ambrose計劃支援：

Pig（已實現）
Cascading
Scalding
Cascalog
Hive

原始碼地址：https://github.com/twitter/ambrose

SecureHeaders——Web安全開發工具

SecureHeaders是Twitter送給Web開發者的一份大禮，作為一款Web安全開發工具，Secureheaders能夠自動實施安全相關的header規則，包括內容安全政策（CSP），防止XSS、HSTS等攻擊，防止火綿羊（Firesheep）攻擊以及XFO點選劫持等。

原始碼地址：https://github.com/twitter/secureheaders

Activerecord-Reputation-System——活動記錄信譽系統

Activerecord-Reputation-System系統基於Rails開發，可以根據網路中的評價自動對應用程式進行信譽估值，幫助開發者發現更多的應用程式相關資訊，從而指導下一步決策。Twitter稱，開發者可以很容易地在Rails應用程式中整合該系統，或者從主應用程式中分離該系統，以便做出更好的設計。

該系統是一個信譽網路，網路中的資料根據評價進行更新，然後計算信譽值並通過網路進行傳播。在該網路中，直接根據評價計算的信譽值稱為原始信譽（primary reputations），間接計算的稱為非原始信譽（non-primary reputations）。

Alt text

原始碼地址：https://github.com/twitter/activerecord-reputation-system

CocoaSPDY——SPDY框架

CocoaSPDY是一個面向OS X（Cocoa）和iOS（Cocoa Touch）的SPDY框架，基於他們先前對Netty的貢獻，同時，他們更新了其iOS應用程式，使用SPDY代替了純HTTP。Twitter已經注意到，通訊延遲降低了多達30%，當“使用者的網路狀況變得更糟”時，改善效果更明顯。

SPDY有另外一個優點：“多路複用請求”—— 一項在單個TCP會話中連續不斷地傳送請求並接收亂序響應的能力、從伺服器向客戶端推送訊息，以及壓縮請求和響應的頭資訊。

原始碼地址：https://github.com/twitter/CocoaSPDY

TwUI——UI框架

TwUI是一個支援硬體加速的Mac的UI框架：

使用CoreAnimation實現的GPU加速；
簡單的MVC開發。

與UIKit不同的地方：

簡化Table View單元；
基於塊的佈局和drawRect；
一個統一的座標系統（bottom left origin）；
Sub-pixel文字繪製。

原始碼地址：https://github.com/twitter/twui

Twemproxy——代理伺服器

Twemproxy是一個快速的單執行緒代理程式，支援Memcached ASCII協議和更新的Redis協議。它全部用C寫成，使用Apache 2.0 License授權。Twemproxy的強大之處在於可以通過配置的方式讓它禁用掉失敗的結點，同時還能在一段時間後進行重試，抑或使用指定的鍵->伺服器對映。這意味著在將Redis用作資料儲存時，它可以對Redis資料集進行分片（禁用掉結點驅逐）；在將Redis用作快取時，它可以啟用結點驅逐以實現簡單的高可用性。它的特性是：

通過代理的方式減少快取伺服器的連線數；
自動在多臺快取伺服器間共享資料；
通過不同的策略與雜湊函式支援一致性雜湊；
通過配置的方式禁用失敗的結點；
執行在多個例項上，客戶端可以連線到首個可用的代理伺服器；
支援請求的流式與批處理，因而能夠降低來回的消耗；
速度快；
輕量級。

原始碼地址：https://github.com/twitter/fatcache

Fatcache——快取服務

Fatcache可以讓你在SSD上執行memcached，你可以把它當作是大資料中的快取。它的一些效能資料如下：

單節點可每秒可處理10萬set操作，每個資料包是100位元組；
單節點可每秒處理4.5k get操作，每個資料100位元組；
8 個Fatcache例項可處理32k get操作/每秒到一個單600GB的SSD儲存；
你可以通過將多個SSD連線到單個機器來提升IO效能。