從Apache Storm學到的經驗教訓 —— storm的由來（轉）

 閱讀目錄

• Storm來源
• 初探
• 再探
• 構建第一個版本
• 被Twitter收購
• 開源的Storm
• 發佈以後
• Storm的技術演進
• 構建開發者社區版
• 離開Twitter
• 提交到Apache
• Apache孵化
• 結論

Apache Storm 最近成爲了ASF的頂級項目，這對於該項目和我我的而言是一個重大的里程碑。很難想像4年前Storm只是我腦海中的一個想法，但如今卻成爲了一個有着大社區支持並被無數企業使用的繁榮項目。在此我將在本文中回首Storm的成長曆程及其經驗教訓。

我會根據我當初必需要克服的主要挑戰來涵蓋Storm歷史的相關主題。本文前25%是關於Storm是如何構思並初創的， 因此主要討論促使我開發這個項目的技術問題。其他部分是關於Storm的發佈並由活躍用戶和開發者社區將其發展成一個普遍使用的項目的發展過程。本文主要 討論了Storm的營銷，傳播和社區的發展。

任何成功的項目都要知足兩個條件:

1. 它解決了一個實用的問題

2. 你有足夠的能力說服不少人使他們相信你的項目是解決他們問題的最佳方案。

我認爲不少開發者難以理解的是實現第二個條件與構建項目自己同樣困難和有趣。我但願在閱讀Storm的歷史時能給你一些啓發。

Storm來源

Storm來自於我在BackType的 工做. 在BackType咱們的工做是產品分析以幫助用戶實時的瞭解他們的產品對社交媒體的影響,固然也能查詢到歷史記錄. 在Storm以前,實時部分的實現用的是標準的隊列和worker的方法. 好比, 咱們向一個隊列集合裏面寫入Twitter firehose, 再用Python worker從這個隊列集合讀取tweets並處理他們. 一般狀況下這些worker須要經過另外一個隊列集合向另外一個worker集合發送消息來進一步處理這些tweets.

咱們很是不滿意這種處理方式. 這種方法不穩定--咱們必需要保證全部的隊列和worker一直處於工做狀態--而且在構建apps它也顯得很笨重. 咱們寫的大部分邏輯都集中在從哪發送/獲取信息和怎樣序列化/反序列化這些消息等等. 可是在實際的業務邏輯裏面它只是代碼庫的一小部分.再加上一個應用的正確邏輯應該是能夠跨多個worker,而且這些worker之間是能夠獨立部署的. 一個應用的邏輯也應該是自我約束的.

初探

在2010年12月，我完成了第一個重大實現。也就是在那時我想出了將"stream"做爲分佈式抽象的想法。stream會被並行地產生和處理，但它們 能夠在一個程序中被表示爲一個單獨的抽象。這使我產生了"spout"和"bolt"的想法－spout生產全新的stream, 而bolt將產生的stream做爲輸入併產出stream。這就是spout和bolt的並行本質， 它與hadoop中mapper和reducer的並行原理類似。bolt只需簡單地對其要進行處理的stream進行註冊，並指出接入的stream在 bolt中的劃分方式。最後，我所想到的頂級抽象就是"topology"－由spout和bolt組成的網絡。

我在BackType測試了這些抽象的用例，而且它們之間契合地很是好。我對於它的結果很是滿意：咱們以前須要處理的繁重工做－發送／接收消息，序列化，部署等都能經過這些新的抽象實現自動化。

在開始構建Storm以前，我想用更普遍的用例集來驗證個人想法。因此我發了這條微博:

我正在研究一個全新的流處理系統。若是你對這個感興趣請聯繫我，我須要你的用例。

— Nathan Marz (@nathanmarz) December 14, 2010

有一羣人迴應了我，而且咱們經過郵件來相互交流。很明顯，個人抽象很是很是合理。

而後我開始了Storm的設計。在我嘗試找出spout和bolt間傳遞消息的方式時我很快就被卡住了。我最初的想法是模仿咱們以前採用的隊列和工人方法並使用一個像 RabbitMQ 的消息代理來傳遞中間消息。我實際花費了大量時間來研究RabbitMQ用於此目的的方案和操做上的影響。可是，爲中間消息使用消息代理的想法彷佛並很差，因而我決定暫時擱置Storm直到我能想到更好的方法。

再探

