一个通用应用运维管控平台的设计实现

2)远程服务器执行模式;远程服务器执行模式就是比较常规的将脚本发送到远程服务器上，并在远程服务器上执行的模式，这种模式需要选择所需要执行服务器列表，这里就需要依靠资源管理系统中的物理机管理功能了，可以通过某种方式对服务器进行手动分组或自动分组，然后执行的时候可以按照不同的维度(比如按ip选择，按机房选择，按业务选择，或按自定义组名选择)选择所需的服务器组，进而将脚本下发到这些服务器上执行。

总结一下，脚本执行功能比较基础，同时还包含三个子功能，这三个子功能放到配置管理里面去实现，后面会具体阐述：

1)脚本管理功能;用于管理用户上传的脚本和常用的基础脚本。

2)账户管理功能;用于管理具体的执行用户。

3)服务器分组功能;用于基于资源管理系统的物理机管理数据按照某种方式划分成一定的服务器组。

说完具体的功能之后，我们需要确定具体的实现方式，准确的说，实现方式有两种：

1)SSH远程执行;可以通过封装ssh和paramiko的方式实现，python中的ansible和fabric包也都支持远程SSH执行的功能。Shell就用ssh命令即可。

该方式对中心节点要求比较高，每一个远程执行命令都会在中心节点启动一个进程(线程)来执行，对中心机的压力较大，同时由于是基于SSH的原理，故命令执行的效率较差，命令执行时间长。

2)Agent执行;在每台服务器上部署一个Agent，用户执行管控系统发送的脚本。这种方式的优点是可以采用拉的方式，由各个子节点订阅分给自己的任务，执行完成后再讲结果推给中心节点的数据;当然也可以像SSH方式通过推的方式由中心节点将任务发给远程的Agent，然后Agent去执行，并将结果反馈给中心节点。这种方式的执行效率会比较高，可扩展性强，将来甚至可以通过该Agent进行配置或运行数据上报，对于配置管理也比较方便，缺点是需要开发Agent，Agent需要支持异步非阻塞模式，且需要维护每台服务器的Agent，包括部署和管理。

Python的saltstack软件就是通过Agent的方式实现的，需要在每台物理机上部署一个saltstack minion进程用于接受任务和执行任务，在每个中心机上部署saltstack master进程用于下发任务，saltstack master通过将任务下发到zeromq中从而实现各个minion获取任务并执行，同时saltstack也支持将任务执行结果存储到Redis等数据库中，便于后续的跟踪和查看。

不过Agent也可以通过自行开发的方式实现，线上所有的Agent大多都是这种原理，也都是自己实现的，不过具有一定的开发难度。

因此对于脚本执行的实现方式来看总结如下：

1)如果用SSH的方式，使用python的ansible api或fabric。

2)如果用Agent的方式，可以考虑使用Python的saltstack minion Agent。

3)如果用自研Agent的方式，可以使用golang。上面两种方式相对快速容易实现，这种方式会有一点的时间消耗，不过可以积累一定的开发经验。

2. 文件分发：

文件分发是除了脚本执行的另一个基础功能，该功能的技术描述就是将某台服务器上的某个或某些文件，传输到其他的某个或某些服务器的某个位置上。

文件分发功能分为以下两个子功能，相关文件和模板的管理工作放到配置管理中去实现，这里只介绍如何实现文件分发：

1)普通文件分发，如代码包，镜像文件，软件包等。

2)模板文件分发，如配置文件等。

模板文件分发与普通文件分发不同的区别是模板文件中存储变量替换的逻辑，这里普通文件的管理和模板文件的管理以及配置变量的管理都放到配置管理系统中去实现，用户选择文件下发的时候可以选择是普通文件还是模板文件，如果是模板文件就会自动去加载配置管理中的变量管理生成临时的普通文件并下发。

具体的下发方式也分为两种：

1)管理机文件下发到普通的业务物理机上。

其实大部分的文件分发场景应该都是这一种，也就是我们将基础文件或模板文件放到管理机上，作为我们的基准文件，比如我们的部署代码，软件包等等，我们只要保证管理机上的文件版本的一致性，就可以保证普通的业务物理机上面的文件和管理机上的文件一致，也就是配置管理功能的中的文件版本一致性管理。

这种模式下的文件可能相对容量较小，比如小文件(几k)，软件包(几M)，或者稍大文件(几G)，文件从管理机下发到某些业务物理机上面临的问题是并发导致的传输速度问题，小文件情况下还可以忽略，基本可以在秒级完成，但稍大文件的传输就会有时间问题，随着业务物理机的个数增加而增加，因此这种情况会有并发和流量的控制。

另外文件的传输会提前进行文件md5的对比判断，如果文件的md5值相同，那就没有再传输文件的必要，在稍大文件情况下可以节省较多的时间。

文件传输，可以使用ansible的copy模块，或者salt的文件file模块，当然也可以自研方式中封装rsync的方式，rsync支持文件md5值校验以及断点续传等方式。

2)物理机之间的文件互传。

物理机之间的文件互传准确的来说是反配置管理逻辑的，这种方式就和我们现在的文件传输方式很类似，也就是从一台服务器scp文件到另一台服务器上。对于配置文件和小文件、软件包等需要配置管理的文件来说，我们需要明确禁止使用这种方式。但这种方式的好处就是可以用来P2P的传输较大的文件，比如几百G的镜像文件。

对于几百G的镜像文件来说，如果使用第一种管理机管理的方式，只能1对多的传输将会造成传输时间的极大占用，而使用这种P2P的方式，即可以极大的提升文件传输的速度。

物理机之间的文件互传使用rsync即可，由于文件较大，且可能出现断点，rsync是比较方便的解决大文件传输的方法，需要在每台服务器上的Agent上对rsync功能进行封装，支持Agent之间的rsync文件互传。

物理机文件中需要管理的文件列表，可以通过Agent汇报到配置管理系统中，用户选择文件分发的时候，可以选择配置管理系统中的点对点大文件传输功能，配置管理系统中可以自动选择传输源，针对被传输物理机的个数，实现真正的点对点传输，不需要用户自己去选择源文件服务器，可以节省大量的人为运维操作。

3. 批量执行：

所谓的批量执行功能就是上面两个基础功能中在选择目的服务器的个数的时候支持多个服务器，而不是只能选择单个服务器。