CN112925544B

CN112925544B - 更新应用程序的方法、装置、电子设备及计算机存储介质

Info

Publication number: CN112925544B
Application number: CN202110219157.3A
Authority: CN
Inventors: 童峰; 宋亮军; 黄洪辉
Original assignee: Hunan Qiangzhi Technology Development Co ltd
Current assignee: Hunan Qiangzhi Technology Development Co ltd
Priority date: 2021-02-26
Filing date: 2021-02-26
Publication date: 2022-12-02
Anticipated expiration: 2041-02-26
Also published as: CN112925544A

Abstract

本公开提供了一种更新应用程序的方法，所述方法包括：接收应用程序的更新内容，所述更新内容至少包括：所述应用程序的最新版本数据、数据库SQL语句；其中，所述数据库SQL语句与所述应用程序的最新版本匹配；解压所述更新内容，执行所述数据库SQL语句；若所述数据库SQL语句执行成功，根据服务端的配置参数，匹配与所述服务端对应的配置文件；重新将所述更新内容、所述配置文件以及授权文件打包成更新包；向需要更新应用程序的节点，下发更新指令；其中，所述更新指令包括：更新包；通过本公开提供的方法，可提高应用程序版本的一致性，提升正常使用率。

Description

更新应用程序的方法、装置、电子设备及计算机存储介质

技术领域

本公开涉及计算机领域，具体地，涉及一种更新应用程序的方法、装置、电子设备及计算机存储介质。

背景技术

随着集群环境中节点数的扩展，对于节点中应用程序的更新维护的要求不断提高，然而现有的关于在节点中的应用程序的更新，人工操作的比重高，导致常会出现由于文件更新不连续的问题、应用程序无法正常启动，并且各节点应用程序的版本不一致而导致应用程序的逻辑不一致，进而导致业务数据产生错误，从而影响节点中应用程序的正常更新和使用。

因此，需要提升应用程序的更新成功率和正常使用率的装置。

发明内容

本公开提供一种更新应用程序的方法、装置、电子设备及计算机存储介质。

根据本公开实施例的第一方面，本公开实施例提供了一种更新应用程序的方法，所述方法包括：

接收应用程序的更新内容，所述更新内容至少包括：所述应用程序的最新版本数据、数据库SQL语句；其中，所述数据库SQL语句与所述应用程序的最新版本匹配；

解压所述更新内容，执行所述数据库SQL语句；

若所述数据库SQL语句执行成功，根据服务端的配置参数，匹配与所述服务端对应的配置文件；

重新将所述更新内容、所述配置文件以及授权文件打包成更新包；

向所述需要更新应用程序的节点，下发更新指令；其中，所述更新指令包括：更新包。

可选地，在向需要更新应用程序的节点，下发更新指令之前，所述方法还包括：

根据所述应用程序的最新版本，比对所述应用程序的最新版本数据与所述节点的应用程序的版本数据，得到比对结果；

根据所述比对结果，确定与所述更新内容的版本数据不一致的节点，为需要更新应用程序的节点。

可选地，在所述接收应用程序的更新内容之后，所述方法还包括：

验证所述更新内容的有效性；

若所述更新内容的有效性通过验证，解压所述更新内容，更新所述数据库SQL语句；

若所述更新内容的有效性未通过验证，则返回所述接收应用程序的更新内容的步骤。

可选地，所述方法还包括：

根据所述更新内容，比对所述更新内容中的版本数据与所述节点的应用程序的版本数据，得到比对结果；

根据所述比对结果，得到所述节点的应用程序的版本数据与所述更新内容的版本数据之间的差值；

将所述差值与预设极小值比对，若所述差值大于预设极小值，则停止对于所述节点的应用程序的更新；若所述差值等于预设极小值，则继续对所述节点的应用程序的更新。

可选地，所述方法还包括：

获取节点的应用程序的更新状况；其中，所述更新状况，包括：更新成功或更新失败；

确定所述节点的应用程序的更新状况为更新失败，向所述节点下发执行清理所述应用程序的运行进程的指令，以及执行关闭所述节点的指令；以及

向所述节点下发更新指令；其中，所述更新指令携带所述更新包。

可选地，所述方法还包括：

确定所述节点的应用程序的更新状况为更新成功，向所述节点下发执行启用所述节点的指令。

可选地，所述方法还包括：

所述服务端的更新日志，记录所述节点的应用程序的更新状况。

根据本公开实施例的第二方面，本公开实施例提供了一种更新应用程序的装置，所述装置包括：

接收模块，用于接收应用程序的更新内容，所述更新内容至少包括：所述应用程序的最新版本数据、数据库SQL语句；其中，所述数据库SQL语句与所述应用程序的最新版本匹配；

执行模块，用于解压所述更新内容，执行所述数据库SQL语句；

匹配模块，用于若所述数据库SQL语句执行成功，根据服务端的配置参数，匹配与所述服务端对应的配置文件；

打包模块，用于重新将所述更新内容、所述配置文件以及授权文件打包成更新包；

下发模块，用于向需要更新应用程序的节点，下发更新指令；其中，所述更新指令包括：更新包。

可选地，在所述下发模块用于向需要更新应用程序的节点，下发更新指令之前，所述装置还配置为，包括：

可选地，所述装置还配置为，包括：

验证模块，用于在所述接收应用程序的更新内容之后，验证所述更新内容的有效性；

若所述更新内容的有效性通过验证，所述执行模块解压所述更新内容，执行所述数据库SQL语句；

若所述更新内容的有效性未通过验证，则返回所述接收模块接收应用程序的更新内容。

可选地，所述装置还配置为，包括：

可选地，所述装置还配置为：

可选地，所述装置还配置为，包括：

根据本公开实施例的第三方面，提供一种更新应用程序的装置，包括：

存储器；