我認爲須要那些中間消息代理的緣由是爲數據的處理提供保障。若是一個bolt處理消息時失敗了，它能夠從取得該消息的代理中重試。可是對於中間消息代理，有不少問題困擾着我：

1. 它們是部署於Storm以外的巨大，複雜的可移動部分

2. 它們建立了不合適的環境，例如當從新部署topology時該如何處置. 這些代理中極可能還有與新版本topology不兼容的中間消息。因此這些消息須要以某種方式清理或忽略掉。

3. 它們複雜化了容錯性。不只要指出當Storm worker崩潰時的處理方式，我也要指出在某一代理崩潰時該如何作。

4. 它們很慢. 消息不是直接在spout和bolt間傳遞的，而是通過了第三方的代理，此外消息還要保存到磁盤上。

直覺告訴我，還有一種不使用中間消息代理也能實現消息處理保障的方式。因此我花費了很長時間思考在spout和bolt間直接傳遞消息時該如何保障消息的 處理。不便用中間消息持久化，這意味着須要從消息來源(spout)中進行重試。棘手的是失敗可能發生在spout下游的任何地方或另外一臺服務器上，而且 這些失敗須要精準檢測到。

在苦思冥想了幾周後我忽然靈光一現。我開發了一個基於隨機數和異或運算的算法，它只需大約20字節就能夠跟蹤每一個spout tuple,  不論下游觸發了多少處理過程。它是我研究出的最優算法之一，它也是在我生涯中有限的幾回，能夠說若是沒有接受良好的計算機科學教育我是不會想出的算法。

在想出這個算法以後，我知道我已經取得了重大突破。由於避免了上面說起的全部問題，因此它大大簡化了storm系統的設計，並提供了一種更加高效的 方式。(有趣的是，在我想出這個算法的當天，我還有一個跟最近認識的女孩的約會。但我對該發現是如此激動以至於在整個約會期間我都心不在焉。不用說，我對 不住那女孩.)

構建第一個版本

在下面的的5個月裏，我構建了Storm的第一個版本。從一開始我就知道我會開源，所以一開始我在內心就作了一些關鍵的決定。首先，我用Java實 現了Storm的全部API，但用Clojure來實現Storm。經過將Storm的API 100%的Java實現，以確保它有一個很是大的潛在用戶羣體。而使用Clojure來實現，我可以更高效以使項目進展地更快。

一開始時我也計劃在非JVM的語言中使用Storm。拓撲被定義爲Thrift的 數據結構並提交了一個Thrift的API。除此以外，我設計了一個協議使得spouts和bolts能夠在任何語言中的實現。Storm能夠應用在其餘 語言讓更多的人使用了項目。它讓人們遷移到Storm中更容易，由於他們沒必要用 JAVA 重寫現有的實時處理器。相反，他們能夠遷移現有的代碼運行在Storm的多語言的API上。

我是Hadoop的長期用戶，用我已有的Hadoop經驗來設計Storm使得Storm會更好.好比, 在Hadoop的workers不關閉，全部的進程不作任何操做的狀況下。這些」僵死進程「積累到必定程度用盡了全部的資源，最終會致使這個集羣中止不能 運做--Hadoop最嚴重的問題之一. 這個問題的關鍵在於Hadoop中關閉worker的工做是由它自身負責。可是有時會由於其餘不少緣由致使worker自我關閉失敗. 因此在Storm的設計裏面，我把關閉worker的任務交給第一次啓動這個worker的daemon負責.最後也證實Storm的這種設計比 Hadoop更魯棒,也不存在」殭屍進程」的問題.

我在Hadoop中遇到的另外一個問題就是若是JobTracker由於某種緣由停掉,那麼在這個JobTracker跑的全部的任務都會終止.真正讓人着 急的是已經跑了幾天的任務就這樣被中止了.在Storm裏面不會存在單個節點失敗的問題，由於「topologies"是一旦開始就不會中止的。由於設計 Storm時就加入了」進程容錯「機制：一個Storm daemon的中止和重啓對一個正在運行的topologies絕對不會有影響. 固然這種考量會使設計面臨更多的挑戰，由於你必需要考慮到進程可能在任什麼時候候用kill -9強行中止和重啓的狀況,可是這樣也使它更健壯。

