应用程序的自动变更方法、系统、装置及存储介质与流程

本发明涉及计算机技术领域，更为具体而言，涉及一种用于应用系统中应用程序的自动变更方法、系统、装置及存储介质。

背景技术：

随着信息技术日新月异的发展，互联网技术深入人们日常生活的每一个角落。目前，以数据驱动业务的模式迅速发展，也来越多的企业建立起相应的数据中心，并将其作为整体信息化架构的重要核心。在今后的发展中，数据中心将会成为企业竞争的资产，商业模式也会因此发生改变。

目前，随着数据中心系统规模的扩大以及业务快速发展的需要，数据中心的运行维护一直是一种耗费人力且操作复杂的工作。由于业务发展的需求，应用系统的变更日益频繁，同时，数据中心的规模也在不断地扩大，导致变更所涉及的主机规模也不断扩大。因此，应用系统中应用程序的变更是数据中心系统日常运维中最耗费人力的一项工作。尽管目前通过使用自动化运维工具(如云管理平台)具备了批量化的变更实施能力，但是由于存在变更的实施工艺不标准、不规范，运维平台之间(云管理平台与监控平台)没有实现数据打通等问题，导致目前在变更实施过程中仍然存在较多人为操作，导致整体执行过程自动化程度低，人工依赖程度高，变更实施效率低下，并且由于存在较多的人工操作，使人力资源日趋紧张，变更实施风险也相应的增加。

技术实现要素：

为了解决现有技术中存在的上述问题，本发明提供了一种用于应用系统中应用程序的自动变更方法、系统、装置及存储介质，以实现应用程序的变更全程自动化执行。

根据本发明的实施方式，提供了一种用于应用系统中应用程序的自动变更方法，所述应用系统至少由一个主机组成，其特征在于，所述方法包括：获取分组列表，所述分组列表记录了本次自动变更过程中待变更的应用程序的应用信息，其中，所述应用信息包含所述应用程序的名称、变更所涉及的主机范围、变更参数和应用序号；从所述分组列表中选取所述应用序号最小的应用信息组成待执行的分组；检查所述待执行的分组是否满足前置条件，若满足所述前置条件，则根据所述待执行的分组向本次变更所涉及的主机发送变更指令；接收到所述变更指令的所述主机根据所述变更指令执行变更脚本实现所述应用程序的自动变更，其中，所述变更脚本包含根据所述待变更的应用程序预先从统一配置的执行操作中选取的操作，并存储于预设的位置；所述变更脚本执行完成后，检查所述分组是否满足执行后等待时间，若满足，执行交易检查。

在本发明的一些实施方式中，所述执行操作是根据预设的编写标准编写的，其中，将所述执行操作中不会根据所述待变更的应用程序的不同而产生变化的操作封装为原子操作，将所述执行操作中特定于所述待变更的应用程序的操作作为可选操作。

在本发明的一些实施方式中，所述可选操作包括：应用停止、自定义备份、发布前执行、发布后执行、启动前执行、应用启动、启动后执行、版本检查和绿灯测试；所述原子操作包括：版本获取、版本备份、版本回退、版本发布和健康检查。

在本发明的一些实施方式中，所述方法还包括：检查所述自动变更方法的执行环境是否满足执行条件，若满足，设置进入监控维护期以屏蔽后续所述自动变更方法执行期间产生的警告事件；其中，所述执行条件包括：是否达到预设的变更开始时间；或，预设检查脚本是否运行成功；其中，若达到所述变更开始时间，则视为满足所述执行条件；或，若所述预设检查脚本运行成功，则视为满足所述执行条件。

在本发明的一些实施方式中，所述前置条件包括：所述分组是否达到预设的绝对依赖时间；或，前置分组是否执行完成，所述前置分组指在执行本次所述分组前执行的上一个分组；其中，若达到所述绝对依赖时间，则视为满足所述前置条件；或，若所述前置分组中所有变更步骤执行完成，则视为满足所述前置条件。

在本发明的一些实施方式中，所述执行交易检查包括：检查交易情况及资源使用情况是否正常；所述交易情况包括：交易量、交易成功率和交易响应时间中的一种或多种的组合；所述资源使用情况包括：cpu、内存、网络、存储、进程和端口中的一种或多种的组合的使用情况。