处理器，与所述存储器连接，用于通过存储所述存储器存储的计算机执行指令，能够实现前述第一方面提供的更新应用程序的方法中的步骤。

根据本公开实施例的第四方面，提供一种计算机存储介质，所述计算机存储介质中存储有可执行指令；所述计算机可执行指令被处理器执行后，能够实现前述第一方面提供的更新应用程序的方法中的步骤。

本公开的实施例提供的技术方案可以包括以下有益效果：将数据库SQL语句与所述应用程序的最新版本匹配，可提升所述应用程序最新版本之间一致性；解压所述更新内容，执行所述数据库SQL语句成功之后，根据服务端的配置参数，匹配与所述服务端对应的配置文件，重新将所述更新内容、配置文件以及授权文件打包，有利于保证更新应用程序所需文件之间的一致性；向所述需要更新应用程序的节点，下发更新包，如此，将各种文件或内容在保证与最新版本统一的前提下，再下发给需要更新应用程序版本的节点，有利于所述应用程序版本的文件之间的一致性以及保证各节点之间应用程序版本的一致性；本公开所提供的更新应用程序的方法或装置，与现有的人工操作各个更新步骤相比，所述应用程序版本的文件之间的一致性的较高，可保证应用程序版本更新后能正常启动；以及各节点应用程序的版本一致可保证应用程序的逻辑一致，提高正常使用率。

应当理解的是，以上的一般描述和后文的细节描述仅是示例性和解释性的，并不能限制本公开。

附图说明

图1为本公开实施例示出的一种更新应用程序方法的流程示意图；

图2为本公开实施例示出的一种更新应用程序方法的流程示意图；

图3为本公开实施例示出的一种更新应用程序方法的流程示意图；

图4为本公开实施例示出的一种更新应用程序方法的流程示意图；

图5为本公开实施例示出的一种更新应用程序方法的流程示意图；

图6为本公开实施例示出的一种更新应用程序方法示意图；

图7为本公开实施例示出的一种更新应用程序方法的示意图；

图8为本公开实施例示出的一种更新应用程序方法的示意图；

图9为本公开实施例示出的一种更新应用程序方法的示意图；

图10本公开实施例示出的一种更新应用程序装置的结构示意图。

具体实施方式

这里将详细地对示例性实施例进行说明，其示例表示在附图中。下面的描述涉及附图时，除非另有表示，不同附图中的相同数字表示相同或相似的要素。以下示例性实施例中所描述的实施方式并不代表与本公开实施例相一致的所有实施方式。相反，它们仅是与如所附权利要求书中所详述的、本公开实施例的一些方面相一致的装置和方法的例子。

结合图1所示，本公开实施例提供了一种更新应用程序的方法，所述方法包括：

步骤S101，接收应用程序的更新内容，所述更新内容至少包括：所述应用程序的最新版本数据、数据库SQL语句；其中，所述数据库SQL语句与所述应用程序的最新版本匹配；

步骤S102，解压所述更新内容，执行所述数据库SQL语句；

步骤S103，若所述数据库SQL语句执行成功，根据服务端的配置参数，匹配与所述服务端对应的配置文件；

步骤S104，重新将所述更新内容、所述配置文件以及授权文件打包成更新包；

步骤S105，向需要更新应用程序的节点，下发更新指令；其中，所述更新指令包括：更新包。

在本公开实施例中，将数据库SQL语句与所述应用程序的最新版本匹配，使得所述应用程序的最新版本的更新，只有与所述应用程序的最新版本匹配的数据库SQL语句，才能对所述更新内容执行下一步的更新步骤，能提升所述应用程序最新版本的统一使用率，进而有助于应用程序版本的一致性。

在本公开实施例中，解压所述更新内容，执行所述数据库SQL语句成功之后，才能根据服务端的配置参数，匹配与所述服务端对应的配置文件，重新将所述更新内容、配置文件以及授权文件打包，有利于保证更新应用程序所需文件之间的一致性。

在本公开实施例中，在步骤S105中，关于所述需要更新应用程序的节点的确定，包括：根据所述应用程序的最新版本，将当前应用版本不是最新版本的节点，确定为需要更新应用程序的节点。之后，向需要更新应用程序的节点，下发更新包，如此，将各种文件或内容在之前保证与最新版本统一的前提下，再下发给需要更新应用程序版本的节点，有利于所述应用程序版本的文件之间的一致性以及保证各节点之间应用程序版本的一致性；所述应用程序版本的文件之间的一致性的提升，可保证应用程序版本更新后能正常启动；以及各节点应用程序的版本一致可保证应用程序的逻辑一致，提高正常使用率。

在本公开实施例中，所述应用程序的版本数据，是指表示所述应用程序版本的数据，具体指不同数据的组合表示所述应用程序的版本，例如可以但不限于所述应用程序的1.0版本、所述应用程序的2.0版本或所述应用程序的3.0版本等；还可以但不限于是1.0.0版本、1.0.1版本、1.0.2版本、1.1.0版本、1.1.2版本、1.1.3版本等。

在本公开实施例中，所述数据库SQL语句具体可包括：SQL(Structured QueryLanguage，数据库结构化查询语言)脚本补丁。SQL是具有数据操纵和数据定义等多种功能的数据库语言，可查询、新增、更新以及删除数据库中的数据。

在本公开实施例中，所述数据库SQL语句包含与最新的应用程序版本对应的数据类型，通过执行所述最新的应用程序版本对应的数据库SQL语句，对应用程序进行更新。

在本公开实施例中，在步骤S101之前，需要远程连接各业务系统应用程序数据库服务器。

本公开实施例中，在步骤S103中，配置文件包含有数据库等连接信息，若所述数据库SQL语句执行成功，根据服务端的配置参数，匹配与所述服务端对应的配置文件，可以保障下发后所有节点的配置文件是一致的，不会由于配置文件不匹配产生故障，这样相当于统一管理配置文件，有利于保障各节点之间配置文件的一致性，进而保证各节点之间应用程序的版本的一致性。

