Ambari Server 架构图,由图中看,主要有4部分:
Resource Service:资源服务,用来接收前端的 Rest 请求。关于 Resource 的几个基本概念:
- Resource:Ambari Server 定义了各种各样的 Resource,比如 Config、User、Cluster、
- Component、Alert 等都是一种 Resource。
- Resource Type:每种 Resource 都对应一个 ResourceType,标记所属的资源类型。
- Resource Service:每种 Resource 都对应一个 Resource Service,比如ConfigService、UserService等,Service 中定义了相对应 Resource 的 Rest API。
- Resource Provider:每种 Resource 都对应一个 ResourceProvider,比如ConfigResourceProvider、UserResourceProvider等,对 Resource 的具体操作,都封装在 Provider 中。
HeartBeatHandler:处理 Agent 的 Heartbeat 请求。
ActionQueue:每个 Host 都有一个 ActionQueue 记录着需要这台 Host 执行的命令。
FSM:维护组件状态的有限状态机。
简述一下 Ambari Server 的工作流程:
前端请求处理流程:前端提交一个 Rest 请求,相应 Resource 的 Service 处理请求,根据 ResourceType 找到对应的 ResourceProvider 执行具体的操作;如果存在需要 Agent 执行的操作,则把操作存储到相应 Host 的 ActionQueue 中;如果需要改变组件的状态,则需要操作 FSM。
Agent 请求处理流程:Agent Heartbeat 每10秒执行一次,Heartbeat Request 会携带命令的执行情况、组件状态以及 Host 状态等信息,HeartBeatHandler 会根据汇报上来的命令执行情况,去操作 FSM 来维护组件的状态;HeartBeatHandler 会从 ActionQueue 中取出需要 Host 执行的命令、修改的配置、Alert 定义等信息,通过 HeartBeat Response 返回给 Agent 执行。
总体来说由于 Ambari Server 和 Ambari Agent 之间是通过短连接进行通信,所以 Server 无法把需要执行的命令,直接推送给相应的 Agent,所以需要 ActionQueue 来存储命令,然后通过 Heartbeat 把命令下发给 Agent 执行。