Ambari采用的不是一个新的思想和架构，也不是完成了软件的新的革命，而是充分利用了一些已有的优秀开源软件，巧妙地把它们结合起来，使其在分布式环境中做到了集群式服务管理能力、监控能力、展示能力。这些优秀开源软件有：
- 在agent端，采用了puppet管理节点;
- 在Web端，采用了ember.js作为前端的MVC构架和NodeJS相关工具，用handlebars.js作为页面渲染引擎，在CSS/HTML方面还用了Bootstrap 框架;
- 在Server端，采用了Jetty, Spring，Jetty，JAX-RS等;
- 同时利用了Ganglia，Nagios的分布式监控能力。
一、Puppet
在Agent节点上，它所有的状态更改操作，都是通过Puppet来完成。Agent相关软件包的安装部署是由python完成，Agent端的包升级操作由Python和Puppet组合完成。例如，如果在页面上进行启动HDFS服务，那么最终在某个Ambari-Agent端会执行类似如下命令：
- /usr/lib/ambari-agent/lib/puppet-2.7.9/bin/puppet apply --confdir=/var/lib/ambari-agent/puppet --detailed-exitcodes /var/lib/ambari-agent/data/site-83.pp
其中site-83.pp 是manifestGenerator.generateManifest方法产生的puppet脚本文件，这个文件里主要完成一x些xxx-site.xml文件的配置工作，最后几行是完成puppet启动namenode的执行逻辑。
- #04.09.2013 15:52:26
- import '/var/lib/ambari-agent/puppet/modules/hdp/manifests/*.pp'
- # 省略一堆import...
- # 省略一堆xxx-site.xml里面的参数配置项...
- $hadoop_pid_dir_prefix = '/var/run/hadoop'
- $zookeeper_sessiontimeout = '60000'
- $dfs_include = 'dfs.include'
- ＃执行节点 默认
- node /default/ {
- # 共分两步
- stage{1 :} -> stage{2 :}
- ＃第一步是 准备启动阶段，进行一系列的检查 和配置更新
- class {'hdp': stage => 1}
- # 第二步是 执行namenode的启动工作。
- class {'hdp-hadoop::namenode': stage => 2, service_state => running}
- }
二、Ember.JS
自从Node.JS出来之后， JavaScript就变得更加神奇了。在前端可以控制页面展示，在后台可以当作服务器。尤其在前端的迅猛发展，不断散发出其无穷无尽的魅力，难怪有人说不懂点JS就不是纯正的攻城师。
Ember.JS是在浏览器前端构建的JS MVC框架，简单易用。它需要你创建一个Ember.Application实例，这个实例里有许多动态对象，MVC的功能就是通过这些动态对象之间相互交互来完成。
- // Creates an application instance.
- App = Ember.Application.create({
- LOG_TRANSITIONS: true
- });
具体如何使用，请下载本文附件。
三、Nagios & Ganglia的使用
如果要观看漂亮的监控图，它就需要依赖nagios和ganglia了，一旦安装成功，ambari-server就直接用http请求的方式向nagios和ganglia请求数据。
ganglia有直接的请求json数据的地址，格式如下：
http://localhost/ganglia//graph.php?g=load_report&json=true
nagios没有直接请求数据的功能，因此ambari实现了一段php代码用来读取服务的json数据，请求地址如下：
http://localhost/ambarinagios/nagios/nagios_alerts.php?q1=alerts&alert_type=all
四、Ambari-Server中的伪“插件”机制
Ambari-Server提供了多种类型的操作和服务，不同的操作对应不同的BaseProvider实现类和Definition实现类。如果要添加新的操作，就要依次实现对应Provider和Definition。这些操作类会统一加载进来。详情可以查看相关类的代码，例如：org.apache.ambari.server.controller.internal.AbstractControllerResourceProvider和org.apache.ambari.server.api.resources.ResourceInstanceFactoryImpl。这种实现机制在Ambari-Server这一层有点类似把服务当作插件来完成，但是也没有完全做到插件那么灵活，只需要实现某些类，配置某些参数就可以实现一个服务或操作。
五、改进思考
熟悉完Ambari的架构，运行逻辑和一些开源软件后，让我想到Hadoop的使用习惯选择，及其Hadoop 1.x 和Hadoop 2.x+的差别。
5.1. “Yarn”化？
Hadoop为了解决计算模型多样化的问题，能够在同一存储系统上实现多种计算模型，Hadoop 2.x+添加了Yarn框架。准确地说，Yarn框架是那些计算模型的共性部分（控制管理部分）抽象出来，产生出一个新的通用的计算管理控制器。在Hadoop 1.x 中只有MapReduce框架，现在常称之为MapReduce V1。Hadoop 2.x+把计算模型的计算部分和控制部分分离开来，把控制部分交给Yarn，把计算部分交给各个计算模型实现（MapReduce模型实现就成为了MapReduce V2）。同时可以在Yarn上实现其它计算模型，例如：实时计算模型Storm，图计算模型BSP。
想一想Ambari现在只能管理着Hadoop及其生态系统，如果需要其管理监控Storm集群，显然现在无法达到。对于不同服务，例如无论是hadoop服务还是storm服务，都有着其共性部分，把其共性部分单独抽取出来，形成一个组件，然后运维人员只需要实现其具体操作。这样一来Ambari又是一款真正伟大的产品。
5.2. 做到简单的手动安装升级？
有人会说，Ambari现在都强大到能做到自动部署升级，那么就很容易做到手动部署升级的？还有人说，既然都已经自动部署了，为什么还要手动部署呢？
5.3. 做到用自己已经装好的hadoop集群？
现在ambari只能从头开始，安装自己的hadoop版本。如果现在已经有了hadoop集群，那么ambari就很难支持了。如果把ambari的多种功能进行分解，形成一组互相衔接的模块，那就更容易自定义hadoop集群。对于系统工程师来说，添加一点麻烦是能够接受的。