任务体系架构

 

       N久没写东西了，贴下最近项目我那块的系统设计，主要是一个任务体系，用于执行可动态配置的不同算法。其中算法均运行于hadoop环境。任务框架的要求是，每种算法可配置，算法各个步骤可配置，算法结果可校验，算法结果可保存。并且提供对算法执行过程的管理、监控、异常获取、异常重做。

 

整个体系分为两块，一块是算法调度，即为，动态控制算法执行时间，主要用quartz框架实现。一块为算法执行，主要是自己用线程池实现。

 

所有算法配置的信息，由用户(算法工程师)设定，通过页面设置后存入数据库。当算法被调度以后，交由执行模块去运算。其中，每个运算，都与DB在交互，将实时信息写入DB中。

 

      废话不多说，先上图：

 

 

      上图为执行模块的整体架构，总体上是一个生产者/消费者模式。其中所有执行的信息，均存在DB中。总共涉及到4个环境，DB + 应用 + 网关 + hadoop。

 

      所有执行的step信息，都在DB中通过状态位来控制执行，具体表现为：waiting(等待执行)，executing(执行中)，exception(异常),over(正常执行结束)。step会分为多个类型，比如：普通步骤类型、索引生成类型、校验类型等待。每个不同的类型会对应不同的task。

 

      生产者的角色主要是PoolThread来扮演，PoolThread是一个不死轮询线程，每10s去轮询DB，将DB中所有等待执行的step信息获得。所有步骤获得后，都在TaskFactory中生产处对应的task。所有task，根据具体信息不同，通过RunnerFactory，分别注入对应的Runner之中。最终将所有的runner都放入线程池中运行。

    

      消费者的角色主要由线程池来扮演，ThreadPool获得runner以后，会按顺序执行Runner的before(),callTask(),after()。如果过程中出现任何异常，这会被handleException()捕获到。执行过程中执行状态，执行内容，执行结果都会实时刷新到DB中。以便监控、管理、重做。

    

其中，Task与Runner完全独立。Runner主要负责任务的流转。Runner中做前置后置通知，调用注入其中的task。运算什么样的内容，完全不关心。具体表现为，在before()中做校验，对执行内容加锁。在callTask()中调用task。在after()中，控制任务下一步流转到哪儿去。Task则相反，只负责执行具体内容，会由Task内部的execute()具体执行。Task只完成自己一个单独节点任务。既不关心上一步，也不关系下一步，流转等任何问题交由Runner负责。

类图过于复杂，不画了…….

 

     所有与hadoop的交互，都由一台独立的网关机器来交互。在此台网关上，启动了Thrift、Jetty的两个Server，提交job，操作hdfs等，均由Thrift来做。另外启了一个jetty的Server，主要负责通过http请求，完成文件的操作。

 

      所有在云梯上的执行的m/r、hive sql执行的结果，会根据DB中不同的配置，会将结果数据存在k-v系统 or 文件系统 or 索引中 or ……之中。

      另外一个时间调度模块，下次再写了……