一、Ambari系统架构

Ambari框架采用的是Server/Client的模式，主要由两部分组成：ambari-agent和ambari-server。ambari依赖其它已经成熟的工具，例如其ambari-server 就依赖python，而ambari-agent还同时依赖ruby, puppet，facter等工具，还有它也依赖一些监控工具nagios和ganglia用于监控集群状况。

• ambari-server主要管理部署在每个节点上的管理监控程序。
• Ambari-agent 部署在监控节点上运行的管理监控程序。
• ambari-web 作为用户与 Ambari server 交互的。

二、Ambari-agent内部架构

Ambari-agent是一个无状态的，其功能分两部分：

• 采集所在节点的信息并且汇总发送心跳发送汇报给ambari-server。
• 处理ambari-server的执行请求。

因此它有两种队列：

1. 消息队列Message Queue，或称为ResultQueue。包括节点状态信息（包括注册信息）和执行结果信息，并且汇总后通过心跳发送给ambari-server。
2. 操作队列ActionQueue。用于接收ambari-server发送过来的状态操作，然后交给执行器调用puppet或Python脚本等模块执行任务。

三、Ambari-server内部架构

三种状态：

• Live Cluster State：集群现有状态，各个节点汇报上来的状态信息会更改该状态;
• Desired State：用户希望该节点所处状态，是用户在页面进行了一系列的操作，需要更改某些服务的状态，这些状态还没有在节点上产生作用;
• Action State：操作状态，是状态改变时的请求状态，也可以看作是一种中间状态，这种状态可以辅助LiveCluster State向Desired State状态转变。

Heartbeat Handler模块用于接收各个agent的心跳请求（心跳请求里面主要包含两类信息：节点状态信息和返回的操作结果），把节点状态信息传递给FSM状态机去维护着该节点的状态，并且把返回的操作结果信息返回给Action Manager去做进一步的处理。

Coordinator模块又可以称为API handler，主要在接收WEB端操作请求后，会检查它是否符合要求，stageplanner分解成一组操作，最后提供给ActionManager去完成执行操作。

因此，从上图就可以看出，Ambari-Server的所有状态信息的维护和变更都会记录在数据库中，用户做一些更改服务的操作都会在数据库上做一些相应的记录，同时，agent通过心跳来获得数据库的变更历史。

四、Ambari-web内部架构

Ambari-web使用了一个流行的前端Embar.js MVC框架实现，Embar.js是一个TodoMVC框架，它涵盖了现今典型的单页面应用（single page application）几乎所有的行为。

使用了nodejs

使用brunch 作为项目的构建管理工具

Brunch ,是一个超快的HTML5构建工具。它有如下功能：

（1）、编译你的脚本、模板、样式、链接它们。

（2）、将脚本和模板封装进common.js/AMD模块里，链接脚本和样式。

（3）、为链接文件生成源地图，复制资源和静态文件。

（4）、通过缩减代码和优化图片来收缩输出，看管你的文件更改。

（5）、并通过控制台和系统提示通知你错误。

Nodejs 是一个基于Chrome JavaScript运行时建立的一个平台，用来方便的搭建快速的易于扩展的网络应用，NodeJS借助事件驱动，非阻塞I/O模型变得轻量和高效，非常适合运行在分布式设备的数据密集型的实时应用。

Ambari-web 目录结构

目录或文件	描述
app/	主要应用程序代码。包括Ember中的view、templates、controllers、models、routes
config.coffee	Brunch应用程序生成器的配置文件
package.json	Npm包管理配置文件
test/	测试文件
vendor/	Javascript库和样式表适用第三方库。

Ambari-web/app/

目录或文件	描述
assets/	静态文件
controllers/	控制器
data/	数据
mappers/	JSON数据到Client的Ember实体的映射
models	MVC中的Model
routes/	路由器
styles	样式文件
views	试图文件
templates/	页面模板
app.js	Ember主程序文件
config.js	配置文件