?

发布之后

?

四天之内，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、百度，阿里巴巴、淘宝以及许多其他公司。

?