Storm源码分析--Nimbus启动过程

Nimbus server, 首先从启动命令开始, 同样是使用storm命令"storm nimbus”来启动
看下源码, 此处和上面client不同, jvmtype="-server", 最终调用"backtype.storm.daemon.nimbus"的main
nimbus是用clojure实现的, 但是clojure是基于JVM的, 所以在最终发布的时候会产生nimbus.class,
所以在用户使用的时候完全可以不知道clojure, 看上去所有都是Java. clojure只是用于提高开发效率而已.

1. Nimbus启动过程

bin/storm

def nimbus(klass="backtype.storm.daemon.nimbus"):
    """Syntax: [storm nimbus]
    Launches the nimbus daemon. This command should be run under 
    supervision with a tool like daemontools or monit. 
    See Setting up a Storm cluster for more information.
    """
    cppaths = [CLUSTER_CONF_DIR]
    jvmopts = parse_args(confvalue("nimbus.childopts", cppaths)) + [
        "-Dlogfile.name=nimbus.log",
        "-Dlogback.configurationFile=" + STORM_DIR + "/logback/cluster.xml",
    ]
    exec_storm_class(klass, jvmtype="-server", extrajars=cppaths, jvmopts=jvmopts)

storm-core/backtype/storm/daemon/nimbus.clj

;; 启动nimbus的主方法
(defn -main []                      ;; main前面加上-, 表示是public的. 所以bin/storm能直接调用nimbus.clj的main方法
  (-launch (standalone-nimbus)))        ;; 同样launch也是一个public方法. standalone-nimbus是一个方法, clojure对于没有参数的方法可以省略()

(defn -launch [nimbus]              ;; launch的参数是一个Nimbus对象, 所以上面standalone-nimbus方法的返回值是Nimbus
  (launch-server! (read-storm-config) nimbus))

注意在clojure中的函数命名规范,-functionname表示该函数是public的,如上面的-main,调用该函数的时候,不需要加-,使用main即可。
而与此相对的是defn-,这个表示该函数是私有函数,不可在外部调用。

1) standalone-nimbus

nimbus的main, 最终会调到launch-server!, conf参数是调用read-storm-config读出的配置参数,
而nimbus是INimbus接口(backtype.storm.scheduler.INimbus)的实现, 可以参考standalone-nimbus.
storm-core/backtype/storm/scheduler/INimbus.java

public interface INimbus {
    void prepare(Map stormConf, String schedulerLocalDir);
    /**Returns all slots that are available for the next round of scheduling.在下一次调度中可用的槽位
     * A slot is available for scheduling 如果槽位是空闲的且可以被分配的, 或者虽然被使用但可以被重新分配的. 都是可以被调度的
     * if it is free and can be assigned to, or if it is used and can be reassigned. */
    Collection<WorkerSlot> allSlotsAvailableForScheduling(Collection<SupervisorDetails> existingSupervisors, Topologies topologies, Set<String> topologiesMissingAssignments);

    // this is called after the assignment is changed in ZK
    void assignSlots(Topologies topologies, Map<String, Collection<WorkerSlot>> newSlotsByTopologyId);

    // map from node id to supervisor details
    String getHostName(Map<String, SupervisorDetails> existingSupervisors, String nodeId);    
    IScheduler getForcedScheduler(); 
}

;; 返回一个实现了INimbus接口的对象. 由于不想创建这种类型, 使用reify匿名对象
(defn standalone-nimbus []                  ;; 没有参数. clojure中[]使用的地方有: let绑定, 方法的参数, vector
  (reify INimbus                                ;; reify: 具体化匿名数据类型: 需要一个实现了某一协议/接口的对象，但是不想创建一个命名的数据类型. 匿名类
    ;; 下面的方式都是INimbus接口的实现方法
    (prepare [this conf local-dir])                 ;; this可以看做是一个隐式参数, prepare方法实际只有2个参数的
    (allSlotsAvailableForScheduling [this supervisors topologies topologies-missing-assignments]
      (->> supervisors
           (mapcat (fn [^SupervisorDetails s]
                     (for [p (.getMeta s)]
                       (WorkerSlot. (.getId s) p))))
           set ))
    (assignSlots [this topology slots])
    (getForcedScheduler [this] nil )
    (getHostName [this supervisors node-id]
      (if-let [^SupervisorDetails supervisor (get supervisors node-id)]
        (.getHost supervisor)))
    ))