在本发明的一些实施方式中，所述方法还包括：根据所述分组列表获取相应的应用版本包，所述应用版本包包括分发配置定义文件和应用文件版本包；根据所述分发配置定义文件将所述应用文件版本包分发至对应的所述主机的目标路径；其中，所述应用文件版本包包括所述变更脚本；所述目标路径记录于所述分发配置定义文件中。

在本发明的一些实施方式中，所述应用版本包还包括验证文件，用于验证所述应用版本包是否异常。

在本发明的一些实施方式中，根据所述分发配置定义文件将所述应用文件版本包分发至对应的所述主机的目标路径前，所述方法还包括：根据所述分发配置定义文件检测所述目标路径下是否存在文件；若存在，将所述目标路径下的文件拷贝至预设的备份目录中，并将相应的所述目标路径记录至预设的备份文件中，并标记为recover；否则，将相应的所述目标路径记录至所述备份文件中，并标记为add；其中，所述备份文件存储于所述备份目录中。

在本发明的一些实施方式中，所述方法还包括：根据映射列表确定本次变更涉及的所述主机对应的测试主机，向所述测试主机发送变更指令；接受到所述变更指令的所述测试主机根据所述变更指令执行所述变更脚本实现所述应用程序的自动变更。

同时，本发明提供了用于应用系统中应用程序的自动变更系统，所述应用系统至少由一个主机组成，其特征在于，所述系统包括：分组列表获取模块，用于获取分组列表，所述分组列表记录了本次自动变更过程中待变更的应用程序的应用信息，其中，所述应用信息包含所述应用程序的名称、变更所涉及的主机范围、变更参数和应用序号；分组模块，用于从所述分组列表中选取所述应用序号最小的应用信息组成待执行的分组；执行前条件检查模块，用于检查所述待执行的分组是否满足前置条件；执行模块，用于根据所述待执行的分组向本次变更所涉及的主机发送变更指令，使接收到所述变更指令的所述主机根据所述变更指令执行变更脚本实现所述应用程序的自动变更，其中，所述变更脚本包含根据所述待变更的应用程序预先从统一配置的执行操作中选取的操作，并存储于预设的位置；执行后条件检查模块，用于所述变更脚本执行完成后，检查所述分组是否满足执行后等待时间，若满足，执行交易检查。

在本发明的一些实施方式中，所述执行操作是根据预设的编写标准编写的，其中，将所述执行操作中不会根据所述待变更的应用程序的不同而产生变化的操作封装为原子操作，将所述执行操作中特定于所述待变更的应用程序的操作作为可选操作。

在本发明的一些实施方式中，所述可选操作包括：应用停止、自定义备份、发布前执行、发布后执行、启动前执行、应用启动、启动后执行、版本检查和绿灯测试；所述原子操作包括：版本获取、版本备份、版本回退、版本发布和健康检查。

在本发明的一些实施方式中，所述系统还包括：监控设置模块，用于检查所述自动变更系统的执行环境是否满足执行条件，若满足，设置进入监控维护期以屏蔽后续所述自动变更系统执行期间产生的警告事件；其中，所述执行条件包括：是否达到预设的变更开始时间；或，预设检查脚本是否运行成功；其中，若达到所述变更开始时间，则视为满足所述执行条件；或，若所述预设检查脚本运行成功，则视为满足所述执行条件。

在本发明的一些实施方式中，所述前置条件包括：所述分组是否达到预设的绝对依赖时间；或，前置分组是否执行完成，所述前置分组指在执行本次所述分组前执行的上一个分组；其中，若达到所述绝对依赖时间，则视为满足所述前置条件；或，若所述前置分组中所有变更步骤执行完成，则视为满足所述前置条件。

在本发明的一些实施方式中，所述执行交易检查包括：检查交易情况及资源使用情况是否正常；其中，所述交易情况包括：交易量、交易成功率和交易响应时间中的一种或多种的组合；所述资源使用情况包括：cpu、内存、网络、存储、进程和端口中的一种或多种的组合的使用情况。

