CompositeService 多个service封装，service定义了状态机状态改变的合法情况。
重要的方法是（子类需要实现的）：serviceStart,serviceInit,serviceStop
里面的服务有:
Dispatcher,ClientRMService,ApplicationMasterService,AplicationMasterLauncher,AdminService,ContainerAllocationExpire,NMLivenessMonitor,NodeListManager
Context每个服务对应有context。
子类定义serviceInit,ServiceStart,ServiceStop
继承的init,start,stop直接调用。
AbstractLivelinessMonitor父类，定义了monitor的一些基本操作。
这些服务的特点都是围绕dispatcher。
RMDispatcher有个register方法进行注册，将相应的Event以及对应的handler进行注册。
不出所料，里面很多服务都有queue，大多数都是异步完成。
Token之类的没有使用，暂时不用考虑。
Event Type Handler
RMAppEvent RMAppEventType ApplicationEventDispatcher
RMStateStoreAppEvent 同上，是子类
RMAppAttemptEvent RMAppAttemptEventType ApplicationAttemptEventDispatcher
SchdulerEventType SchedulerEventDispatcher
RMNodeStatusEvent
状态机
StateMachineFactory<OPERAND, STATE extends Enum<STATE>, EVENTTYPE extends Enum<EVENTTYPE>, EVENT>
通过状态机把所有的状态转变都建立好后，在状态改变后自动执行。
1、Dispatcher里面有个queue，将所有的请求。
每个注册到Dispatcher的类最后都能够获得一个dispatcher的handler，用于将Event传入到Dispatcher的queue中，有可能有一个，也可能有多个handler，根据注册情况。
Dispatcher内部有个线程用于将queue中得Event根据注册的handler,dispatch到不同的类去处理。有些是同步有些是异步。
2、ResourceScheduler
3、ClientRMService
(1)实现的是ApllicationClientProtocol，完成的是client向Server(ResourceManager）的信息传输。
client submit一个job以后，提交到ClientRMService中，首先将该job,向RMAppManager submit这个job。
经过token，ACL验证。
然后交给Dispatcher进行处理，Event是RMAppEvent,Type的enum是RMAppEventType。
这个时候返回给Client端。
(2)生成一个RMApp类，代表一个application。向Dispatcher发送一个请求
RMAppEvent(applicationId, isRecovered ? RMAppEventType.RECOVER:
RMAppEventType.START));
这里面的EventType为RMAppEventType.START。RMAppEvent对应的Handler为ApplicationEventDispatcher。
RMStateStore指的是是否存储状态。
在RMAppImpl中，状态转变通过EventType确定。
(3)随后进入RMStateStore中，生成一个ApplicationState状态，内部处理，内部进行handle,储存相应的state信息，如果不是可以recovery的话就是只打log。
随后出发RMAppEvent type的event,该Event的type是RMAppEventType.APP_SAVED
(4)随后代码流程重新进入RMAppImpl中，根据type，状态机流转到从State NEW_SAVING到SUBMITTED,执行StartAPpAttemptTransition()
createNewAttempt(true);
(5)随后生成RMAppAttempt对象，根据id等等，把需要的参数加入。
随后进入RMAppAttemptImpl类的状态机，实现类是RMAppAttemptImpl
根据其状态机转变从RMAppAttemptState.NEW到RMAppAttemptState.SUBMITTED
transition类是AttemptStartedTransition类。
首先获取时间戳
进入ApplicationMasterService,该Service目的是沟通ApplicationMaster和ResourceManager。
registerAppAttempt注册该ApplicationAttempt。
然后进入scheduler阶段
(6)在Scheduler阶段，首先是APP_ADDED
先不管内部逻辑，随后又进入到RMAppAttemptImpl中得状态转变
(7)EventType是RMAppAttemptEventType.APP_ACCEPTED,执行的transition类为ScheduleTransition类
它的行为是将首先将RMAppimpl的状态从submit调整到APP_ACCEPTED，没有行为。
随后在scheduler中分配资源，返回一个allocate对象。
至此client结束任务，下一步的任务不需要client参与了。
当NodeManager向ResourceManager汇报心跳的时候，RM会找到需要分配的资源，通过scheduler的方法去分配。在AppSchedulable方法中的assighContainer将该container assign到node中。同时通知该node需要去launch得app。这步是rm 和 nm进行通信完成的，相当于rm向nm申请ApplicationMaster的Container。
NodeManager与ResourceManager通信
协议是ResourceTracker，实现类是ResourceTrackerService