这里面有好几个语法点: ->>, mapcat if-let
mapcat, (mapcat f & colls) 和普通map不同的是, 会对map执行的结果执行concat操作等于(concat (map f &colls))
依次对colls中的每个集合运用函数f, 最后将每个结果合并起来. (mapcat f collections)的map不是数据结构意义的映射. 而是一个遍历操作.
普通的map版本是: (map f collection), 用java来描述就是for(Object o : collection) func(o). 集合中的每个元素会作为函数f的参数.
上面的(mapcat (fn [s] ...))并没有看到collections. 这个要结合->> supervisors来一起分析.
->> supervisors (mapcat fun) 实际上等价于(mapcat fun supervisors). 由于mapcat的返回值是map,根据接口的定义返回值是一个集合Collection
所以(mapcat)表达式后面的set的意思是将(mapcat)表达式的返回值转换为set, (mapcat)表达式的返回值会跟在set后面作为最后一个Item.
达到连续调用的功能. ->>和->的区别是->是将返回值作为下一个表达式的第二个Item, 而->>是作为下一个表达式的最后一个Item.

supervisors不是Supervisor列表, 其类型是SupervisorDetails. mapcat后面紧跟的函数的参数类型对应的是collections=supervisors的类型.
WorkerSlot需要两个参数id和port. 所以这个方法返回的是Collection, 对应接口INimbus的返回类型.

getHostName的参数supervisors和allSlotsAvailableForScheduling的supervisors是一样的.
通过supervisors.get(node-id)获取对应的supervisor. 所以我们可以猜测supervisors是一个Map.
storm-core/backtype/storm/scheduler/SupervisorDetails.java

public class SupervisorDetails {
    String id;
    String host;                // hostname of this supervisor
    Object meta;
    Object schedulerMeta;       // meta data configured for this supervisor
    Set<Integer> allPorts;      // all the ports of the supervisor  
}

Nimbus要分配任务给Supervisor上的Worker进行工作, 而每个Supervisor会有多个worker. 配置文件中可以为一个supervisor配置多个slot port.

2) read-storm-config

阅读源码其实都会遵循一个范式,那就是程序的入口在哪,配置文件是在什么时候读入的。那么好,现在就来讲配置参数的读入,在上面的-launch函数中,
已经可以见到用以读取配置文件的函数了,那就是read-storm-config。非常狗血的是, 在 nimbus.clj 中有一个名称非常类似的函数称为read-storm-conf,这个可不是来读取storm cluster的配置信息,它其实是用来读取Topology的配置内容的。read-storm-config定义于config.clj中,此时你会说等等,没见到有地方
import或是use backtype.storm.config啊。这一切都被包装了,它们统统被放到bootstrap.clj中了。注意到这行没 (bootstrap)
好了, 上述有关文件引用的疑问解决之后, 还是回到正题, 看看read-storm-config的定义吧。storm默认的配置文件使用的是yaml格式,一定要找到使用yaml parser的地方。
storm-core/backtype/storm/config.clj

(defn read-storm-config []
  (let [conf (clojurify-structure (Utils/readStormConfig))] ;; let中参数conf被赋值为右侧的表达式的值. 和java方法参数不同, let中参数可以被计算
    (validate-configs-with-schemas conf)                ;; 对conf进行验证
    conf))                                      ;; 返回这个conf 

