Ambari Server 架构图，由图中看，主要也是四部分：

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 请求。

ActionManager：管理 Action。每个 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 执行。

Ambari Server 架构