从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