本公开实施例中，在向需要更新应用程序的节点，下发更新指令之前，所述方法还包括：

步骤S1061，根据所述应用程序的最新版本，比对所述应用程序的最新版本数据与所述节点的应用程序的版本数据，得到比对结果；

步骤S1062，根据所述比对结果，确定与所述更新内容的版本数据不一致的节点，为需要更新应用程序的节点。在本公开实施例中，所述比对结果包括：所述应用程序的最新版本数据与所述节点的应用程序的版本数据的大小关系，例如，所述应用程序的最新版本数据大于所述节点的应用程序的版本数据，或所述应用程序的最新版本数据等于所述节点的应用程序的版本数据。

在本公开实施例中，所述方法包括：根据所述应用程序的最新版本，将当前版本不是最新版本的节点，确定为需要更新应用程序的节点；关于确定当前版本不是最新版本的节点，则按照所述步骤S1061得到比对结果以及按照所述步骤S1062，确定与所述更新内容的版本数据不一致的节点，为当前版本不是最新版本的节点，此时，所述当前版本不是最新版本的节点，为需要更新应用程序的节点。

在本公开实施例中，所述步骤S1062中，若所述比对结果为：所述应用程序的最新版本数据大于所述节点的应用程序的版本数据，则确定所述节点的应用程序与所述应用程序的最新版本不一致，则确定所述节点为需要更新应用程序的节点。

在本公开实施例中，若所述比对结果为：所述应用程序的最新版本数据等于所述节点的应用程序的版本数据，则确定所述节点的应用程序与所述应用程序的最新版本一致，则确定所述节点为不需要更新应用程序的节点，之后，跳过该节点，将下一个节点的应用程序的版本数据与所述应用程序的最新版本数据比对。

在本公开实施例中，将所述应用程序的最新版本数据与所述节点的应用程序的版本数据比对，使得节点的应用程序的版本以服务端的应用程序的最新版本为比对基准，使得所述节点的应用程序在能及时得到更新的同时，也能与服务端的应用程序的版本一致，进而提升各节点之间的应用程序的版本的一致性。

本公开实施例中，实时监控所有集群节点主机上的程序的最新版本，以服务端的最新版本为准，将服务端的最新版本与集群节点主机上的应用程序版本比对，若检测到部分节点主机与服务端的应用程序一致，而其他节点主机的应用程序版本与服务端的应用程序版本不一致时，进而确定是否有大量的主机之间的应用程序版本与服务端版本一致，若不一致，则服务端异步下发应用程序的软件更新包，同时更新其余主机上的应用程序版本，使主机之间的应用程序的版本一致。

本公开实施例中，服务端异步下发应用程序的软件更新包，同时更新其余主机上的应用程序版本，可提升更新速率。

本公开实施例中，是通过应用程序的更新提升应用程序版本的一致性的，并且一段时间更新一次应用程序版本，升级的同时也提升版本之间的一致性。

在本公开实施例中，关于提升节点之间的应用程序版本的一致性，服务端接收的应用程序的版本以及下发给节点的版本，也可以不是最新版本，例如，可以是客户或用户指定的某一特定中间版本，例如是客户或用户反馈的好评率最高的应用程序的版本。

在本公开实施例中，也可以不升级的同时，更新应用程序只是为了提升应用程序版本的一致性。

本公开实施例中，结合图3所示，在步骤S101：接收应用程序的更新内容之后，所述方法还包括：

步骤S1012，验证所述更新内容的有效性；

若所述更新内容的有效性通过验证，则进入步骤S102：解压所述更新内容，执行所述数据库SQL语句；

若所述更新内容的有效性未通过验证，则返回步骤S101：接收应用程序的更新内容。

在本公开实施例中，所述验证所述更新内容的有效性，包括：验证所述数据库SQL语句的格式是否正确、验证所述更新内容的压缩包格式是否正确。

在本公开实施例中，所述验证所述数据库SQL语句的格式是否正确，具体包括：所述数据库SQL语句的格式是否为符合要求的格式，例如，所述数据库SQL语句的文件格式是否为特定格式，命名是否统一规范，是否为不含有中文。例如，所述SQL脚本补丁的文件格式可以是但不限于UTF-8格式，UTF-8为一种字节编码方式。

在本公开实施例中，所述验证所述更新内容的压缩包格式是否正确，具体包括：验证所述更新内容的压缩包名称中的版本信息和压缩包内的实际版本是否一致、以及所述验证所述应用程序版本的名称格式是否正确。

在本公开实施例中，所述验证所述压缩包名称中的版本信息显示的版本数据，与所述压缩包内的实际版本不一致，则提示修改所述压缩包名称，以与实际版本一致。例如，若所述压缩包名称中显示的版本为“5_4_7”，而压缩包内实际的版本为“5_4_6”，则提示将所述压缩包名称的版本部分修改为“5_4_6”。

在本公开实施例中，所述验证所述应用程序版本的名称格式是否正确，包括但不限于：验证所述应用程序版本的名称中的版本数据部分是否带有字母，若带有字母，则有效性验证不通过，若不带有字母，则有效性验证通过。例如，在一个示例性实施例中，所述更新内容的压缩包命名为：jrb-319-fullUPgradePackage-20200430-software-S5_4_7.zip，则验证出版本数据部分“S5_4_7”带有字母，则接收所述更新内容失败，提示失败原因，重新接收应用程序的更新内容；例如在另一个示例性实施例中，只有所述更新内容的压缩包命名为：jrb-319-fullUPgradePackage-20200430-software-5_4_7.zip时，则验证出版本数据部分“5_4_7”不带有字母，则验证所述应用程序版本的名称格式正确。在本公开实施例中，只有所述更新内容是有效的内容，才能进行下一步的更新步骤，如此才能避免由于更新内容无效导致的更新失败的问题，与此同时，也能节约时间，避免无效操作并且占用服务器资源，提升应用程序的版本一致性。