在本发明的一些实施方式中，所述系统还包括：准备模块，用于执行下述操作：根据所述分组列表获取相应的应用版本包，所述应用版本包包括分发配置定义文件和应用文件版本包；根据所述分发配置定义文件将所述应用文件版本包分发至对应的所述主机的目标路径；其中，所述应用文件版本包包括所述变更脚本；所述目标路径记录于所述分发配置定义文件中。

在本发明的一些实施方式中，所述应用版本包还包括验证文件，用于验证所述应用版本包是否异常。

在本发明的一些实施方式中，所述系统还包括：备份模块，用于在所述准备模块根据所述分发配置定义文件将所述应用文件版本包分发至对应的所述主机的目标路径前，执行下述操作：根据所述分发配置定义文件检测所述目标路径下是否存在文件；若存在，将所述目标路径下的文件拷贝至预设的备份目录中，并将相应的所述目标路径记录至预设的备份文件中，并标记为recover；否则，将相应的所述目标路径记录至所述备份文件中，并标记为add；其中，所述备份文件存储于所述备份目录中。

在本发明的一些实施方式中，所述系统还包括：测试模块，用于执行下述操作：根据映射列表确定本次变更涉及的所述主机对应的测试主机，向所述测试主机发送变更指令，使接受到所述变更指令的所述测试主机根据所述变更指令执行所述变更脚本实现所述应用程序的自动变更。

此外，本发明提供了一种用于应用系统中应用程序的自动变更装置，包括存储器和处理器，所述存储器用于存储一条或多条计算机指令；所述处理器用于调用并执行所述一条或多条计算机指令从而实现前述任一项的自动变更方法。

本发明还提供了一种计算机存储介质，存储有一条或多条计算机程序，所述一条或多条计算机程序在执行时实现前述任一项的自动变更方法。

由于本发明中变更脚本包含根据待变更的应用程序预先从统一配置的执行操作中选取的操作，使得应用程序的变更工艺变得统一规范，导致即便在不同的应用系统中变更不同的应用程序，也可以使用同一套方案实施变更，极大的降低了人工的干预。因此，采用本发明能够实现应用程序的变更全程自动化执行，减少执行过程中的人工依赖，同时，达到提高变更实施的自动化水平，降低变更人力投入，提高变更实施的质量和效率的目的。

附图说明

为了便于理解本发明，以下通过具体实施方式并结合附图对本发明进行具体说明。

图1是根据本发明实施方式的一种用于应用系统中应用程序的自动变更方法的流程示意图；

图2是根据本发明实施方式的另一种用于应用系统中应用程序的自动变更方法的流程示意图；

图3是根据本发明实施方式的另一种用于应用系统中应用程序的自动变更方法的流程示意图；

图4是根据本发明实施方式的一种用于应用系统中应用程序的自动变更系统的框图；

图5是根据本发明实施方式的另一种用于应用系统中应用程序的自动变更系统的框图；

图6是根据本发明实施方式的另一种用于应用系统中应用程序的自动变更系统的框图；

图7是根据本发明实施方式的另一种用于应用系统中应用程序的自动变更系统的框图；

图8是根据本发明实施方式的另一种用于应用系统中应用程序的自动变更系统的框图。

具体实施方式

以下结合附图和具体实施方式对本发明的各个方面进行详细阐述。其中，众所周知的模块、单元及其相互之间的连接、链接、通信或操作没有示出或未作详细说明。并且，所描述的特征、架构或功能可在一个或一个以上实施方式中以任何方式组合。本领域技术人员应当理解，下述的各种实施方式只用于举例说明，而非用于限制本发明的保护范围。还可以容易理解，本文所述和附图所示的各实施方式中的模块或单元或处理方式可以按各种不同配置进行组合和设计。

图1是根据本发明实施方式的一种用于应用系统中应用程序的自动变更方法的流程示意图，在本发明的实施方式中，参照图1，该方法包括：

100：获取分组列表；

该分组列表记录了本次自动变更过程中待变更的应用程序的应用信息，该应用信息包含应用程序的名称、变更所涉及的主机范围、变更参数和应用序号；