在開發階段的早期我作的一個很關鍵性的決定就是讓咱們的一個實習生--Jason Jackson-- 在AWS上作一個Storm的自動部署工具.這個工具在很大程度加快了Storm的開發，由於它可以讓我很容易的測試不一樣大小的集羣和配置， 而且迭代更快.

被Twitter收購

2011年5月,BackType與Twitter談收購問題. 從各方面來說，此次收購對咱們來說很是的重要.另外, 對我我的而言也很具備吸引力,由於Twitter品牌效應的做用，由Twitter來發布Storm比由BackType發佈更能讓Storm有所做爲.

在收購談判期間,我在BackType's的科技板塊發佈了一篇博客向世界宣佈了Storm的存在. 這篇博客的真正目的僅僅是爲了在與Twitter的談判中增長咱們的談判籌碼.它確實起到了做用：Twitter對這項技術特別感興趣，在作技能評測的時候，整個評測就演變成了一次大型的Storm演示.

這引起了其餘使人驚訝的影響。在那篇博客上我不經意的說起Storm做爲 「實時的Hadoop」 ，這句話就這樣流行起來。直到如今人們還在使用它，甚至被許多人簡潔地稱爲 「實時Hadoop」 。這個意外的品牌是很是強有力的，也有利於推廣。

開源的Storm

咱們在官方上加入Twitter是在2011年七月，以後我當即開始計劃Storm的發佈。

有兩種方式你能夠取得發佈版的開源軟件。第一種是「使之變大」，爲項目作許多宣傳，儘量多地在發佈的時候增長曝光率。這條途徑會有風險（若是軟件質量有缺陷或者你陷入困境，項目的人氣就會與日遞減）。那樣就會殺死任何有可能成功的項目。

第二條途徑是安靜地發佈代碼而且讓軟件緩慢地得到承認。這避免了第一種途徑的風險，（由於）它所擁有的風險與人們查看工程是可有可無的，能夠忽略。

我決定採用第一種方式。 我知道Storm是一款高質量且實用的軟件，而且由於我有發佈第一個開源項目Cascalog  的經驗，我對Storm可否得到承認充滿信心。

開始我計劃經過一篇博文來發布Storm，但後來我有個在大會上發佈Storm的想法。在大會上發佈能夠：

1.大會能幫助作營銷和推廣。

2. 我能夠直接面向使用Storm的潛在早期使用者羣體，他們能夠經過博客/微博/電子郵件更大泛圍的推廣Storm。

3. 我能夠炒做此次會議， 建起人們對此項目的渴望，這樣在發佈的那一天它必定會備受關注。

因此從多個角度考濾，在大會上發佈彷佛更好。巧合的是，我已經計劃在9月的Strange Loop上討論一個徹底不一樣的主題。由於我計劃在那時發佈Storm,我給Strange Loop的組織者，Alex發了封郵件， 將個人會議改成Storm的發佈. 正如你從會議簡介上看到的， 我會以Twitter的名義對Storm進行介紹。

而後，我開始炒做Storm。 在2011年8月，會議前的一個月，我在Twitter的科技博客板塊發表了一篇文章，宣佈我將在Strange Loop 會議上發佈Storm。 在那篇文章中，我經過展現Storm 工做方式的不少細節、並給出示例證實Storm的優雅，以勾起人們對Storm 的興趣。文章達到了我想要的效果，Storm讓人們很興奮。

次日，我作了一些我認爲比較聰明的事情。 我在Storm 郵件列表中寫道：

若是你想繼續瞭解Storm 或者對Storm 有疑問，請加入Google 討論組 http://t.co/S7TJlCB。 — Nathan Marz (@nathanmarz) 2011年5月。

這就是我認爲聰明的緣由。 爲了使項目得到承認，你必須解決的一個關鍵的問題是創建社會認同。 社會認同以不少形式表現： 項目的實際使用記錄，Github 上關注者，郵件列表活動，郵件列表訂閱者，Twitter 粉絲，項目相關的博客文章數量，等。 若是我在發佈項目時就發起郵件列表活動，那麼當人們查看郵件時，郵件會顯示沒有相關活動且關注者不多。 項目有可能會馬上變得很流行，郵件列表活動創建起了社會認同，可是對於這一點，我不敢保證。

在郵件列表發佈以前,我處在被仲裁的狀況。開始時人們問問題和訂閱,而後我在創建社會認同感。若是什麼事都沒有發生,這並不重要,由於項目尚未公佈。 