在本公开实施例中，结合图4所示，所述方法还包括：

步骤S1061，根据所述更新内容，比对所述更新内容中的版本数据与所述节点的应用程序的版本数据，得到比对结果；

步骤S1063，根据所述比对结果，得到所述节点的应用程序的版本数据与所述更新内容的版本数据之间的差值；

步骤S1065，比对所述差值与预设极小值，若所述差值大于预设极小值，则进入步骤S1067，

步骤S1067；停止对于所述节点的应用程序的更新；

若所述差值等于预设极小值，则进入步骤S1069；

步骤S1069，继续对所述节点的应用程序的更新。

在本公开实施例中，在所述步骤S1061中，若所述更新内容中的版本数据为3.0，所述节点的应用程序的版本数据为1.0，则得到的所述比对结果显示：所述更新内容中的版本数据与所述节点的应用程序的版本数据不一致，且得到所述节点的应用程序的版本数据与所述更新内容的版本数据之间的差值为2。若原本设定的预设极小值为1，则所述差值大于预设极小值，需要停止对所述节点的应用程序的更新。

在本公开实施例中，在所述步骤S1061中，若所述更新内容中的版本数据为2.0，所述节点的应用程序的版本数据为1.0，则得到的所述比对结果显示：所述更新内容中的版本数据与所述节点的应用程序的版本数据不一致，且得到所述节点的应用程序的版本数据与所述更新内容的版本数据之间的差值为1。若原本设定的预设极小值为1，则所述差值等于预设极小值，继续对所述节点的应用程序的更新。

在本公开实施例中，若所述节点的应用程序版本与所述服务器中的最新应用程序版本之间还隔着多个中间版本，则容易导致由于隔着多个中间版本，直接跨版本更新会导致更新不顺畅，容易出现更新失败的问题，因此当出现跨版本的最新版本的应用程序版本时，先停止对所述应用程序的更新，对版本较低的节点顺序自动更新至较高的版本，直至所述差值等于所述预设极小值时，再继续对所述节点继续最新版本的应用程序的更新。

在本公开实施例中，结合图5所示，所述方法还包括：

步骤S107，获取节点的应用程序的更新状况；其中，所述更新状况，包括：更新成功或更新失败；

步骤S1071，确定所述节点的应用程序的更新状况为更新失败，向所述节点下发执行清理所述应用程序的运行进程的指令，以及执行关闭所述节点的指令；以及

步骤S1072，向所述节点下发更新指令；其中，所述更新指令携带所述更新包。

在本公开实施例中，获取到节点的应用程序的更新状况为更新失败时，及时清理所述应用程序的运行进程以及及时关闭所述节点，并且重新更新，可避免应用程序版本不一致以及所述应用程序无法正常使用的状况。

在本公开实施例中，结合图6所示，所述方法还包括：

在步骤S107之后，进入步骤S1073，确定所述节点的应用程序的更新状况为更新成功，向所述节点下发执行启用所述节点的指令。

在本公开实施例中，确定所述节点的应用程序的更新状况为更新成功后，再向所述节点下发执行启用所述节点的指令，之后，所述应用程序才可以正常使用。

在本公开实施例中，所述方法还包括：所述服务端的更新日志，记录所述节点的应用程序的更新状况。

在本公开实施例中，所述更新日志包括程序更新日志和数据库SQL语句更新日志；所述程序更新日志的显示信息有：应用程序的程序名称、更新环境、操作人以及操作时间；所述数据库SQL语句更新日志显示信息有：程序包名称、文件名称、更新环境、执行状态、操作人以及操作时间。

在本公开实施例中，所述执行状态是指SQL脚本补丁执行的状态，包括：自动执行状态和手动执行状态。当自动执行状态失败后，更新日志会将失败记录记载在服务端中，管理人员可查询服务端的更新日志，对更新失败的节点主机进行手动执行SQL脚本补丁，并修改更新日志中的手动执行状态为已执行，方可再次更新程序。

在本公开实施例中，所述数据库SQL语句更新日志明细需要下载日志文件，文件内包括每条数据库SQL语句的执行状态信息；对应工具自动执行数据库SQL语句出错的，需在此处修改执行状态为已执行，才可以再次自动更新。

在本公开实施例中，对于所述应用程序的更新管理，包括：维护上传集群中各业务系统应用程序更新包、系统更新操作、节点更新状态信息查询。在所述更新过程中，对更新包检查，以及对节点上应用程序版本进行检查，确认无误才可以进入下一步的主机环境检查；检查通过之后，可先远程执行数据库SQL语句。

在本公开实施例中，若所述数据库SQL语句执行失败，则停止更新，需要手动执行所述数据库SQL语句，修改更新日志管理中手动执行状态为已执行，才可再次更新应用程序，确保上述步骤均已通过，接下来就是远程分发程序更新包至节点的文件目录下，停止并备份原始集群中各业务系统应用程序，加压新的程序更新包并启动程序，在系统更新最后，记录更新包更新日志和脚本更新日志，更新操作完成。

在本公开实施例中，在自动化更新应用程序的过程中，服务端需要对更新环境以及更新所涉及的文件进行校验。

在本公开实施例中，环境校验部分包括但不限于：

检查服务端与节点之间的远程连接是否正常；

检查节点的共享目录是否正常；

检查授权文件是否正常等。

在本公开实施例中，文件校验部分包括但不限于：

数据库SQL语句的格式是否为特定格式；

不能跨版本更新；

个性化目录必须有；

database目录(数据库目录)下必须存在一个DDL(data definition language，数据定义语言)文件或DML(data manipulation language，数据操纵语言)文件；