110：从分组列表中选取应用序号最小的应用信息组成待执行的分组；

120：检查待执行的分组是否满足前置条件，若满足，则执行处理130，否则重复处理120直至满足该前置条件；

130：根据待执行的分组向本次变更所涉及的主机发送变更指令；

140：接收到变更指令的主机根据该变更指令执行变更脚本实现应用程序的自动变更；

该变更脚本包含根据待变更的应用程序预先从统一配置的执行操作中选取的操作，并存储于预设的位置；

150：检查分组是否满足执行后等待时间，若满足，则执行处理160，否则重复处理150直至满足该执行后等待时间；

160：执行交易检查。

在本发明的实施方式中，执行交易检查包括检查交易情况及资源使用情况是否正常。其中，交易情况包括：交易量、交易成功率和交易响应时间中的一种或多种的组合；资源使用情况包括：cpu、内存、网络、存储、进程和端口中的一种或多种的组合的使用情况。

若检查无误，则结束变更流程；若检查发现存在异常，则发送告警通知给相关人员，同时基于预设异常场景进行自动化应急处置，例如：包自动回滚版本、重启应用服务等。

可选的，执行操作是根据预设的编写标准编写的，在本发明中提供一种实施方式，具体如下：

在本实施方式中，预先将应用程序的自动变更实施过程抽象为12步标准的执行操作，如下表所示：

表1

上述定义的12个执行操作中，将不会根据待变更的应用程序的不同而产生变化的操作封装为原子操作，将特定于待变更的应用程序的操作作为可选操作。

具体的，在本发明的实施方式中，版本获取、版本备份、版本回退、版本发布和健康检查由于其具体操作和待变更的应用程序无关，属于通用的执行操作。因此，为了方便调用及减少人工操作量，将该类执行操作封装为原子操作，需要使用时可以直接从系统中进行调用，无需事先进行准备。同时，提供通用的原子操作也更好地保障了执行操作的执行效果和质量。

而应用停止、自定义备份、发布前执行、发布后执行、启动前执行、应用启动、启动后执行、版本检查和绿灯测试由于在不同的应用程序变更中存在一定的差异，所以无法通用。对于该类执行操作，本发明的实施方式通过提供统一的编写模板，根据待变更的应用程序预先进行编写，作为可选操作。由此，在使得执行操作统一规范的基础上，降低了人为操作的工作量。同时，由于使用统一的编写标准，使得可选操作在不同的应用系统中可以统一调用，实现了不同平台之间的数据打通，工作人员可以轻易接手不同平台间的变更工作，也避免了重复准备相同功能的脚本的问题。

可选的，在执行处理110之前，可以检查该自动变更方法的执行环境是否满足执行条件，如果满足执行条件，则设置进入监控维护期以屏蔽后续所述自动变更方法执行期间产生的警告事件，准备开始执行该自动变更方法。

在本发明的实施方式中，给出两种执行条件的设置，具体如下：

(1)按时间设置，监控是否到达预设的变更开始时间，若到达预设的变更开始时间，则判定为满足执行条件，将启动变更执行，若未到达预设时间，则继续进行循环等待。

(2)按预设检查脚本，按一定的时间周期重复调用的预设检查脚本，若脚本执行后返回成功(例如，返回码为0)，则判定为满足执行条件，将启动变更执行，若返回失败(例如，返回码非0)，则判定为不满足执行条件，则继续进行循环等待。

同时，在本发明的实施方式中，通过分组列表确认本次变更所涉及的主机范围，通过调用服务接口，设置该主机范围内的主机进入监控维护期，屏蔽变更执行期间产生的警告事件。

可选的，在本发明的实施方式中，给出两种在执行处理120中的前置条件的设置，具体如下：

(1)基于绝对依赖时间的前置条件，监控当前时间，当当前时间到达预设的绝对依赖时间时，则判定为满足前置条件，将启动后续处理，若未到达预设时间，则继续进行监控等待。

(2)基于前置分组的前置条件，按一定的时间周期检查待执行分组的前置分组是否执行完成，当前置分组中所有变更步骤执行完成，则判定为满足前置条件，将启动后续处理，否则，继续进行循环等待。