真正实现对配置文件storm.yaml进行读取的是由java代码来实现的,readStormConfig定义于Utils.java中。
storm-core/backtype/storm/utils/Utils.java

    public static Map readDefaultConfig() {
        return findAndReadConfigFile("defaults.yaml", true);
    }
    public static Map readStormConfig() {
        Map ret = readDefaultConfig();              // 首先读取defaults.yaml的配置
        String confFile = System.getProperty("storm.conf.file");
        Map storm;
        if (confFile==null || confFile.equals("")) {
            storm = findAndReadConfigFile("storm.yaml", false); 
        } else {
            storm = findAndReadConfigFile(confFile, true);
        }
        ret.putAll(storm);                          // 其次读取storm.yaml中的配置
        ret.putAll(readCommandLineOpts());          // 最后是命令行的参数, 这个优先级更高
        return ret;
    }
    public static Map findAndReadConfigFile(String name, boolean mustExist) {
            HashSet<URL> resources = new HashSet<URL>(findResources(name));
            URL resource = resources.iterator().next();
            Yaml yaml = new Yaml();
            Map ret = (Map) yaml.load(new InputStreamReader(resource.openStream()));
            if(ret==null) ret = new HashMap();
            return new HashMap(ret);                // 解析storm.yaml文件, 返回HashMap
    }
    public static List<URL> findResources(String name) {
            Enumeration<URL> resources = Thread.currentThread().getContextClassLoader().getResources(name);
            List<URL> ret = new ArrayList<URL>();
            while(resources.hasMoreElements()) {
                ret.add(resources.nextElement());   
            }
            return ret;
    }

终于看到神秘的Yaml了,那么Yaml这个类又是由谁提供的呢,看看Utils.java的 开头部分有这么一句话: import org.yaml.snakeyaml.Yaml;
再看看在storm-core/project.clj中定义的dependencies: [org.yaml/snakeyaml "1.11"]
至此,yaml文件的解析及其依赖关系的解决探索完毕。在新版本的storm中使用了maven管理. 可以查看pom.xml

3) storm.yaml

conf/storm.yaml

# storm.zookeeper.servers:
#     - "server1"
#     - "server2"
# 
# nimbus.host: "nimbus"
# 
# ##### These may optionally be filled in:
#    
## List of custom serializations
# topology.kryo.register:
#     - org.mycompany.MyType
#     - org.mycompany.MyType2: org.mycompany.MyType2Serializer
#
## List of custom kryo decorators
# topology.kryo.decorators:
#     - org.mycompany.MyDecorator
#
## Locations of the drpc servers
# drpc.servers:
#     - "server1"
#     - "server2"

## Metrics Consumers
# topology.metrics.consumer.register:
#   - class: "backtype.storm.metrics.LoggingMetricsConsumer"
#     parallelism.hint: 1
#   - class: "org.mycompany.MyMetricsConsumer"
#     parallelism.hint: 1
#     argument:
#       - endpoint: "metrics-collector.mycompany.org"
storm.zookeeper.servers:
   - 127.0.0.1
storm.zookeeper.port: 2181
nimbus.host: "127.0.0.1"
storm.local.dir: "/home/hadoop/data/storm"
supervisor.slots.ports:
 - 6700
 - 6701
 - 6702
 - 6703

在配置文件中需要至少回答以下三个问题
1. zookeeper server在哪台机器上运行,具体就来说就是ip地址啦
2. nimbus在哪运行,可以填写ip地址或域名
3. 在每台supervisor运行的机器上可以启几个slot,指定这些slot监听的端 口号
2. thrift RPC
1) thrift
网络结点之间的消息交互一般会牵涉到两个基本的问题,
• 消息通道的建立
• 消息的编解码
如果每变化一个需求就手工来重写一次,一是繁琐,二是易错。为了一劳永逸的解决此类问题,神一样的工具就出现了,如google protolbuffer,如thrift.
thrift的使用步骤如下

编写后缀名为thrift的文件,使用工具生成对应语言的源码,thrift支持的语言很多的,什么c,c++,java,python等,统统不是问题。
实现thrift client
实现thrift server
thrift server需要实现thrift文件中定义的service接口。更为具体的信息可以通过阅读官方文档来获得。这里有个thrift java的示例.

(1). 编写thrift文件：add.thrift

namespace java com.zqh.code.thrift.server   // defines the namespace
typedef i32 int                         // typedefs to get convenient names for your types
service AdditionService {               // defines the service to add two numbers
        int add(1:int n1, 2:int n2),            // defines a method
}

(2). 编译：thrift --gen java add.thrift 会在当前目录生成gen-java/$namespace$/AdditionService
(3). Service：Interface的实现类

public class AdditionServiceHandler implements AdditionService.Iface {
    public int add(int n1, int n2) throws TException { return n1 + n2; }
}