集群信息中必须设置管理端和被管理端的更新包名称和集群代码(例如学校代码、公司代码或机构代码)；

更新内容的格式检查，同一个版本只能接收一个更新内容，更新包的index.JSP中的版本要和更新包的版本一致。

本公开实施例中，在上述环境部分和文件部分检查完毕之后，汇总输出的信息包括：成功的项数，失败的项数以及哪些部分失败了，输出提示该如何解决失败的项数。如此，可以杜绝需要多次接收所述更新内容的压缩包，一个版本更新内容的压缩包至多接收有限次数n次。在一些实施例中，有限次数n次可以为2次。所述有限次数也可以是3次，当然，所述有限次数大于等于1的基础上，所述有限次数越少越好。

本公开实施例中，在对环境和文件的校验成功之后，执行对所述节点的更新部分的步骤，包括：

只更新已部署的节点主机；

执行SQL脚本补丁；

备份当前程序代码；

清理当前程序代码时，保留共享目录部分(业务系统附件、编辑附件)；

更新时下发更新包，尚未执行更新操作的节点主机，还可进行程序包替换修改，否则不可修改；

记录更新日志；

SQL脚本补丁自动执行应用程序的更新失败，可在修改更新状态后，再人工执行SQL脚本补丁。

本公开实施例中，下发所述更新指令时，需要检查应用程序的版本是否一致、检测到部分更新以及全部更新成功的则无需再次下发更新指令。

在本公开实施例中，关于对节点的更新包进行删除控制工作，包括：检测到部分更新成功的节点，不允许进行删除所述更新包。

在本公开实施例中，关于服务启用的管理：需要先校验，再更新程序，最后启动服务。在环境校验部分：校验不通过，不可启动。部分节点突然开机时，在更新管理部分：则无需对突然开机的部分节点执行SQL脚本补丁以及文件校验；获取最新版本程序更新并记录更新日志。

在本公开实施例中，关于服务禁用的管理：禁用关机的节点或连不上的节点。防止出现使用故障。

在本公开实施例中，应用程序的更新不需要选择主机、更新类型、SQL执行方式，而是默认所有可更新主机、所有更新类型(例如是服务端还是节点主机)、SQL自动执行方式。

在本公开实施例中，节点主机信息会显示：ip、tomcat(Apache Tomcat，开源JavaWEB服务器)路径、工程包、最新版本、服务状态。

在本公开实施例中，服务端定时检查节点的教务系统版本，版本不一致时执行服务启动更新，启动失败则更新服务状态为禁用状态并清理tomcat进程，启动成功则更新服务状态为启动状态。

在本公开实施例中，关于授权文件的修改的管理，授权码到期需邮件反馈给服务端，导出节点信息，例如邮件反馈授权文件到期提醒、导出节点信息：例如ip、机器码。

在本公开实施例中，节点的更新日志会记录在服务端中，服务端可自动记录各节点的更新状况以及各节点的应用程序的版本。如此，当出现任意一个节点的应用程序的最新版本更新成功后，会继续对其他节点的应用程序更新到最新版本，以提升各节点之间应用程序的版本的一致性。并且，由于服务端中更新日志对各节点的更新状况的记录，可便于对更新失败的节点设置再次更新或禁止启用，以及后续根据所述更新日志，对所述节点进行维护。

以下结合上述任意实施例提供一些具体示例：

示例1：结合上述任意实施例提供一种应用于集群中各业务系统的更新应用程序的方法。

结合图7，同步集群中各节点之间的应用程序版本一致性工具实现了自动化替代人工操作流程，只需要技术人员上传更新包执行更新操作，工具内部将集群中各业务系统应用程序更新流程全自动化，如：检查程序包，检查web主机部署环境，智能批量检查集群中各业务系统应用程序版本一致性，SQL脚本补丁执行，发送程序包，备份原始程序，替换原始程序，启动新部署程序。其中更新多台web主机时，程序包同时分发至web各个主机，采用多线程技术，实现了多任务异步执行更新操作，大大缩短了整个更新周期。

关于同步集群各节点之间的应用程序版本一致性工具可应用于学校的各业务系统之间的节点、公司及分公司之间的节点、机构及分支机构之间的节点。

在所述工具控制范围内，上述可保证所有更新的集群中各业务系统应用程序版本的一致性，如遇外界因素(停电或人为误操作重启)，工具实现了实时检测集群中各业务系统应用程序版本纠错机制，智能检测所有Web主机上集群中各业务系统应用程序版本，采用智能纠错算法进行处理，将存在版本不一致的集群中各业务系统应用程序程序与正常的程序进行隔离开，保证集群中各业务系统应用程序正常运行。

基础主机管理配置教务管理平台所有服务器信息。基础主机需配置所需远程登录的信息，如：服务器ip(Internet Protocol，网际互连协议)地址、远程账号、密码、启用状态、已部署教务版本号、所属服务标签(web/oracle/redis等)。用于执行采集脚本通过ssh(Secure Shell，安全外壳协议)远程登录和判别是否为集群中各业务系统应用程序web主机。

服务启停管理配置监控基础主机，维护主机上配置的服务项(web服务)和服务状态(启动、关闭)。启动web服务时具体会进行以下操作：

步骤S201，远程连接对应的web主机，检查集群中各业务系统应用程序使用共享目录、授权文件是否正常；

步骤S202，分发最新程序包至主机$TOMCAT_HOME/tomcat_temp目录下；

步骤S203，备份主机上正在运行版本集群中各业务系统应用程序至$TOMCAT_HOME/tomcat_bak目录下；

步骤S204，停止正在运行的集群中各业务系统应用程序，清理程序且保留共享目录，解压最新程序包，启动集群中各业务系统应用程序；

步骤S205，记录更新过程记录。

