STORM_0008_Structure-of-the-codebase_Storm的代码库的结构

http://storm.apache.org/releases/1.0.1/Structure-of-the-codebase.html

• Structure of the codebase

源码分成独立的三层

第一：在最开始的时候Storm就被设计成支持多种语言，Nimbus是一种Thrift的服务，Topologies是一种Thrift类型的结构。Thrift的使用使得Storm可以被任何语言使用。

第二：所有的Storm的接口都被声明为java接口，虽然内部的实现有很多的Clojure但是所有的使用必须通过java api。这意味着所有的特性都可以通过java调用。

第三：Storm的实现很大一部分是Clojure，但是有接近一半的java代码，但是因为Clojure表达性强，所以绝大多数的逻辑的实现都在Clojure中。

下面的部分详细解释每一部分

• storm.thrift
• org.apache.thrift7
• 每一个组件都有一个component id
• Spouts和bolts有相同的Thrift定义
• 一个Thrift definition for bolts包含ComponentObject结构和ComponentCommon结构
• ComponentObject，定义了bolt的实现，可能是下面的三种类型的一种
• 一个Serialized java对象，实现了IBolt
• 一个ShellComponent代表了其他语言的实现，按照这样的方式声明bolt的时候将会造成storm实例化一个ShellBolt对象， 去处理基于JVM的工作进程和非基于JVM的实现的部分之间的通信
• 一个JavaObject结构，传递给storm类名和构造的参数去实例化那个bolt。如果你想用一种非JVM语言去定义拓扑的时候这样是有用的。这样你可以使用基于JVM的spouts和bolts而不必自己创建并且序列化一个java对象。
• ComponentCommon，定义了组件的所有的其他的部分，包含下面的：
• 这个组件发射什么streams，已经每个stream的metadata
• 这个组件消费什么stream
• 这个组件的并行度
• 组件声明的配置信息
• 需要注意的是，spouts的结构也包含了一个ComponentCommon属性，因此，spouts也可以声明去消费其他的输入流。但是JAVA API没有提供这样一种方式使得spout去消费其他的流，如果你放任何的输入声明给spout，那么在提交拓扑的时候，你将会得到一个错误。spouts有一个输入声明的属性不是给用户去使用的 ，而是为了storm自身去使用的。storm添加隐式的流或者bolts给拓扑，去设置acking framework，一个拓扑中每个spout有两个来自acker bolt的隐式的流。伴随着这些流，一旦tuple被检测到完成或者失败，acker发送ack或者fail信息。这些用户的拓扑需要被转换成运行时拓扑。
• Java interfaces
• storm的接口主要被声明为java接口，主要的接口有下面的三个
• IRichBolt
• IRichSpout
• TopologyBuilder
• 大多数的接口的策略是：
• 用一个java的interface声明一个接口
• 合适的时候提供一个基类提供默认的实现
• 一个微妙的区别是IBolt/ISpout和IRichBolt/IRichSpout的区别。主要的区别是是rich版本的接口，多了declareOutputFields方法。有这种区别的原因是因为每个输出流的输出fields的声明需要是Thrift结构的一部分（保证可以从各种语言指定出来），但是作为用户，你希望能够声明流作为自己的类的一部分。TopologyBuilder做的事情是当创建Thrift表示，调用declareOutputFields获取声明，并转换为Thrift结构。
• 实现
• 通过java接口声明所有的功能保证每个特性都能通过java去调用。
• 虽然两个代码量相同，但是Clojure实现了主要的逻辑。但是有两个例外，就是DRPC和transactional topologies的实现。这两个是纯java的实现。这充当了一个抽象，为实现storm的更高程度的抽象。这两个模块的代码在org,apache.storm.coordination,org.apache.storm.drpc,org.apache.storm.transactional包中。
• 下面是主要的java 包和Clojure namespace的功能的总结：
• java packages
• org.apache.storm.coordination:实现了在storm之上的批处理
• org.apache.storm.drpc:DRPC更高程度的抽象
• org.apache.storm.generated:storm生成Thrift代码
• 使用了Thrift的this fork，简单的把这个包重命名为org.apache.thrift7以避免和Thrift版本的冲突
• org.apache.storm.grouping:包含自定义的流分组的接口
• org.apache.storm.hooks：包含钩子进入各种事件的接口，例如当任务发送tuple，当tuple被ack。
• org.apache.storm.serialization:实现了storm序列化和反序列化tuples，基于谷歌的kyro
• org.apache.storm.spout:定义了spout和相关的接口
• org.apache.storm.task:定义了bolt和相关接口，TopologyContext也定义在这
• org.apache.storm.testing:包含了一系列的在单元测试中使用的测试bolts和工具
• org.apache.storm.topology:基于底层的Thrift结构的Java层，为storm提供一个整洁，纯java的API。
• org.apache.storm.transactional:事务拓扑的实现
• org.apache.sorm.tuple:storm的tuple数据模型的实现
• org.apache.storm.utils:代码库使用的数据结构和乱七八糟的工具
• Clojure namespaces
• org.apache.storm.bootstrap:包含了一个宏，可以导入整个代码库需要的各种类和命名空间
• org.apache.storm.clojure:为storm实现了Clojure DSL
• org.apache.storm.cluster:storm守护进程需要的zookeeper逻辑都封装在这个文件中。这个文件的代码，管理了集群的状态在zookeeper的文件系统中的描绘。
• org.apache.storm.command.*:为storm命令行客户端实现了多种的命令，都很短
• org.apache.storm.config:Clojure配置文件的读取和解析的代码。
• org.apache.storm.daemon.acker:acker bolt的实现，是storm保证数据处理的重要的部分。
• org.apache.storm.daemon.common:storm守护进程使用的通用函数的实现，比如，根据拓扑的名字获取拓扑的id等。
• org.apache.storm.daemon.drpc:DRPC server的实现
• org.apache.storm.daemon.nimbus:Nimbus的实现
• org.apache.storm.daemon.supervisor:Supervisor的实现
• org.apache.storm.daemon.task:spout和bolt的独立任务的实现
• org.apache.storm.daemon.worker:工作进程的实现
• org.apache.storm.event:实现一个异步的函数执行器。
• org.apache.storm.log:定义了往log4j中打日志的函数
• org.apache.storm.messaging.*:定义更高层次的接口实现点对点通信，本地模式使用基于内存的java queue,在集群上使用ZeroMQ,通用的接口被定义在protocol.clj中。
• org.apache.storm.stats:统计汇总例程的实现，将这些stats信息发送到zk在UI中显示
• org.apache.atorm.testing:测试拓扑的设施的实现
• org.apache.storm.thrift:包围着Thrift API的 Clojure Wrapper使得使用Thrift结构更加愉悦
• org.apache.storm.timer:后台计时器
• org.apache.storm.ui.*:Storm UI的实现
• org.apache.storm.util：整个代码库使用到的通用工具
• org.apache.storm.zookeeper:包含Zookeeper API的ClojureWrapper实现高层的例如mkdirs和delete recursive的操作。