实现类具体实现了thrift文件定义的接口方法.
(4). Server

public class MyServer {
    public static void start(AdditionService.Processor<AdditionServiceHandler> processor) {
            TServerTransport serverTransport = new TServerSocket(9090);     // 服务端Socket
            TServer server = new TSimpleServer(new Args(serverTransport).processor(processor));
            System.out.println("Starting the simple server...");
            server.serve();
    }
    public static void main(String[] args) {
        start(new AdditionService.Processor<AdditionServiceHandler>(new AdditionServiceHandler()));
    }
}

服务端通过TServerSocket暴露出服务端口, 客户端要通过这个端口连接.
实现类Handler的实例要作为生成的AdditionService.Processor的参数.
Args需要TServerTransport作为参数, 然后调用processor方法, 该方法需要AdditionServiceProcessor参数.
这个过程类似于将自定义实现类Handler注册到服务端上. 接着启动服务器.
(5). Client

public class AdditionClient {
    public static void main(String[] args) {
            TTransport transport = new TSocket("localhost", 9090);
            transport.open();
            TProtocol protocol = new TBinaryProtocol(transport);
            AdditionService.Client client = new AdditionService.Client(protocol);
            System.out.println(client.add(100, 200));
            transport.close();
    }
}

客户端要建立到服务端的连接, 需要提供Server的host和port. 根据TTransport构造出和服务端进行通讯的一个协议.
这个协议传给自动生成的AdditionService的Client内部类, 会生成一个类似服务端的代理对象.
接着就可以使用这个代理对象调用thrift协议提供的方法.

分布式测试: 可以在两台机器上测试. 第一二步都需要在两台机器上操作: 编写thrift文件, 编译.
然后在第一台机器操作3: 自定义实现类; 4: Server. 在第二台机器上操作5: Client. 最后分别运行两台机器的Server和Client.

2) nimbus thrift server

有了thrift这个背景,我们再重新拾起上述的代码执行路径。上头讲到程序执行至

(defn -launch [nimbus]                                  ;; launch的参数是一个Nimbus对象, 所以上面standalone-nimbus方法的返回值是Nimbus
  (launch-server! (read-storm-config) nimbus))

(defn launch-server! [conf nimbus]                      ;; 让nimbus作为一个thrift server运行起来
  (validate-distributed-mode! conf)                     ;; 分布式模式下才会启动thrift server
  (let [service-handler (service-handler conf nimbus)           ;; 自定义实现类, 实现storm.thrift中service Nimbus定义的接口方法
        options (-> (TNonblockingServerSocket. (int (conf NIMBUS-THRIFT-PORT))) ;; 服务端的ServerSocket
                    (THsHaServer$Args.)             ;; TServerSocket作为TServer.Args内部类的参数. 创建了Args args对象 ->表示插入第二个位置
                    (.workerThreads 64)                 ;; 上面new Args(TServerSocket)会作为这里的第二个位置, 即args.workerThreads(64)
                    (.protocolFactory (TBinaryProtocol$Factory. false true (conf NIMBUS-THRIFT-MAX-BUFFER-SIZE)))
                    (.processor (Nimbus$Processor. service-handler))    ;; args作为这里的第二个位置,即调用了args.processor
                                                    ;; new Nimbus.Processor(service-handler), 自定义实现类作为Nimbus.Processor的参数,
                                                    ;; processor会作为参数再传给args.processor()
                    )                               ;; 最终返回的是TServer.AbstractServerArgs, 会作为TServer构造函数的参数
       server (THsHaServer. (do (set! (. options maxReadBufferBytes)(conf NIMBUS-THRIFT-MAX-BUFFER-SIZE)) options))]
    (.addShutdownHook (Runtime/getRuntime) (Thread. (fn [] (.shutdown service-handler) (.stop server))))
    (log-message "Starting Nimbus server...")               ;; 上面添加了一个关闭钩子. 类似回调函数. 当关闭Nimbus的thrift服务时, 会触发这个函数执行
    (.serve server)))                               ;; 启动TServer, 即启动Nimbus的thrift服务