系统更新管理用于自动化替代人工更新集群中各业务系统应用程序程序(自动化更新部署保证集群中各业务系统应用程序版本一致性)，包括集群中各业务系统应用程序配置文件替换、维护系统授权文件、维护集群中各业务系统应用程序数据库连接、程序更新包管理、更新日志管理等功能。各个项目的集群中各业务系统应用程序的配置参数是不同，通过配置文件管理设置模块，更新时可使模板替换。配置集群中各业务系统应用程序数据库连接用于远程执行SQL脚本补丁。程序更新包管理记录每次程序包更新操作信息。更新日志管理记录程序更新包更新过程状态、SQL脚本补丁执行过程状态。

程序包更新包括以下操作：

步骤S301，上传最新集群中各业务系统应用程序更新包用于更新操作；

步骤S302，检查更新包的有效性；

步骤S303，替换集群中各业务系统应用程序配置文件并重新打包；

步骤S304，远程连接所有需要更新的web主机，通过智能检查批处理集群中各业务系统应用程序版本是否一致，不一致停止更新。检查运行中集群中各业务系统应用程序版本与当前更新版本比对，跨多版本停止更新(如：1.0升级到3.0中间跨了2.0版本，则不允许更新，1.0升级到2.0才可正常更新)；

步骤S305，远程连接对应的web主机，检查集群中各业务系统应用程序使用共享目录、授权文件是否正常；

步骤S306，远程连接集群中各业务系统应用程序数据库，执行SQL脚本补丁；

步骤S307，遍历所有主机，异步分发更新包至主机$TOMCAT_HOME/tomcat_temp目录下；

步骤S308，备份主机上正在运行版本集群中各业务系统应用程序至$TOMCAT_HOME/tomcat_temp目录下；

步骤S309，停止正在运行的集群中各业务系统应用程序程序，清理程序且保留共享目录，解压最新程序包，启动集群中各业务系统应用程序程序；

步骤S310，记录更新过程记录。

以上功能的实现详见图8。

实时监控集群中各业务系统应用程序版本不一致机制，是以智能检测批量处理web主机中集群中各业务系统应用程序版本，发现不一致的进行主机隔离处理及时止损。采用智能纠错算法进行web主机隔离，如检测到版本与当前最新版本不一致的集群中各业务系统应用程序web主机，则调用服务启停管理中对应主机的服务启动操作(包含了启动操作执行步骤)，启动成功，修改主机启用状态(禁用状态的改为启用状态)；启动失败，修改主机启用状态(启用状态的改为禁用状态)，并清理集群中各业务系统应用程序程序进程，记录服务启停日志记录原因。如检测到版本与当前最新版本一致的集群中各业务系统应用程序web主机，则只修改主机启用状态(禁用状态的改为启用状态)。

以上功能的实现详见图9。

数据流具体实现：

基础主机管理：

维护监控主机信息，监控主机信息包括：主机名称、主机ip、端口号、账号、密码、启用状态、运行环境、系统版本、所属服务标签、已部署教务版本号等。

服务启停管理:

维护监控主机web服务状态，服务启停信息包括：主机ip、服务标签(web/oracle/redis等)，服务部署路径、WebApp名称(ROOT/jsxsd)、服务访问地址。

更新管理:

学校基本信息：

维护学校基本信息包括：学校代码、学校名称、英文名称、管理端工程包名、客户端工程包名。

文件路径管理：

维护文件路径信息包括：路径名称、路径参数(如:/WEB-INF/classes/config/)、更新环境(正式、测试)、工程包类型(管理端、师生端)。

文件路径信息为集群中各业务系统应用程序程序中配置文件的路径，由于有多个配置分布在不同路径下，所以需要预设，在集群中各业务系统应用程序更新流程中替换配置文件的路径信息读取此数据。

配置文件管理：

维护配置文件信息包括：路径名称、更新环境(正式、测试)、配置文件模板、备注。

在集群中各业务系统应用程序更新流程中替换配置文件根据具体配置文件模板(如：dbconfig.properties)和文件路径(如:/WEB-INF/classes/config/)，可直接定位到程序包中被替换的配置文件。

授权文件管理：

维护授权文件信息包括：主机名称、授权文件、有效截止日期。

授权文件包含集群中各业务系统应用程序正常使用的授权码，过期的授权文件可重新上传维护，确认无误可远程发送至对应的主机集群中各业务系统应用程序授权文件目录下(如：/WEB-INF/lib/)。

数据连接管理：

维护集群中各业务系统应用程序数据库连接信息包括：更新环境(正式、测试)、主机ip、端口、实例名、账号、密码。

用于集群中各业务系统应用程序更新流程中远程连接集群中各业务系统应用程序数据库服务器，根据提供集群中各业务系统应用程序数据库连接进行远程执行SQL脚本补丁。

更新程序管理：

维护上传集群中各业务系统应用程序更新包、系统更新操作、web主机更新状态信息查询。

更新过程中工具对程序包检查，以及所有web主机上集群中各业务系统应用程序版本进行检查，确认无误才可进入下一步web主机环境检查；基础必要性的检查通过了，就可先远程执行SQL脚本补丁，SQL脚本补丁执行失败，则停止更新，需手动执行SQL脚本补丁并修改更新日志管理SQL脚本补丁更新日志中手动执行状态为已执行，方可再次更新程序(执行过的脚本工具会调过进入下一步)；确保上述步骤均已通过，接下来就是远程分发程序更新包至web主机($TOMCAT_HOME/tomcat_temp目录下)，停止并备份原始集群中各业务系统应用程序程序，加压新的程序更新包并启动程序，在系统更新最后，记录更新包更新日志和SQL脚本补丁更新日志，整个系统更新操作完成。

更新日志管理：

查询程序更新日志(显示信息有程序包名称、更新环境、操作人、操作时间)，SQL脚本补丁更新日志(显示信息有程序包名称、文件名称、更新环境、执行状态、手动执行状态、操作人、操作时间)。

