Ambari 利用了已有的优秀开源软件，并结合起来 :

agent 端，采用了 puppet 管理节点
在 web 端，采用 ember.js 作为前端 MVC 框架和 NodeJS 相关工具，用 handlebars.js 作为页面渲染引擎，在CSS/HTML方面还用了 Bootstrap 框架
在 Server 端，采用了Jetty、Spring、JAX-RS 等
同时利用了 Ganglia、Nagios 的分布式监控能力

Ambari 框架采用的是 Server/Client 的模式 :

ambari-agent : 依赖ruby，puppet，fecter等工具 , 监控工具 : nagios 和 ganglia
ambari-server : 依赖 python
ambari-web : 用户与 Ambari server 交互的
puppet : 分布式集群配置管理工具，Server/Client模式，能够集中式管理分布式集群的安装配置部署，主要语言是ruby
facter : 用 Python 写的一个节点资源采集库，用于采集节点的系统信息，如 : OS 信息，由于 ambari-agent 主要是用 Python 写的，所以用 facter 可以很好的采集到节点信息

项目目录

目录	描述
ambari-server	Ambari 的 Server 程序，主要管理部署在每个节点上的管理监控程序
ambari-agent	部署在监控节点上运行的管理监控程序
Contrib	可视化工具的代码及一些通用的工具代码
ambari-web	Ambari 页面 UI 的代码，作为用户与 Ambari server 交互的
ambari-views	用于扩展 Ambari Web UI 中的框架
Docs	文档
ambari-common	Ambari-server 和 Ambari-agent 共用的代码
ambari-metrics	在Ambari所管理的集群中用来收集、聚合和服务Hadoop和系统计量
ambari-admin	admin界面管理代码
ambari-project	编译代码使用的公用代码
ambari-shell	命令行代码包括shell及python
ambari-funtest	功能测试代码
ambari-logsearch	日志管理代码

Ambari系统架构

在 ambari-server 开放的 Rest API 分为两大类 API :

Master 模块接受 API 和 Agent Interface 的请求，完成 Ambari-server 的集中式管理监控逻辑，而每个 agent 节点只负责所在节点的状态采集及维护工作

架构的四部分：

Brower : 前端，前端通过 HTTP 发送 Rest 指令和 Ambari Server 进行交互
Ambari Server : 一个 web 服务器，开放两个端口，分别用于和前端、Agent 进行交互。Ambari Server 的数据存储在 MySQL 中
Metrics Collector : 一个 web 服务器，提供两个功能，一方面将 Metrics Monitor 和 Metrics Sink 汇报上来的监控信息存储到 HBase 中，另一方面提供监控信息查询接口，供 Ambari Server 进行查询
Host : 实际安装大数据服务的主机，可以有多台。每台主机都安装有一个 Ambari Agent 服务和 Metrics Monitor 服务，当有些组件需要更详细和特有的监控信息，可以集成相应的 Metrics Sink（如 : HDFS 的 Metrics Sink 监控空间的使用情况）

两条业务线 :

核心业务：集群的统一部署、管理以及基本的监控（如 : 组件的存活情况）都是由这条线来完成的，由前端、Ambari Server 和 Ambari Agent 组成。前端提供可视化界面，发送操作指令；Ambari Server 维护着整个集群的状态；Ambari Agent 执行具体的指令去操作服务和组件，而且会通过心跳汇报 Host 和服务的状态信息
Metrics 监控业务：提供详细的监控功能，由 Metrics Collector、Metrics Monitor、Metrics Sink 组成。Metrics Collector 存储监控信息，并提供查询接口；Metrics Monitor 主要负责收集并汇报 Host 相关的指标，如 : 主机的 CPU、内存、网络等；Metrics Sink 负责收集并汇报组件的相关指标，如 : 该组件的 CPU 使用率，内存使用情况

Resource Service：资源服务，用来接收前端的 Rest 请求

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 执行