Apache Storm 的歷史及經驗教訓

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

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

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

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

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

我認為很多開發者難以理解的是實現第二個條件與構建項目本身一樣困難和有趣。我希望在閱讀Storm的歷史時能給你一些啟發。

Storm來源

Storm來自于我在BackType的 工作. 在BackType我們的工作是產品分析以幫助用戶實時的了解他們的產品對社交媒體的影響,當然也能查詢到歷史記錄. 在Storm之前,實時部分的實現用的是標準的隊列和worker的方法. 比如, 我們向一個隊列集合里面寫入推ter 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的開發，因為它能夠讓我很容易的測試不同大小的集群和配置， 并且迭代更快.

被推ter收購

2011年5月,BackType與推ter談收購問題. 從各方面來講，這次收購對我們來講非常的重要.另外, 對我個人而言也很具有吸引力,因為推ter品牌效應的作用，由推ter來發布Storm比由BackType發布更能讓Storm有所作為.

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

這引發了其他令人驚訝的影響。在那篇博客上我不經意的提及Storm作為 “實時的Hadoop” ，這句話就這樣流行起來。直到現在人們還在使用它，甚至被許多人簡潔地稱為 “實時Hadoop” 。這個意外的品牌是非常強有力的，也有利于推廣。

開源的Storm

我們在官方上加入推ter是在2011年七月，之后我立即開始計劃Storm的發布。

有兩種方式你可以取得發布版的開源軟件。第一種是“使之變大”，為項目做許多宣傳，盡可能多地在發布的時候增加曝光率。這條途徑會有風險（如果軟件質量有缺陷或者你陷入困境，項目的人氣就會與日遞減）。那樣就會殺死任何有可能成功的項目。

第二條途徑是安靜地發布代碼并且讓軟件緩慢地獲得認可。這避免了第一種途徑的風險，（因為）它所擁有的風險與人們查看工程是無關緊要的，可以忽略。

我決定采用第一種方式。 我知道Storm是一款高質量且實用的軟件，并且因為我有發布第一個開源項目Cascalog  的經驗，我對Storm能否獲得認可充滿信心。

開始我計劃通過一篇博文來發布Storm，但后來我有個在大會上發布Storm的想法。在大會上發布可以：

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

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

3. 我可以炒作這次會議， 建起人們對此項目的渴望，這樣在發布的那一天它一定會備受關注。

所以從多個角度考濾，在大會上發布似乎更好。巧合的是，我已經計劃在9月的Strange Loop上討論一個完全不同的主題。因為我計劃在那時發布Storm,我給Strange Loop的組織者，Alex發了封郵件， 將我的會議改為Storm的發布. 正如你從會議簡介上看到的， 我會以推ter的名義對Storm進行介紹。

然后，我開始炒作Storm。 在2011年8月，會議前的一個月，我在推ter的科技博客板塊發表了一篇文章，宣布我將在Strange Loop 會議上發布Storm。 在那篇文章中，我通過展示Storm 工作方式的很多細節、并給出示例證明Storm的優雅，以勾起人們對Storm 的興趣。文章達到了我想要的效果，Storm讓人們很興奮。

第二天，我做了一些我認為比較聰明的事情。 我在Storm 郵件列表中寫道：

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

這就是我認為聰明的原因。 為了使項目獲得認可，你必須解決的一個關鍵的問題是建立社會認同。 社會認同以很多形式表現： 項目的實際使用記錄，Github 上關注者，郵件列表活動，郵件列表訂閱者，推ter 粉絲，項目相關的博客文章數量，等。 如果我在發布項目時就發起郵件列表活動，那么當人們查看郵件時，郵件會顯示沒有相關活動且關注者很少。 項目有可能會立刻變得很流行，郵件列表活動建立起了社會認同，但是對于這一點，我不敢保證。

在郵件列表發布之前,我處在被仲裁的情況。開始時人們問問題和訂閱,然后我在建立社會認同感。如果什么事都沒有發生,這并不重要,因為項目還沒有公布。

我在最初的那些日子里犯了一個錯誤,從我是在推ter上工作這是奇異的,不是為項目而注冊一個推ter賬號。推ter的一個很 棒的方式讓人們保持關注最新的項目以及不斷的展示人們的項目(通過轉發)。我沒有意識到我應該有一個推ter帳戶,直到后來發布,但幸運的是它證明 沒有什么大不了的。如果我能再做一次我就會在我的郵件列表上一天內開始 推ter帳戶。

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

項目發布在2011年9月19日進行。在發布時我感覺很高興。 我以“我一直在爭論是否開源Storm”為話題開始了我的演講，伴隨著一聲巨響演講開始，我在觀眾的驚嘆中結束了演講。 在演講進行到一半時，我說我決定開源Storm來做到兩全其美。 并且告訴觀眾，如果未來我沒有開源Storm，請在網上大聲地喊出來。 此時，伴隨著觀眾的尖叫，我發布了Storm。

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

發布之后

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

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

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

在接下來的一年里，我在會議上、聚會上、公司里做了大量的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"頁上我的電子郵件鏈接外，我用的方法是通過推ter和郵件列表接受提交來填充"Powered By"頁面。

Storm的技術演進