我在最初的那些日子裏犯了一個錯誤,從我是在Twitter上工做這是奇異的,不是爲項目而註冊一個Twitter帳號。Twitter的一個很 棒的方式讓人們保持關注最新的項目以及不斷的展現人們的項目(經過轉發)。我沒有意識到我應該有一個Twitter賬戶,直到後來發佈,但幸運的是它證實 沒有什麼大不了的。若是我能再作一次我就會在個人郵件列表上一天內開始 Twitter賬戶。 

我寫在Twitter上的科技博客和奇怪的循環的開始的時間之間,我花了個人大部分的時間爲Storm編寫文檔。爲這個項目這是我作的最重要的事 情之一。我寫了約12000字的仔細考慮過得文檔——教程,引用,API文檔等等。不少開源開發者不知道文檔是多麼的重要:若是人們不理解你的軟件，他們 就不會使用你的軟件。寫好的文檔是痛苦的,耗時的,但絕對必要的。 

項目發佈在2011年9月19日進行。在發佈時我感受很高興。 我以「我一直在爭論是否開源Storm」爲話題開始了個人演講，伴隨着一聲巨響演講開始，我在觀衆的驚歎中結束了演講。 在演講進行到一半時，我說我決定開源Storm來作到一箭雙鵰。 而且告訴觀衆，若是將來我沒有開源Storm，請在網上大聲地喊出來。 此時，伴隨着觀衆的尖叫，我發佈了Storm。

一切按照計劃進行。 Storm得到了大量的關注，發佈的第一天， Github上的粉絲就超過 1000人。 Storm馬上登上了 Hacker News 網站的頭條。 演講結束，我上網回答 Hacker News、郵件列表活動、 Twitter上人們提出的問題。

發佈以後

四天以內，Storm成爲了Github上最受關注的 Java, Scala與 Clojure 領域的項目。兩週以內，spider.io宣佈已將Storm用在了產品中。我認爲那是讓人難以置信的，作出高質量的項目與文檔的發佈承諾,。

Strom一經發布，我就開始獲取用戶的反饋。在第一週，我製做了三個最小化的發佈，用來解決用戶遇到的生命週期的質量問題。儘管他們很小，但我儘量確 保每人都有最佳體驗。同時，我也在Strom中加入了大量的額外日誌，使用戶在郵件列表中列出問題時，可以向我提供更多遇到的信息。

我沒預料到回答郵件列表裏的問題會花費多少時間。 郵件列表裏有不少的活動，我天天花一到兩個小時回答問題。 使郵件列表這麼耗時的一部分緣由是大多數人的提問很糟糕。 常常有人問下面的問題： 「我使用時元組報不少錯誤。 爲何？？「 大部分狀況下，緣由很簡單：用戶在使用 Storm時，運用了一些奇怪的配置。 可是我不得不花費大量的時間問後續的問題，以獲取問題的詳細信息，這樣我才能幫助他們。 用戶作了奇怪的操做卻不告訴你，你會對這類事情發生的頻率感到吃驚，好比同時運行多個版本的 Storm，手動修改本地磁盤上 Storm的守護進程，運行他們本身修改後的 Storm版本，或者爲 Storm 守護進程配置共享網絡驅動器。 回答郵件列表上的問題變得愈來愈耗時（尤爲當時我正在 Twitter上創建一個全新的團隊），一年多的時間裏我都沒有從中解脫。

在接下來的一年裏，我在會議上、聚會上、公司裏作了大量的Storm的演講。 我確信我進行了超過25次演講。 我已經達到閉上眼睛就能夠介紹Storm項目的境界。 全部這些演講使Storm愈來愈有名氣。

營銷有了回報，Storm很快得到了產品用戶的支持。 我在2012年1月作了一個調查，發現Storm已有10個產品用戶，另有15個用戶計劃將要在他們的產品中使用Storm，另有30家企業對Storm 進行了試驗。 在發佈後的3個月內擁有那麼多的產品用戶，這對於一個大型的基礎型項目來講是很是有意義的。

我創建了一個 Storm「技術支持」頁面，以得到最後一張社會認同通行證。 用戶列表中不只僅展現公司，我請求每一個人把本身加入到列表中，並附上他們如何使用 Storm的簡短說明。 這可讓人們在瀏覽頁面時瞭解 Storm不一樣的使用場景和使用力度。 對於那些想出如今用戶列表的人，我提供了一個我郵箱的連接。 像我進行技術演講同樣，這個頁面會一直地增加和發展。