可选的，如图2所示，在本发明的实施方式中，该自动变更方法还包括：

101：根据分组列表获取相应的应用版本包，该应用版本包包括分发配置定义文件和应用文件版本包；

102：根据分发配置定义文件将应用文件版本包分发至对应的所述主机的目标路径。

其中，应用文件版本包还包括变更脚本，目标路径记录于分发配置定义文件中。由此，实现将自动变更过程中需要用到的变更脚本分发至变更所涉及的主机。

可选的，应用文件版本包还可以包括验证文件，用于验证该应用版本包是否异常。优选的，该验证文件可以是记录了md5码的md5文件。

可选的，在执行处理101之前，还可以根据分发配置定义文件检测目标路径下是否存在文件；若存在，将目标路径下的文件拷贝至预设的备份目录中，并将相应的目标路径记录至预设的备份文件中，同时标记为recover；否则，将相应的目标路径记录至备份文件中，并标记为add；其中，备份文件存储于备份目录中。由此，实现对变更前的文件的备份，记录备份操作内容，以便版本回退时使用。

如图3所示，在本发明的实施方式中，该自动变更方法还包括：

103：根据映射列表确定本次变更涉及的主机对应的测试主机，向该测试主机发送变更指令；

104：接受到变更指令测试主机根据变更指令执行变更脚本实现应用程序的自动变更。

在正式的主机上进行变更前，通过在测试主机上进行测试，从而检验应用版本包、变更脚本是否满足标准化要求，验证变更脚本是否能够正确执行。若测试通过，可以通过映射列表快速在目标主机上执行变更；若不通过，可以及时发送告警通知给相关人员，避免不必要的损失。由此，提高了变更实施的质量和效率。

下面将结合具体例子对本实施方式所提供的用于应用系统中应用程序的自动变更方法进行描述。本实施方式所提供的方法主要包括两个方面：一、标准化文件的准备；二、应用程序的自动变更。具体的：

标准化文件的准备说明：

在本实施方式中，对分组列表进行进一步的规范和优化，对外提供统一格式的分组列表模板(例如，execl文件)，在其中设置相关宏处理功能，在填写分组列表时，通过宏的处理机制，规范填写内容，限制非法输入，保障分组列表格式统一和填写内容合法。

同时，在分组列表中增设目标主机与测试主机的映射列表，开发人员在准备分组列表时，按目标主机信息填写分组列表，在测试环境下进行版本变更检验测试时，依据该映射列表，自动将目标主机替换为对应的测试主机，使同一份变更实施工艺，可以同时满足生产变更与测试实施。

在实施应用程序的自动变更方法前，为了保证整个实施过程的标准化和统一化，对应用版本包进行了规范，具体的，可以包括：规范应用版本包文件组成、规范应用版本包命名和规范应用版本包目录结构。

在本实施方式中，应用版本包由三种文件组成，分别为：应用文件版本包、分发配置定义文件和md5文件。

其中，应用文件版本包用于存放需要应用更新的应用程序文件。除此之外，与应用程序相关的变更脚本也存放于该应用文件版本包中，具体的，可以存放于该版本包bin/dist_shell目录下。

分发配置定义文件用于定义应用文件版本包中待分发的应用程序文件的源路径、目标路径、属组以及权限。

md5文件包括应用文件版本包和分发配置定义文件的md5码，用于应用文件版本包和分发配置定义文件下发后的校验。

在文件统一组成的基础上，本实施方式还要求统一版本的文件命名，具体的，应用文件版本包、分发配置定义文件、md5文件必须命名一致，相互之间以扩展名区分，例如：unix系统中，应用文件版本包的扩展名为.tgz/.tar.gz，配置文件的扩展名为.cfg，md5文件的扩展名为.txt；windows系统中，应用文件版本包的扩展名为.zip，配置文件的扩展名为.json，md5文件的扩展名为.txt。

此外，应用版本包的结构也需要统一配置，在本实施方式中，应用版本包结构是以目录结构来表示，其结构规定如下：

说明：

目录“app”：该目录用于存放应用文件版本包、分发配置定义文件和md5文件；

目录“oth”：该目录用于存放其他工具软件、升级版本文件；

