Apache Storm 的曆史及經驗教訓——Nathan Marz【翻譯】

英文原文位址

中英文對照位址

History of Apache Storm and lessons learned

——項目建立者 Nathan Marz

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以及那些曾為項目貢獻過更新檔、部署過生産環境，寫使用經曆或推介過它的人。