填充一個項目的"Powered By"頁面有點讓人心煩，由於可能有不少人使用你的項目但你殊不知道。我記得有一次我收到一封世界上最大的中國公司的郵件，要對將它加入Storm 的"Powered By"頁。那時他們已經用Storm超過一年，但我卻全然不知道。即便如今，我不知道讓別人告訴你他們正在使用你的軟件的最佳途徑是什麼。除了對 Storm"Powered By"頁上個人電子郵件連接外，我用的方法是經過Twitter和郵件列表接受提交來填充"Powered By"頁面。

Storm的技術演進

Storm相比它剛發佈時更爲先進。發佈時它主要是面向咱們在BackType的需求，當時咱們還沒意識到各大公司對主要基礎設施的需求。在Twitter上普遍部署通過一年半的發展後發佈了它。

大公司的技術需求與初創公司的是不一樣的。在初創公司裏，一個小團隊管理着整個棧，包括全部操做與部署，而在大公司裏，這些功能通常分配給多個團隊。咱們從Twitter中最早得知的是，人們並不想運行本身的Storm簇羣，他們只想要一個由他人管理的Storm簇。

這預示着咱們須要可以擁有一個巨大的、共享的簇，用來運行許多獨立的應用。咱們須要確保這些應用可以獲得足夠多的資源，確保在同一簇中一個應用出毛病時沒法影響到其餘的。這就是所謂的「多租戶」。

咱們也遭遇過進程問題.當咱們擴建共享簇時，注意到至關多的人在構建拓撲時，佔用了超出他們實際須要的大量資源。這致使簇的使用很是低效。問題出在沒人主動優化本身的拓撲，他們只想運行本身的東西，使它們工做起來，所以在他們眼裏沒理由沒必要去佔用大量的資源。

我經過開發的「分離調度器「解決了這些問題。這是一個至關簡單的用於多租戶的解決方案，建立了促令人們高效利用資源的激勵機制，容許單簇共享產出與工做負載。

隨着愈來愈多的Twitter用戶使用Storm，咱們也發現他們須要控制他們的帶度量的拓撲，而不是Storm默認捕作的。這導致咱們開發了Storm的優秀的度量API，容許用戶完全地收藏定製的、任意度量，併發送給任何控制系統。

Storm另外一個大的技術跳躍是發展中的Trident，一個Storm之上微混合的API，其提供了精準的一次性處理語義。這使Storm能夠被應用到許多新的使用案例。

除了全部這些重大的改進以外，這個改進中還有許多生態的改善和大量的性能提高。咱們所作的全部工做讓咱們可以發佈許多版本的Storm–那以後的一 年中咱們平均一個月發佈至少一個版本。頻繁的版本發佈在項目的成長的初期是很是重要的，由於每一個發佈都會在人們談論它時提升知名度。它也向人們展現了項目 在不斷髮展，並且若是他們遇到了問題，項目也將迅速響應他們。

構建開發者社區版

建立開源項目最艱難的部分是構建開發者社區版以促進項目發展。這絕對是讓我吃力的部分。

在發佈後起初的一年半里，我驅動整個Storm的開發。全部的變動都要通過我。以我爲中心的發展有優勢也有缺點。

經過控制項目的每一個細節，我能夠保證項目有很高的質量。由於我瞭解項目的各個環節，我能夠預料任何變動對整個項目的影響。由於我有一個項目發展的願景，我能夠防止任何會改變該願景（或一致的修改）的變動。我能夠確保項目始終有一致的設計及體驗。

不幸的是，「願景驅動開發」有一個主要的缺點：這種項目創建一個積極熱鬧的開發社區很是困難。首先，其餘人加入進來並做出貢獻很難，由於我控制一 切。第二，我是全部開發的一大瓶頸。當達到必定規模是跟上的請求進來的速度（別忘了，與此同時我還在Twitter組件了一個全新的基礎設施團隊）太困難 了。因此當反饋/合併週期延長時有些人感到氣餒了。

