1. 关于AGENT特性
1.1. AGENT特性的总结过程
1.1.1. 传统IDC时期
我们之前的网络环境中，数万台服务器集中在几个主要机房，机房之间有专线链接。
每一个机房都有hadoop集群，需要管理的服务器中都挂载了hadoop fuse。
IDC时期服务器的几个特点：
分成几个大的区域，区域之间有专线互联。
每个机房的IP进行了规划，不存在冲突的情况。
因为费用是固定的，不太注重费用的问题。
这时候我们定义对于机器的管理集中到了调用命令上，因为我们觉得对于机器的管理可以归纳成两个操作，
一个是获取数据，一个是执行指令。数据已经通过了一个共享文件系统得到了解决。
所以我们的AGENT功能集中在了调用指令和支持各样的插件上。
1.1.2. 用了部分公有云时期
随着公有云的兴起，云资源的使用变多，出现了几个现象：
机房分布的更多更广：不在局限于国内某几个大的区域。
区域内的服务器资源很少：资源不需要集中在某些地区，出现了某个区域资源很少的情况，用来做特定的业务。
不能保证每个区域都存在专线： 区域太多，不是每个区域都有必要专线打通。
不同区域的内网IP可能会出现被重复使用的情况：因为可能存在公司或者业务合并的问题， 不同区域之前可能使用了相同的内网IP。
这个时候我们沿用了之前的策略，把机器的管理集中在命令调用上，同时做了如下的调整：
AGENT调用方面，我们添加了代理的功能，保证可以调用通这些隔离区域下的机器。
数据获取方面，因为有些区域的机器比较少，没办法让每个区域都有一个共享的文件系统， 即使有文件系统，之前的同步和共享也是一个问题，这时候我们使用了一个更普遍的协议HTTP， 通过HTTP提供数据下载功能，然后在下载慢的地方添加代理，添加缓存。
1.1.3. 不再区分使用的是公有云还是IDC
在公有云上使用资源在某些角度上存在的很多的优势。随着业务的发展，在上一个阶段使用的方案中，
需要配置和维护的数据很多难以维护，我们需要维护两个网络链路，一个是调用机器使用的链路另一个是下载数据的链路。
不但维护的人力成本高，同时如果需要进行区域加速的时候，两边的链路需要单独处理。
最终我们的AGENT特性集中在：
轻： 云上可能会开了很低配置的机器，AGENT需要在低配机器上运行且不能影响业务。
简单： AGENT和代理合二为一，不用区分安装的是AGENT还是代理。
异常感知： 部分区域没有专线，在跨国调用的时候网络可能出现极端情况。客户端，服务端，中间网络 任何一方出现异常需要立即退出。
跨区域只同步一份数据，通过代理中转：跨区域传输数据不但延迟高，而且产生额外的费用，所以数据传输后会在入口处进行缓存,避免重复传输。
同区域进行多对多的拷贝： 为了加速数据同步的过程，在同区域进行数据同步时使用了多对多的方式。