SQL脚本补丁更新日志明细需下载日志文件，文件内包括每条SQL执行状态信息；对应工具自动执行SQL出错的，需在此处修改手动执行状态为已执行，才可以再次自动更新。

实时监控检测运行中的集群中各业务系统应用程序版本：

实时监控web主机上的集群中各业务系统应用程序版本是否一致，对问题主机进行纠错处理。纠错根据服务启动状态，进行修改web主机的启动状态(禁止状态为更新工具认为是无效的主机)。

示例2：结合上述任意实施例提供一种应用于集群中各业务系统的更新应用程序的方法。

实现程序更新保证版本一致性包括4个部分：程序版本、数据库SQL脚本补丁、配置文件、授权文件。要保证程序版本能正常运行，需要4个部分的内容完全匹配。

首先，通过程序更新工具服务端，配置监听需要程序更新的集群节点主机，由人工在程序更新工具服务端管理界面上传最新程序包更新程序，由程序更新工具内部完成程序版本、数据库SQL脚本补丁、配置文件、授权文件校验和替换，保证程序版本一致(校验不通过、跨了版本的将直接返回错误信息，无法执行下一步)，再异步分发至集群节点主机。发送成功后，将集群节点主机上一版本的程序备份后，更新最新程序并重启程序。

其次，通过程序更新工具服务端，实时监控所有集群节点主机上的程序最新版本，如检测到版本不一致的主机，将进行纠错处理，重复尝试将最新版本程序进行更新，如更新失败，则强行清理当前程序所有相关进程，更新工具服务端自动将问题主机与正常主机进行隔离，标记状态，下次版本更新时，问题主机不会被更新。

所述方法包括：基础主机管理、服务启停管理、系统更新管理、实时检测运行中的集群中各业务系统应用程序版本。

由基础主机管理配置教务管理平台所有服务器信息。服务器为被监控对象，需配置所需远程登录的信息，如：服务器ip地址、远程账号、密码、启用状态、已部署教务版本号、所属服务标签(web/oracle/redis等)。用于执行采集脚本通过ssh远程登录和判别是否为集群中各业务系统应用程序web主机。

服务启停管理配置对应的主机，管理主机上配置的服务项(web服务)和服务状态(启动、关闭)。

系统更新管理用于自动化替代人工更新集群中各业务系统应用程序程序(自动化更新部署保证集群中各业务系统应用程序版本一致性)，包括集群中各业务系统应用程序配置文件替换、维护系统授权文件、维护集群中各业务系统应用程序数据库连接、程序更新包管理、更新日志管理等功能。采用服务端主动发送更新指令到集群节点主机。

实时检测处理集群中各业务系统应用程序版本不一致机制，是以检测所有运行中的web主机中集群中各业务系统应用程序版本，发现不一致的进行自动化处理及时止损并记录相关日志。

随着我国高等教育的快速发展，现代化信息管理程度的不断提高，加上高校办学规模不断扩大，随之而来的是高校各业务系统的运营维护管理任务面临严峻挑战，从运营维护管理难度和运营成本也随之提高。

就目前，一个高校长期用户有三万左右，单体部署高校业务应用程序已无法满足学校日常管理使用需求，教学管理人员依赖信息化管理程度不断提高，加上师生使用智能手机的普及，系统日常使用量大幅度增长，学校应教学需求，高校业务应用程序从单体方式升级为集群方式，随之而来的问题，就是高校业务应用程序更新维护。

各高校现状，仍使用人工操作各业务系统的应用程序更新升级，更新多主机过程中，总是要手动替换配置、执行SQL脚本补丁、分批次更新程序包，只要遗漏了一个步骤，对应的业务系统应用程序无法正常启动。没有更新过程日志情况下，排查原因浪费大量时间。更致命的问题就是集群中的程序均正常运行，系统版本却存在不同版本，致使各个业务系统应用程序逻辑不一致从而导致业务数据产生错误，甚至造成教学事故。

现有的人工操作更新多台web(World Wide Web，全球广域网)主机，需管理替换系统配置文件，执行SQL脚本补丁，每台web主机都需要远程操作，步骤太多，容易出现遗漏更新web主机，导致所有更新的集群中出现高校各业务系统应用程序版本不一致的节点，这种情况又很难被发现。

在高校各业务系统应用程序使用高峰期，为了保证服务正常运行，往往会在集群中临时增加服务器节点数量，使用高峰期一过，多余服务器会关闭使用。此时，更新高校各业务系统应用程序版本，只有正常运行的才会被更新，关机状态的高校各业务系统应用程序服务器不会更新。由于人为或机房断电原因，多数服务器被重启，其中也可能包括之前关机状态的高校各业务系统应用程序服务器，这就导致同一个集群中存在多个版本的高校各业务系统应用程序运行，只要有用户登录到有版本问题的高校各业务系统应用程序操作，可能产生问题数据。

结合本公开实施例、示例1以及示例2所提供的方法，能解决上述问题，并且可以带来以下技术效果：

使用自动化工具替换人工操作系统更新，规避操作失误导致集群中各业务系统应用程序版本不一致的更新问题；实时检测教务版本机制，及时自动处理纠正集群中各业务系统应用程序版本不一致的web主机，避免系统业务数据出错；记录系统更新日志，提供给项目负责人查阅，做好更新问题早发现早处理；可有效的提高每次集群中各业务系统应用程序升级更新效率。

集群中各业务系统应用程序自动化更新操作，避免人为干预，提高了系统更新时版本一致性；建立集群中各业务系统应用程序版本纠错机制，有效的避免外在因素导致集群中集群中各业务系统应用程序版本不一致问题；提供了更新时每个环节详细过程记录，为排查系统更新问题提供了依据。