圍繞本身開發的另外一個缺點是，人們視我爲一個項目失敗的單點。不斷有人提醒我若是我被車撞了會發生什麼。這個問題確實限制了項目，超出了你的預想， 像Storm，已被許多大公司所採用，但卻以我爲開發中心，它們包括Yahoo!、Groupon、天氣頻道，WebMD、Cerner、百度，阿里巴 巴、淘寶以及許多其餘公司。

最後，以本身爲開發中心最糟糕的狀況是我我的以爲負擔很大。確實有巨大的壓力，休息都很困難。然而，我依然很猶豫是否擴大項目開發控制給別人，由於 我擔憂項目質量。沒有其餘人會像我同樣對整個代碼庫有深刻的瞭解，並且不可避免的，一下改變會帶來意外後果。然而，我開始意識到這是擴展開發者社區時你要 必須面對的。但我意識到這並不想我擔憂的那樣是個大問題。

離開Twitter

當我在2013年三月離開Twitter去追求個人新起點時，我仍然身處Storm開發的中心。幾個月後，這成爲一個須要優先刪除的項目瓶頸。我以爲在共識驅動的發展模式下，Storm會更好發展。

我認爲當項目尚未獲得充分的探討解空間「願景驅動開發」是最好的。所以 Storm 包含我全部的決定，咱們構建的多用戶、自定義的度量、Trident以及主要性能重構都是好事。主要的設計問題只能由對整個項目有深刻了解的人解決。

我離開Twitter的時候，咱們已經繪製了Storm所能解決問題的模型。這並非說沒有更多創新的可能–Storm自那以後有了不少提高–但這些創新 的改進並不必定是使人驚訝的。許多工做，自從我離開Twitter後Storm從ZeroMQ轉爲Netty，實現了安全/認證，提升了性能/可擴展性， 提高了拓撲的可視化，等等。這些都是可怕的改進，但都是2013年三月時預期的改進方向。換句話說，我認爲當問題解決空間仍具備很大不肯定性時「願景驅動 開發」是必要的。當問題解決空間比較好理解時，「願景驅動開發「的價值顯著減小。而後會出現我的成爲瓶頸而嚴重抑制項目的成長。

大約離開Twitter四個月的時候，Yahoo!的Andy Feng強烈建議我將Storm提交到Apache。那時我剛剛開始思考如何確保Storm的將來，Apache彷佛是個有趣的想法。我會見了 Hadoop的創造者Doug Cutting，獲取他對Apache的見解以及Storm轉移到Apache的潛在風險。Doug給我說了Apache如何工做的概述，坦誠地談了 Apache的利弊。他告訴我說，孵化器有些混亂，這最多是過程當中最痛苦的（但在實際中，過程卻使人難以置信的平滑）。Doug的意見是很是寶貴，他真 實幫我瞭解了共識驅動的開發模型。 

在共識驅動開發中，至少包括其如何爲許多Apache項目使用的，變動須要項目組「提交人員」的投票。一般一個變動須要至少兩個+1贊成而且沒有-1反對 票。這就意味着每一個提交人員都有否決權。在一個共識驅動的項目中，不是每一個人都會對代碼有全面的瞭解。許多開發者會專一於代碼的不一樣部分。隨着時間的推 移，一些參與者將學習到更多部分的代碼並更深刻的瞭解一切是如何配合的。

當Storm首先轉移到共識驅動模型時，大多數的參與者對代碼的理解不成總體比較有限，有的是不一樣專一領域的理解。這徹底是由於我一直佔主導開發地 位的緣由–沒有人曾經被賦予他們須要學習更多以作出正確決定的責任。經過給其餘人更多的權力和並退後一步，我但願別人能填補這一空白。這就是確切發生的。

當轉移到共識驅動開發時個人一個擔心是開發質量會降低。而事實上，咱們的轉換中的一些變化導入了bug。但這沒什麼大不了的。由於你會獲得錯誤報 告，並在下個版本中解決這個問題。若是問題真的是很大，你能夠放出一個緊急版本供他人使用。當我獨自一人作全部開發決定時，我會本身完全測試，並利用我對 整個代碼庫的瞭解去釋放高質量的代碼。但即便這樣，個人代碼有時仍有bug，咱們要在下個發佈時解決它們。因此共識驅動開發也沒有什麼不一樣，除了變動的問 題可能須要更多的迭代來解決這個不一樣。沒有軟件是完美的–重要的是，要有一個積極負責的開發社區，去迭代和解決出現的問題。

提交到Apache

