标签：
最近有大概半个月的时间可以重构下代码，刚好可以重新整理下Job Service相关的代码。前段时间由于忙于完成Job Service所有功能以及完成对Auto Job的支持以正常上线，使得有些地方的代码写得不是特别优雅。主要集中在以下一些地方：
DAG状态的转移
目前DAG状态分为3层，分别为ApplicationStatus、TaskStatus、InstanceStatus。每个层次都有以下几种状态，Waiting、Running、Finished、Stopped、Failed。并且DAG有如下几种事件会导致状态转移：TA_RUNNING、TA_FAILED、TA_FINISHED、OP_STOP、OP_START、TK_EXPIRED，除了这些之后可能会增加新的事件。
因此，DAG的状态转移是Job Service模块中比较复杂的。目前的处理方式比较原始，使用大量的switch......case，这样使得代码可维护性特别差。尤其是新增加了对Auto Job的支持，而且Auto Job会根据状态的转移而涉及到一系列对Cluster的操作，包括CreateCluster、DeleteCluster、ResetClusterInstance、KillClusterInstance。这样使得大量涉及Cluster的操作也包括在大量switch......case语句中。使得这块的代码重构迫在眉睫。
目前的想法是使用Yarn的StateMachine + Dispatcher + EventHandler方式重构下DAG状态机。
Auto Cluster生命周期的管理
目前对于Auto Cluster有一个专门的ClusterManager对象去维护。ClusterManager对象会在创建的时候或者有Task Finished的时候，创建所有入度为0并且是Auto Cluster的结点；在有结点终结（包括Stopped、Finished、Failed等状态）的时候会Delete Auto Cluster；根据Instance是重启还是结束选择Reset还是Kill Instance。这样使得Auto Cluster的管理随着DAG状态转移而特别分散，特别难以维护。
对于Auto Cluster生命周期管理，也是使用StateMachine模式。
类关系以及职责的明确
一直感觉目前的类相互间的依赖关系有点混乱，比如：
DAGApplication包含DAGStatus、DAGTokenManager、DAGDescription、ClusterManager等类对象。
DAGStatus依赖DAGDescription，并且Create的时候把DAGDescription作为入参。
DAGTokenManager依赖于DAGDescription、DAGStatus。
ClusterManager依赖DAGDescription、DAGStatus。
这些类之间关系非常复杂，导致出现问题特别难排查。
有点想根据Yarn RMAppImpl以及apache tez中的DAG相关代码把这部分代码重构下，但是目前还没有特别具体的计划。只能先把状态机部分代码重构完再说吧！
标签：
原文地址：http://www.cnblogs.com/bitCoin/p/5131937.html
