从Apache Storm学到的经验教训 —— storm的由来

　　Apache Storm是一个免费、开源的分布式实时计算系统。除了用于实时分析外，Storm也可用于在线机器学习、持续计算、分布式远程调用和ETL等领域。Storm简单易用，支持多种编程语言。Storm也是少有的几个使用Clojure编写的开源项目之一，Clojure是一个在JVM平台运行的动态函数式编程语言。国内的几个公司也在大规模使用Storm，比如百度、淘宝，在Storm的官网也能看到他们的商标。

　　在Storm升级为Apache基金会顶级项目后，Storm主工程师Nathan Marz就Storm的由来和项目心得撰写了本文。Nathan Marz表示，Storm的成功离不开开源，打造一个成功的项目不仅是能帮助人们解决实际问题，还必需兼顾文档，推广，支持社区等方方面面。

译文如下：

Storm的由来

　　首先，任何成功的项目需要做到两点：

1. 成功解决了一个实际问题
2. 能够说服大量的用户使用你的项目，证明你的项目是他们的最佳解决方案。

　　我想，第二点是开发者在项目工作中普遍忽略的一点，但其实这关系到项目的成败，我希望下述的Storm历史能够使大家对此引起足够的重视。

　　Storm的前身是BackYype，用来帮助商家分析和研究他们的产品在社交网络中的影响力，可以处理历史或实时的数据。使用的方法是标准队列和线程(worker)方法，但是这个方案不太令人满意。首先它并不友好，所有的队列和线程都必须确保可用，这样相对来说显得冗长。大部分逻辑处理用于进行收发和序列/反序列消息，一个应用的某个逻辑将会遍及所有线程。

　　在2010年12月，我想到了“流(Stream)”的分布式抽取方法，最后演变为“喷嘴(spout)”和“bolts(螺拴)”的思想。这两个概念的特点是内在并行处理的，类似于Hadoop。Bolts对于需要处理的流进行订阅，然后指出之后的流该如何进行分区处理。进行一番实践后，我决定在这基础上进行进一步改进，于是我在推特上发布了新的构建思路--Storm，结果反应非常热烈。

　　随后，对中间消息的依赖让我觉得，如果有个更好的办法，消除对中间消息传递的依赖，会更能提高工作效率。于是我尝试使用一种基于随机数和异或逻辑的算法，它仅需要20个字节的长度来跟踪每个spout数组。至此，Storm的雏形基本成型，我隐约感觉这将是一项伟大的工程。

第一个版本

　　接下来的5个月时间里，Storm的第一个版本诞生了。从一开始，开源是我觉得应该去做的事情。我用Java进行Storm API的编写，而部署端使用Clojure。事实证明，这会带来更高的软件生产力和工作效率。此外，考虑到兼容性和便利性，我希望Storm平台是能与主流编程语言无缝工作的，这样人们使用Storm时，可以使用自己熟悉的语言，而不必重写代码。

　　作为Hadop的重度使用者，Hadoop的僵尸worker模式会浪费不少资源。于是，在Storm设计中，我把累赘的使用完毕的worker在其首次出现的地方就直接销毁。另外，一旦Hadoop的JobTracker出现问题，正在运行的作业将会被终止。如果有一项作业已经运行了多天却因此而被迫终止，这无疑是非常令人沮丧的。所以在Storm中我引入了“process fault-tolerant(进程容错)”机制，简单说，就是即使Storm守护进程被销毁，重启该进程不会对正在运行的拓扑产生影响。

　　在Jason Jackson的帮助下，在AWS上我们创建了Storm自动部署机，这对Storm的开发过程带来极好的帮助，同时使得我可以在不同大小和配置的机器集群中进行测试。

开源Storm

　　2011年7月，与Twitter就收购事宜达成一致，我们正式加入Twitter这个大品牌。同时，我马上着手推出Storm。

　　要想成功发布开源软件，方法有两个。一是把事情“搞大”，尽可能地增加作品的曝光度与关注度，不过缺点是一旦与人们预期不符合，进一步合作意愿可能从此消失。二是静悄悄地发布，慢慢地培养用户群，不足之处是如果人们发现不过如此，很可能从此不再关注。对这两点进行分析论证后，我决定透过开交流会的方式进行宣传和发布。事后证明，这是正确的做法。在正式发布当天，Github上的浏览和关注数很快就超过了1000次，同时成为Hacker New上排名首位的项目。

Storm的技术演变

　　初创企业的需求与大型成熟企业的需求截然不同，加入Twitter后，我们对此有越来越深刻的认识。在Twitter中，人们希望能够直接使用Storm，而把其他的运营工作交给别人。这意味着，我们需要打造一个大型的共享集群，能够独立运行大量的程序，并确保程序间不会成为彼此的资源争夺者，这一般被称为“多用户架构”。

　　由于共享的性质，我们发现人们喜欢获取最大程度的资源来运行程序，而实际上很多时候是供大于求。于是，我开发了“isolation scheduler(分离调度表)”。这个机制一来鼓励人们更有效地使用资源，二来允许单个集群共享负载量。

　　随着Twitter平台的发力，越来越多的开发者成为Storm的用户。出于对系统性能监控需求的考虑，我们提供了相应的指标API，方便人们把相关指标数据与自己喜好的监控系统进行整合。

　　另外一个较大的技术进步是开发了Trident(三叉戟)，一个基于Storm的微批处理API，提供了精确的一次性语义处理能力，提高了对新用例的处理能力。

离开Twitter，投入Apache怀抱

　　在2013年，我离开Twitter发展自己的创业公司，但对于Storm，我始终是开发环节和发展的中心。接下来的数月里，在再次认识以个人为中心模式的种种不足后，我想是时候采用共识驱动的开发模式了。我希望Storm能成为一项长久的有活力的工程。争取Apache基金会的帮助，投入Apache的怀抱，是非常合适的选择。Apache有足够的品牌影响力，是个强大的合法的基金会，最关键的是能最大程度帮助Storm过渡到共识驱动模式。随着我作为发展瓶颈的问题完美解决后，Storm驶入发展的快车道。Storm开发社区活跃度与日俱增，越多越多的新想法新思路被发掘被采纳，在其哇哇坠地的三年后，在2014年9月成为官方的顶级项目，这就是群众的力量。

写在最后

　　Storm的成功让我深刻认识到，打造一个成功的项目不仅仅要能帮助人们解决实际问题，还必需兼顾文档，推广，支持社区等方方面面。特别是项目初期，我们需要有自己的创造性思维，来确保项目被成功推广。此外，自己也需要充分利用时间，来为人们解答疑难，编写支持文档，形成良好的交流氛围。最后，我们有时候需要做个清醒的旁观者，看有什么会制约项目发展，在适当的时候做出果断的选择，该抽离就抽离，群众的力量总比一个人战斗来得高效长效。