目录“dbs”：该目录用于存放数据库升级版本包；

目录“man”：该目录用于存放操作手册文档；

目录“doc”：该目录用于存放需求、设计文档。

由此，实现变更过程中涉及的各类文件的标准化，方便后续在不同的应用系统中可以使用同一套方法执行变更操作。

应用程序的自动变更说明：

获取分组列表，根据该分组列表从服务器中下载相应的应用版本包，具体的：

从服务器指定路径下载应用版本包到临时目录app_temp下。下载方式可选择使用ftp或wget进行文件下载。如文件不存在或下载失败，则报错处理，如获取文件成功，则继续进一步处理。

应用版本包下载完成后，基于md5文件中记录的md5码信息，检查已下载到临时目录下的应用文件版本包、分发配置定义文件的md5码是否与定义的md5码一致。如果不一致，则判断为异常，中断处理，如md5检核通过则继续进一步处理。

通过tar命令解压应用文件版本包到临时目录distrubute_dir目录下读取分发配置定义文件中定义的信息，基于定义待分发的应用程序文件的用户属组及访问权限，确定每个待分发的应用程序文件要设置的访问权限及用户属组，通过chmod、chown命令修改待分发的应用程序文件的用户属组及访问权限。

进一步的，根据分组列表中的映射列表，将应用版本包下发至其变更的目标主机所对应的测试主机中，具体的：

逐行读取分发配置定义文件中定义的待分发的应用程序文件的目标路径，根据映射列表将应用版本包中待分发的应用程序文件拷贝至对应的目标路径下。

拷贝完成后，检查应用版本包中待分发的应用程序文件与拷贝后目标路径下的文件的md5是否一致。如果不一致返回失败，中断处理。

测试主机根据变更脚本执行变更测试，并生成测试执行报告。若测试未通过则将分组列表和应用版本包退回至开发人员，以重新准备分组列表和应用版本包。

为了保证提高变更实施的质量，在本实施方式中，测试通过后，可以将测试执行报告及相应的分组列表和应用版本包再次提交给审核人员进行在线审核。由于分组列表和应用版本包经过预先统一配置，可以极大程度上降低人工审核的难度和时间。

同时，通过在线审核的方式以及对审核对象进行的标准化优化，解决原有变更执行与变更审批脱节的问题。实现变更实施工艺一点录入，线上审批，变更内容不可篡改，审批通过后在线全自动实施，保证变更实施内容与变更审批内容严格一致。加强了变更实施过程管控，有效得控制变更操作风险。

人工审核通过后的变更方案处于待执行的状态，开始检测执行环境是否满足执行条件。在本实施方式中，监控是否到达预设的变更开始时间，若到达预设的变更开始时间，则判定为满足执行条件，将启动变更执行，若未到达预设时间，则继续进行循环等待。执行条件满足后，根据分组列表确定本次变更所涉及的主机范围，调用服务接口，设置范围内的主机进入监控维护期，屏蔽执行期间产生的警告事件。

选择分组列表中应用序号最小的应用信息组成本轮待执行的分组，解压该分组对应的应用版本包，根据其中分发配置定义文件检测目标主机中的目标路径下是否存在文件，从而对目标主机上与待分发的应用版本包对应的目标路径下的文件进行备份，记录备份操作内容，以便版本回退时使用。具体的：

在服务器备份目录下(例如：/home/backupfile)创建一备份目录，命名为：appbak_<时间戳>(例如：appbak_20190610123010)，用于存放备份文件。并在该目录下创建一备份文件，命名为：appbak_rec_<时间戳>(例如：appbak_rec_20190610123010)，用于记录备份的动作及备份文件信息，在版本回退时需要通过该文件中记录的信息执行回滚操作。

逐行读取分发配置定义文件中所定义的待分发文件，确定目标主机上目标路径下是否存在文件。如果存在，则将该文件(带路径信息)拷贝到创建的备份目录下进行备份。并将该文件的路径、md5、操作方式记录至备份文件中。