回到Storm的歷史，離開Twitter幾個月後我決定將Storm轉換爲共識驅動開發模式。我很專一於個人新起點，我也但願Storm有長期的 住所會給用戶的信心：Storm會有興起的日子。我考慮全部的選項時，提交Storm到Apache彷佛是最好的選擇。Apache會給Storm帶來強 大的品牌，強大的法律基礎以及我但願項目擁有的徹底的共識驅動模型。

經過運用我從Doug Cutting的所學，我當心翼翼地將Storm往Apache轉移：着手以前事先甄別孵化過程當中可能引發的任何法律問題。Storm使用ZeroMQ庫用於內部進程間通訊，但不幸的是，ZeroMQ許可與Apache基金會的政策不相容。Yahoo!的一些開發者（他們後來成爲Storm的提交者）推動並基於Netty建立了一個替代。

在造成Storm的初始提交者名單時，我選擇了不一樣公司並對項目有較大貢獻的開發者。一我的我超級高興可以邀請到的是者是Taylor Goetz，他當時在健康科學市場（Health Market  Science ）工做。我猶豫是否邀請他是由於他那時他尚未貢獻代碼。然而，他在社區和郵件列表上很是活躍，因此我決定在他身上試一下。成爲體檢者 後，Taylor採起了大量的行動，分擔了許多項目的管理負擔。孵化期間他處理大部分細節的東西（好比顧及某些法律的事情，弄清楚如何將網站遷移到 Apache，如何進行提交者的權限管理，管理髮布，呼籲投票，等）。Taylor後來去了Hortonworks爲Storm全職工做，他作了出色的工 做來幫助Storm經過孵化器，他如今是該項目的PMC。

2013年九月，在Yahoo! Andy Feng的幫助下，我正式宣佈Storm在Apache孵化。由於咱們預先準備好了，建議中只有一些小的修改須要。

Apache孵化

孵化過程當中，咱們必須證實咱們可以保證發佈，發展用戶社區，並擴大項目的提交者。完成這全部內容咱們沒有遇到任何問題。一旦Storm孵化成功，我再也不是瓶頸，開發迅速加速。提交補丁的迅速反饋促使了更多的貢獻。咱們鑑定你們貢獻的重要性並邀請他們成爲提交者。

由於孵化後我像其餘提交人員同樣只是提交者，投票的比重也是同樣的。我集中精力關注影響Storm核心的任何問題，或那些有困難的設計決策。這樣更有效地利用個人時間，可以審查每一個小小的變化也是項巨大的安慰。

Storm在2014年9月17日正式步入頂級項目的行列，在開源後短短的三年後。

結論

構建Storm並發展到如今是段不易的旅程。我認識到建立一個成功的項目須要的不只僅是產生好的代碼來解決重要的問題。文檔，營銷，以及社區的發展 也一樣重要。特別是在早期的時候，你必需要有創意並想出清晰的方法來起始項目。我所作的是利用Twitter的品牌，從郵件列表開始直到發佈前幾個月，並 作一個最大限度地曝光。此外，參與建設一個成功的項目還有不少繁瑣費時的工做，如寫文檔，回答無休止郵件列表上的問題，培訓宣講。

我看到的最驚人的事情是Storm對行業大範圍的影響。在Powered By頁上，有醫療保健，天氣，新聞，分析，拍賣，廣告，旅遊，報警，金融等諸多領域的應用。閱讀該頁回顧大量工做我以爲對Storm的投入是值得的。

講述這個故事的過程當中我沒法包括每一個細節（畢竟三年是段很長的時間）。因此我想經過列出那些對Storm今日的所成重要的人物。我對全部這些人很是 感激：Chris  Aniszczyk, Ashley Brown, Doug Cutting, Derek Dagit, Ted Dunning, Robert  Evans, Andy Feng, Taylor Goetz, Christopher Golda, Edmund Jackson, Jason  Jackson, Jeff Kaditz, Jennifer Lee, Michael Montano, Michael Noll,  Adrian Petrescu, Adam Schuck, James Xu以及那些曾爲項目貢獻過補丁、部署過生產環境，寫使用經歷或推介過它的人。

本文地址：http://www.oschina.net/translate/history-of-apache-storm-and-lessons-learned

原文地址：http://nathanmarz.com/blog/history-of-apache-storm-and-lessons-learned.html