一、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	配置文件