launch-server!说白了,就是让nimbus作为一个thrift server运行起来, 那么storm.thrift中service指定的各个接口函数实现在service-handler中完成。
对比clojure版本的创建thrift server的过程, 其实和上面java示例是一样的, 只不过换了不同的实现类. 以下是java-clojure的代码对比.
new AdditionServiceHandler() (service-handler conf nimbus)
new AdditionService.Processor(new AdditionServiceHandler()) (Nimbus$Processor. service-handler)
TServerTransport serverTransport = new TServerSocket(9090); (TNonblockingServerSocket. (int (conf NIMBUS-THRIFT-PORT)))
new Args(serverTransport) -> (TNonblockingServerSocket...) (THsHaServer$Args.)
new Args(serverTransport).processor(processor) -> (TNonblockingServerSocket...) (THsHaServer$Args.) (.processor (Nimbus$Processor. ..))
TServer server = new TSimpleServer(new Args(serverTransport).processor(processor)); server (THsHaServer… options)
server.serve(); (.serve server)

service-handler可是一个大家伙。对比一下 service-handler可以发现,在storm.thrift中的定义的Nimbus服务,
其接口在 service-handler中一一得以实现。 以下是storm.thrift中关于service Nimbus的声明。
storm-core/storm.thrift

namespace java backtype.storm.generated
service Nimbus {
  void submitTopology(1: string name, 2: string uploadedJarLocation, 3: string jsonConf, 4: StormTopology topology) throws (1: AlreadyAliveException e, 2: InvalidTopologyException ite);
  void submitTopologyWithOpts(1: string name, 2: string uploadedJarLocation, 3: string jsonConf, 4: StormTopology topology, 5: SubmitOptions options) throws ...;
  void killTopology(1: string name) throws (1: NotAliveException e);
  void killTopologyWithOpts(1: string name, 2: KillOptions options) throws (1: NotAliveException e);
  void activate(1: string name) throws (1: NotAliveException e);
  void deactivate(1: string name) throws (1: NotAliveException e);
  void rebalance(1: string name, 2: RebalanceOptions options) throws (1: NotAliveException e, 2: InvalidTopologyException ite);

  // need to add functions for asking about status of storms, what nodes they're running on, looking at task logs
  string beginFileUpload();
  void uploadChunk(1: string location, 2: binary chunk);
  void finishFileUpload(1: string location);
  string beginFileDownload(1: string file);
  binary downloadChunk(1: string id);       //can stop downloading chunks when receive 0-length byte array back

  string getNimbusConf();                   // returns json
  ClusterSummary getClusterInfo();          // stats functions  
  TopologyInfo getTopologyInfo(1: string id) throws (1: NotAliveException e);
  string getTopologyConf(1: string id) throws (1: NotAliveException e); //returns json
  StormTopology getTopology(1: string id) throws (1: NotAliveException e);
  StormTopology getUserTopology(1: string id) throws (1: NotAliveException e);
}

这个文件还指定了其他一些struct结构的数据类型, 比如StormTopology, TopologySummary, ClusterSummary, TopologyInfo等.
编译storm.thrift文件生成的代码在namespace指定的位置: backtype.storm.generated
storm-core/genthrift.sh

thrift7 --gen java:beans,hashcode,nocamel --gen py:utf8strings storm.thrift

现在来回顾下storm的thrift RPC的整体流程.
1. 编写 storm.thrift
2. 编译 genthrift.sh, 会在backtype.storm.generated生成Nimbus.java接口类. 其中含有内部类Iface(Service), Processor(Server), Client(Client)
3. Service服务类: nimbus.clj中的service-handler方法的返回值. 其应该实现Nimbus.Iface接口. 所以service-handler使用reify Nimbus$Iface
4. Server服务端: launch-server!中创建thrift的TServer, 并启动. 使用了Nimbus.Processor, 传入service-handler自定义服务实现类
5. Client客户端: StormSubmitter中localNimbus!=null时, 使用NimbusClient即Nimbus.Client调用RPC定义的接口方法

注意: 对于本地模式, 在StormSubmitter中直接使用Nimbus.Iface localNimbus对象. 这个对象的实现类应该就是service-handler.
对于分布式模式, StormSubmitter作为客户端, 会通过client调用RPC定义的接口方法. 即storm.thrift中定义的方法. 所以service-handler要实现这些方法!