结合本公开实施例、示例1以及示例2所提供的方法，除了解决学校(例如高校)的各业务系统的应用程序版本不一致之外，还可以解决公司及其分公司之间的节点、机构及其分支机构之间的节点的应用程序版本不一致的问题。避免在使用应用程序的使用高峰期，人员过多，而应用程序版本不一致导致的逻辑不一致，产生部分节点的应用程序无法正常使用的问题。

结合图10所示，在本公开实施例中，提供一种更新应用程序的装置，所述装置包括：

在本公开实施例中，所述更新应用程序的装置还包括：确定模块，还用于根据所述应用程序的最新版本，确定需要更新应用程序的节点；

所述确定模块，还配置为，包括：

在本公开实施例中，所述装置还配置为，包括：

在本公开实施例中，所述装置还配置为：

在本公开实施例中，所述装置还配置为，包括：

在本公开实施例中，提供一种电子设备，所述电子设备，包括：

处理器；

用于存储处理器可执行指令的存储器；

其中所述处理器用于运行所述计算机服务时，实现上述所述的更新应用程序的方法中的步骤。

本领域普通技术人员可以理解：实现上述方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成，前述的程序可以存储于一计算机可读取存储介质中，该程序在执行时，执行包括上述方法实施例的步骤；而前述的存储介质包括：移动存储设备、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

在本公开实施例中，提供一种存储介质，所述存储介质中有计算机可执行指令，所述计算机可执行指令被处理器执行实现上述所述的更新应用程序方法中的步骤。

或者，本发明实施例上述集成的单元如果以软件功能模块的形式实现并作为独立的产品销售或使用时，也可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明实施例的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备(可以是个人计算机、服务器、或者网络设备等)执行本发明各个实施例所述方法的全部或部分。而前述的存储介质包括：移动存储设备、只读存储器(ROM，Read-Only Memory)、随机存取存储器(RAM，Random Access Memory)、磁碟或者光盘等各种可以存储程序代码的介质。

以上所述，仅为本公开的具体实施方式，但本公开的保护范围并不局限于此，任何熟悉本技术领域的技术人员在本公开揭露的技术范围内，可轻易想到变化或替换，都应涵盖在本公开的保护范围之内。因此，本公开的保护范围应以所述权利要求的保护范围为准。

Claims

1.一种更新应用程序的方法，其特征在于，所述方法包括：

解压所述更新内容，执行所述数据库SQL语句；

若所述数据库SQL语句执行成功，即所述数据库SQL语句与所述应用程序的最新版本匹配，才能对所述更新内容执行下一步的更新步骤；

根据服务端的配置参数，匹配与所述服务端对应的配置文件；

向需要更新应用程序的节点，下发更新指令；其中，所述更新指令包括：更新包；

将所述更新包分发至各节点，停止并备份原始集群中各业务系统应用程序，解压所述更新包并启动程序；

实时监控检测运行中的集群中各应用程序版本，如检测到版本不一致的主机，对主机进行纠错处理，将最新版本程序进行更新；若更新失败，则强行清理当前程序所有相关进程，将问题主机与正常主机隔离。

2.根据权利要求1所述的更新应用程序的方法，其特征在于，在向需要更新应用程序的节点，下发更新指令之前，所述方法还包括：

3.根据权利要求1所述的更新应用程序的方法，其特征在于，在所述接收应用程序的更新内容之后，所述方法还包括：

验证所述更新内容的有效性；

若所述更新内容的有效性通过验证，解压所述更新内容，执行所述数据库SQL语句；

4.根据权利要求1所述的更新应用程序的方法，其特征在于，所述方法还包括：

比对所述差值与预设极小值，若所述差值大于预设极小值，则停止对于所述节点的应用程序的更新；若所述差值等于预设极小值，则继续对所述节点的应用程序的更新。

5.根据权利要求1所述的更新应用程序的方法，其特征在于，在所述方法还包括：

6.据权利要求1或5所述的更新应用程序的方法，其特征在于，所述方法还包括：

7.根据权利要求1或2所述的更新应用程序的方法，其特征在于，所述方法还包括：

8.一种更新应用程序的装置，其特征在于，所述装置包括：

匹配模块，用于若所述数据库SQL语句执行成功，即所述数据库SQL语句与所述应用程序的最新版本匹配，才能对所述更新内容执行下一步的更新步骤；根据服务端的配置参数，匹配与所述服务端对应的配置文件；

下发模块，用于向需要更新应用程序的节点，下发更新指令；其中，所述更新指令包括：更新包；

更新模块，用于将所述更新包分发至各节点，停止并备份原始集群中各业务系统应用程序，解压所述更新包并启动程序；

监控模块，用于实时监控检测运行中的集群中各应用程序版本，如检测到版本不一致的主机，对主机进行纠错处理，将最新版本程序进行更新；若更新失败，则强行清理当前程序所有相关进程，将问题主机与正常主机隔离。

9.根据权利要求8所述的一种更新应用程序的装置，其特征在于，在所述下发模块用于向需要更新应用程序的节点，下发更新指令之前，所述装置还配置为，包括：

10.根据权利要求8所述的一种更新应用程序的装置，其特征在于，所述装置还配置为，包括：

11.根据权利要求8所述的一种更新应用程序的装置，其特征在于，所述装置还配置为，包括：

12.根据权利要求8所述的更新应用程序的装置，其特征在于，所述装置还配置为：

13.根据权利要求8或12所述的更新应用程序的装置，其特征在于，所述装置还配置为，包括：

14.根据权利要求8或9所述的更新应用程序的装置，其特征在于，所述装置还配置为，包括：

15.一种电子设备，其特征在于，包括：

存储器；

处理器，与所述存储器连接，用于通过存储所述存储器存储的计算机执行指令，能够实现权利要求1至7任一项所述的方法。

16.一种计算机存储介质，其特征在于，所述计算机存储介质存储有所述计算机可执行指令；所述计算机可执行指令被处理器执行后，能够实现权利要求1至7任一项所述的方法。