Storm相比它剛發布時更為先進。發布時它主要是面向我們在BackType的需求，當時我們還沒意識到各大公司對主要基礎設施的需求。在推ter上廣泛部署經過一年半的發展后發布了它。

大公司的技術需求與初創公司的是不同的。在初創公司里，一個小團隊管理著整個棧，包括所有操作與部署，而在大公司里，這些功能一般分配給多個團隊。我們從推ter中最先得知的是，人們并不想運行自己的Storm簇群，他們只想要一個由他人管理的Storm簇。

這預示著我們需要能夠擁有一個巨大的、共享的簇，用來運行許多獨立的應用。我們需要確保這些應用能夠得到足夠多的資源，確保在同一簇中一個應用出毛病時無法影響到其他的。這就是所謂的“多租戶”。

我們也遭遇過進程問題.當我們擴建共享簇時，注意到相當多的人在構建拓撲時，占用了超出他們實際需要的大量資源。這導致簇的使用非常低效。問題出在沒人主動優化自己的拓撲，他們只想運行自己的東西，使它們工作起來，因此在他們眼里沒理由不必去占用大量的資源。

我通過開發的“分離調度器“解決了這些問題。這是一個相當簡單的用于多租戶的解決方案，創建了促使人們高效利用資源的激勵機制，允許單簇共享產出與工作負載。

隨著越來越多的推ter用戶使用Storm，我們也發現他們需要控制他們的帶度量的拓撲，而不是Storm默認捕做的。這致使我們開發了Storm的優秀的度量API，允許用戶徹底地收藏定制的、任意度量，并發送給任何控制系統。

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

除了所有這些重大的改進之外，這個改進中還有許多生態的改善和大量的性能提升。我們所做的所有工作讓我們能夠發布許多版本的Storm–那之后的一 年中我們平均一個月發布至少一個版本。頻繁的版本發布在項目的成長的初期是非常重要的，因為每個發布都會在人們談論它時提高知名度。它也向人們展示了項目 在不斷發展，而且如果他們遇到了問題，項目也將迅速響應他們。

構建開發者社區版

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

在發布后起初的一年半里，我驅動整個Storm的開發。所有的變更都要經過我。以我為中心的發展有優點也有缺點。

通過控制項目的每個細節，我可以保證項目有很高的質量。因為我了解項目的各個環節，我可以預料任何變更對整個項目的影響。因為我有一個項目發展的愿景，我可以防止任何會改變該愿景（或一致的修改）的變更。我可以確保項目始終有一致的設計及體驗。

不幸的是，“愿景驅動開發”有一個主要的缺點：這種項目建立一個積極熱鬧的開發社區非常困難。首先，其他人加入進來并作出貢獻很難，因為我控制一 切。第二，我是所有開發的一大瓶頸。當達到一定規模是跟上的請求進來的速度（別忘了，與此同時我還在推ter組件了一個全新的基礎設施團隊）太困難 了。所以當反饋/合并周期延長時有些人感到氣餒了。

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

最后，以自己為開發中心最糟糕的情況是我個人覺得負擔很大。確實有巨大的壓力，休息都很困難。然而，我依然很猶豫是否擴大項目開發控制給別人，因為 我擔心項目質量。沒有其他人會像我一樣對整個代碼庫有深入的了解，而且不可避免的，一下改變會帶來意外后果。然而，我開始意識到這是擴展開發者社區時你要 必須面對的。但我意識到這并不想我擔心的那樣是個大問題。

離開推ter

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

我認為當項目還沒有得到充分的探討解空間“愿景驅動開發”是最好的。因此 Storm 包含我所有的決定，我們構建的多用戶、自定義的度量、Trident以及主要性能重構都是好事。主要的設計問題只能由對整個項目有深入了解的人解決。

我離開推ter的時候，我們已經繪制了Storm所能解決問題的模型。這并不是說沒有更多創新的可能–Storm自那之后有了很多提升–但這些創新 的改進并不一定是令人驚訝的。許多工作，自從我離開推ter后Storm從ZeroMQ轉為Netty，實現了安全/認證，提高了性能/可擴展性， 提升了拓撲的可視化，等等。這些都是可怕的改進，但都是2013年三月時預期的改進方向。換句話說，我認為當問題解決空間仍具有很大不確定性時“愿景驅動 開發”是必要的。當問題解決空間比較好理解時，“愿景驅動開發“的價值顯著減少。然后會出現個人成為瓶頸而嚴重抑制項目的成長。

大約離開推ter四個月的時候，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的歷史，離開推ter幾個月后我決定將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并發展到現在是段不易的旅程。我認識到創建一個成功的項目需要的不僅僅是產生好的代碼來解決重要的問題。文檔，營銷，以及社區的發展 也同樣重要。特別是在早期的時候，你必須要有創意并想出清晰的方法來起始項目。我所做的是利用推ter的品牌，從郵件列表開始直到發布前幾個月，并 做一個最大限度地曝光。此外，參與建設一個成功的項目還有很多繁瑣費時的工作，如寫文檔，回答無休止郵件列表上的問題，培訓宣講。

我看到的最驚人的事情是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以及那些曾為項目貢獻過補丁、部署過生產環境，寫使用經歷或推介過它的人。