其中，操作方式分为：recover、add。recover表示将应用版本包中的文件对该文件进行覆盖操作。add表示应用版本包中的文件为在目标路径下的新增文件。即，如果检查到目标路径下存在文件，则后续操作必定是以应用版本包中的文件覆盖该目标路径下的文件，所以操作方式记录为recover；如果检查到目标路径下不存在文件，则后续操作必定是将应用版本包中的文件新增至该目标路径下，所以操作方式记录为add。记录方式为<路径信息><md5(若存在文件)><操作方式>示例如下：

/home/ap/yyc/fserver2，add

/home/ap/yyc/stop.sh，206007521043g519g07dj5，recover

备份完成后，根据分发配置定义文件将待分发的应用程序文件分发至各目标主机下的目标路径，具体分发方式与上述将应用版本包分发至测试主机的流程一致，在此不再赘述。

检查待执行的分组是否满足前置条件，在本实施方式中，基于绝对依赖时间设置前置条件。具体的：监控当前时间，当当前时间到达预设的绝对依赖时间时，则判定为满足前置条件，将启动后续处理，若未到达预设时间，则继续进行监控等待。

满足前置条件后，向该分组涉及的目标主机发送变更指令，接收到变更指令的主机执行下发的文件中包含的变更脚本实现应用程序的自动变更。

在本实施方式中，还设置了执行后等待时间，变更脚本执行完成后，检测是否满足该执行后等待时间，以实现分组中不同应用程序的变更之间的协同等待。满足执行后等待时间后，进行下一轮分组的执行，直至分组列表中所记录的应用程序全部变更完成。并且，在本实施方式中，支持多个分组同时并发执行。

最后，执行交易检查，通过调用系统监控平台服务接口，检查系统交易情况(包括：交易量、交易成功率、交易响应时间)、系统资源使用情况(cpu、内存、网络、存储、进程、端口)是否正常。

若检查发现存在异常，发送告警通知相关人员。同时基于预设异常场景进行自动化应急处置，例如：自动回滚版本、重启应用服务等。

其中，在本实施方式中，自动回滚版本可以通过以下方式实现：

创建备份目录命名为：appbak_rec_<时间戳>(如：appbak_rec_20190610123010)，用于在回退版本文件前，对待回退的版本文件进行备份，具体备份方式与上述备份流程一致，在此不再赘述。

找到本次回退操作对应的待恢复的备份目录，读取该备份目录中对应的备份文件，基于每条备份记录信息逐条进行回退处理。

具体的，回退处理过程如下：读取每条备份记录信息，获得每条记录的的文件的路径、md5、操作方式。在执行回退操作前，先对服务器上待回退的目标文件进行备份。再基于操作方式采取对应回退处理，如记录的操作方式为add，则对当前目标路径下的文件进行直接删除处理。如果操作方式为recover，在删除目标文件后，将备份目录下对应的备份文件拷贝到目标路径下，拷贝完成后，检查目标文件的md5是否正确。

若检查无异常，则关闭监控维护期，表示自动变更完成。

最后，执行健康检查，调用一键式、通用的健康检查脚本，对应用进程、端口、日志等进行检查。若检查发现存在异常，发送告警通知相关人员，若检查通过，则结束该变更流程。

图4是根据本发明实施方式的一种用于应用系统中应用程序的自动变更系统1的框图，参照图4，该自动变更系统1包括：分组列表获取模块11，用于获取分组列表，该分组列表记录了本次自动变更过程中待变更的应用程序的应用信息。其中，应用信息包含了应用程序的名称、变更所涉及的主机范围、变更参数和应用序号。分组模块12，用于从上述分组列表中选取应用序号最小的应用信息组成待执行的分组。执行前条件检查模块13，检查待执行的分组是否满足前置条件。若满足前置条件，则通知执行模块14根据待执行的分组向本次变更所涉及的主机发送变更指令，使接收到变更指令的主机根据变更指令执行变更脚本实现所述应用程序的自动变更。其中，变更脚本包含根据所述待变更的应用程序预先从统一配置的执行操作中选取的操作，并存储于预设的位置。执行后条件检查模块15，用于在变更脚本执行完成后，检查分组是否满足执行后等待时间，若满足，则执行交易检查。

在本发明的实施方式中，如图5所示，自动变更系统1还包括监控设置模块16，用于检查自动变更系统的执行环境是否满足执行条件，若满足，设置进入监控维护期以屏蔽后续所述自动变更系统执行期间产生的警告事件。其中，执行条件包括：是否达到预设的变更开始时间；或，预设检查脚本是否运行成功。其中，若达到所述变更开始时间，则视为满足所述执行条件；或，若所述预设检查脚本运行成功，则视为满足所述执行条件。

在可选的实施方式中，如图6所示，自动变更系统1还包括准备模块17，用于根据分组列表获取相应的应用版本包，该应用版本包包括分发配置定义文件和应用文件版本包。获取到应用版本包后，根据其中分发配置定义文件将应用文件版本包分发至对应的主机的目标路径中。其中，应用文件版本包包括变更脚本，目标路径记录在分发配置定义文件中。

在可选的实施方式中，如图7所示，自动变更系统1还包括备份模块18，用于在准备模块17将应用文件版本包分发至对应的主机的目标路径前，根据分发配置定义文件检测目标路径下是否存在文件。若存在，将目标路径下的文件拷贝至预设的备份目录中，并将相应的目标路径记录至预设的备份文件中，并标记为recover；否则，将相应的目标路径记录至所述备份文件中，并标记为add。其中，备份文件存储于所述备份目录中。

在可选的实施方式中，如图8所示，自动变更系统1还包括测试模块19，用于根据映射列表确定本次变更涉及的主机对应的测试主机，向该测试主机发送变更指令，使得接受到该变更指令的测试主机根据该变更指令执行变更脚本实现应用程序的自动变更。

可选的，本发明实施方式提供了一种用于应用系统中应用程序的自动变更装置，该数据库清理装置包括存储器，用于存储一条或多条计算机指令；处理器，用于调用并执行所述一条或多条计算机指令从而实现本发明前述实施方式或实现方式所提供的用于应用系统中应用程序的自动变更方法。可选地，在本发明实施方式的一种实现方式中，所述用于应用系统中应用程序的自动变更装置还可以包括用于进行数据通信的输入输出接口。例如，所述处理装置可以是计算机、智能终端、服务器等。

本发明实施方式还提供了一种计算机存储介质，存储有一条或多条计算机指令，用于在执行时实现本发明前述实施方式或实现方式提供的用于应用系统中应用程序的自动变更方法。例如，所述存储介质可以包括硬盘、软盘、光盘等。

虽然本文举例描述了一些实施方式，但是，在不脱离本发明实质的前提下，可以对这些实施方式进行各种变形，所有这些变形仍属于本发明的构思，并且落入本发明权利要求所限定的保护范围。

本文所公开的具体实施方式仅用于举例说明本发明，对于本领域技术人员而言，显然可以根据本文的教导进行各种修改，可以采用各种等同的方式实施本发明，因此，本发明上述公开的特定的实施方式仅仅是示例性的，其保护范围不受在此公开的结构或设计的细节所限，除非在权利要求中另有说明。因此，上述公开的特定的示例性的实施方式可进行各种替换、组合或修改，其所有的变形都落入本文公开的范围内。在缺少本文没有具体公开的任何元件或缺少本文公开的任选的部件的情况下，本文示例性公开的用于应用系统中应用程序的自动变更方法、系统、装置及存储介质仍可适当地实施。上述公开的所有的数值和范围也可进行一定变化。每当公开了具有下限和上限的数值范围，落入此范围内的任何数值及任何被包含的范围都被具体地公开了。具体而言，本文公开的数值的任一范围均可理解为列举了包含在较宽数值范围内的任一数值和范围。同样，除非申请人明确且清楚地另有定义，权利要求中的术语具有它们的清楚、通常的含义。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到本发明可借助软件结合硬件平台的方式来实现。基于这样的理解，本发明的技术方案对背景技术做出贡献的全部或者部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如rom/ram、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施方式或者实施方式的某些部分所述的方法。

此外，权利要求书中的部件的数量包括一个或至少一个，除非另有说明。如果本发明中的用词或术语与其它文献中的用法或含义存在不一致，则应当以与本发明所定义的为准。