CN106557347B - 软件更新方法及装置 - Google Patents

Abstract

本公开是关于一种软件更新方法及装置，该方法包括接收一包括将待更新软件的软件版本信息以及配置文件信息的软件安装数据上传的请求，并响应所述请求接收上传的所述软件安装数据；在接收到上传的所述软件安装数据后，创建一与所述待更新软件关联的运行策略；在所述运行策略创建完成后，将所述软件版本信息、配置文件版本信息以及运行策略版本信息发送至一Redis缓存中；以及根据所述软件版本信息、配置文件版本信息以及运行策略版本信息更新所述Redis缓存中的指令信息以使得当一客户端扫描到更新后的指令信息时更新所述待更新软件。本公开可以节省人力和时间成本。

Description

软件更新方法及装置

技术领域

本公开涉及软件工程技术领域，具体而言，涉及一种软件更新方法以及一种软件更新装置。

背景技术

目前，在大部分软件企业中，应用软件的更新部署大部分都依赖于运营维护人员通过手工进行发布；静态以及数据库的配置文件也没有纳入统一配置管理；并且客户端运行环境策略等还都依赖与其他平台。上述各模块的运行流程例如可以包括应用服务端将配置文件打进war包(一种压缩文件包格式)后，再通知运营维护人员通过人工发布上线，然后再通过其他平台了解客户端运行状态；上述各模块各自经营，部署上线流程也相对独立。

但是，上述上线步骤的劣势例如可以包括下述几个方面。首先，对于应用软件、配置文件的管理和维护都很不方便；其次，对于客户端的运行状态反馈的不够及时也不够全面，而且对应用软件及配置文件的编辑对相关开发人员没有权限管控，在不同的环境部署应用以及人工重启集群应用都需要耗费一定的运营维护人员的人力成本和时间成本，而且容易疏忽出错。并且，在高发布量的情况下，上述上线步骤的劣势更为明显。

需要说明的是，在上述背景技术部分公开的信息仅用于加强对本公开的背景的理解，因此可以包括不构成对本领域普通技术人员已知的现有技术的信息。

发明内容

本公开的目的在于提供一种软件升级方法以及一种软件升级装置，进而至少在一定程度上克服由于相关技术的限制和缺陷而导致的一个或者多个问题。

根据本公开的一个方面，提供一种软件更新方法，包括：

接收一包括将待更新软件的软件版本信息以及配置文件信息的软件安装数据上传的请求，并响应所述请求接收上传的所述软件安装数据；

在接收到上传的所述软件安装数据后，创建一与所述待更新软件关联的运行策略；

在所述运行策略创建完成后，将所述软件版本信息、配置文件版本信息以及运行策略版本信息发送至一Redis缓存中；以及

根据所述软件版本信息、配置文件版本信息以及运行策略版本信息更新所述Redis缓存中的指令信息以使得当一客户端扫描到更新后的指令信息时更新所述待更新软件。

在本公开的一种示例性实施例中，在创建一与所述待更新软件关联的运行策略之前还包括：

将接收到的上传的所述软件安装数据保存到服务端本地磁盘中。

在本公开的一种示例性实施例中，在创建一与所述待更新软件关联的运行策略之后还包括：

创建一与所述待更新软件关联的客户端运行流程；以及

将所述软件安装数据、所述运行策略以及所述客户端运行流程保存至一数据库中。

在本公开的一种示例性实施例中，所述软件更新方法还包括：

获取所述Redis缓存中与所述待更新软件关联的更新结果并将所述更新结果更新到所述待更新软件的发布状态中。

在本公开的一种示例性实施例中，所述指令信息包括软件版本号信息、软件配置版本号信息以及容器重启指令标志信息中的一种或多种；其中，更新所述Redis缓存中的指令信息包括：

更新所述Redis缓存中与所述待更新软件相关的软件版本号以及软件配置版本号；

更新所述Redis缓存中与所述待更新软件相关的容器重启指令标志信息；其中，所述容器重启指令标志信息用于指示所述待更新软件更新完成后是否需要重启所述客户端。

根据本公开的另一个方面，提供一种软件更新方法，包括：

每隔一预设时间，扫描一次上述任意一项所述的Redis缓存；

当扫描到所述Redis缓存中有更新后的指令信息时，判断所述Redis缓存中更新以后的指令信息与原始的指令信息是否相同；

在判断所述更新以后的指令信息与原始的指令信息不同时，获取所述软件安装数据；

根据所述安装数据更新所述待更新软件，并扫描与所述待更新软件相关的日志，判断所述待更新软件是否更新成功；

在判断所述待更新软件更新成功后，将更新结果发送至所述Redis缓存中。

在本公开的一种示例性实施例中，获取所述软件安装数据包括：

通过超文本传送协议拉取所述软件安装数据并从所述服务端磁盘中将所述软件安装数据按照指定的路径下载到客户端本地磁盘中。

根据本公开的另一个方面，提供一种软件更新装置，包括：

安装数据接收模块：用于接收一包括将待更新软件的软件版本信息以及配置文件信息的软件安装数据上传的请求，并响应所述请求接收上传的所述软件安装数据；

运行策略创建模块：用于在接收到上传的所述软件安装数据后，创建一与所述待更新软件关联的运行策略；

信息发送模块：用于在所述运行策略创建完成后，将所述软件版本信息、配置文件版本信息以及运行策略版本信息发送至一Redis缓存中；以及

指令信息更新模块：用于根据所述软件版本信息、配置文件版本信息以及运行策略版本信息更新所述Redis缓存中的指令信息以使得当一客户端扫描到更新后的指令信息时更新所述待更新软件。

在本公开的一种示例性实施例中，在创建一与所述待更新软件关联的运行策略之前还包括：

将接收到的上传的所述软件安装数据保存到服务端本地磁盘中。

在本公开的一种示例性实施例中，在创建一与所述待更新软件关联的运行策略之后还包括：

创建一与所述待更新软件关联的客户端运行流程；以及

将所述软件安装数据、所述运行策略以及所述客户端运行流程保存至一数据库中。

在本公开的一种示例性实施例中，所述软件更新装置还包括：

更新结果获取模块：用于获取所述Redis缓存中与所述待更新软件关联的更新结果并将所述更新结果更新到所述待更新软件的发布状态中。

在本公开的一种示例性实施例中，所述指令信息包括软件版本号信息、软件配置版本号信息以及容器重启指令标志信息中的一种或多种；其中，更新所述Redis缓存的指令信息包括：

更新所述Redis缓存中与所述待更新软件相关的软件版本号以及软件配置版本号；

更新所述Redis缓存中与所述待更新软件相关的容器重启指令标志信息；其中，所述容器重启指令标志信息用于指示所述待更新软件更新完成后是否需要重启所述客户端。

根据本公开的另一个方面，提供一种软件更新装置，包括：

扫描模块：用于每隔一预设时间，扫描一次上述任意一项所述的Redis缓存；

指令信息判断模块：用于当扫描到所述Redis缓存中有更新后的指令信息时，判断所述Redis缓存中更新以后的指令信息与原始的指令信息是否相同；

安装数据获取模块：用于在判断所述更新以后的指令信息与原始的指令信息不同时，获取所述软件安装数据；

软件更新模块：用于根据所述安装数据更新所述待更新软件，并扫描与所述待更新软件相关的日志，判断所述待更新软件是否更新成功；

更新结果发送模块：用于在判断所述待更新软件更新成功后，将更新结果发送至所述Redis缓存。

在本公开的一种示例性实施例中，获取所述软件安装数据包括：

通过超文本传送协议拉取所述软件安装数据并从所述服务端磁盘中将所述软件安装数据按照指定的路径下载到客户端本地磁盘中。

本公开一种软件升级方法及装置，接收上传的待更新软件的软件安装数据，然后创建一与待更新软件关联的运行策略并将软件版本信息、配置文件版本信息以及运行策略版本信息发送至一Redis缓存中；然后再更新Redis缓存中的指令信息以使得当客户端扫描到更新后的指令信息时更新待更新软件；一方面，通过将软件版本信息、软件配置文件信息以及运行策略发布到同一服务端，使得软件各个部分的数据管理和维护起来更加的方便，节省了人力和时间成本；另一方面，通过将更新Redis的指令信息，使得当客户端检测到有新的指令信息时，可以及时的更新待更新的软件，提升了用户体验。

本公开的另一种软件更新方法及装置，通过将软件版本信息以及配置文件信息保存到客户端本地磁盘中，客户端可以直接发起通过超文本传送协议请求从客户端本地磁盘中下载配置文件，减少了数据库的压力，更加适用于并发访问量较高的情况，提高了下载速度。

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

附图说明

此处的附图被并入说明书中并构成本说明书的一部分，示出了符合本公开的实施例，并与说明书一起用于解释本公开的原理。显而易见地，下面描述中的附图仅仅是本公开的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1示意性示出一种软件更新方法的流程图。

图2示意性示出更新Redis缓存中的指令信息的方法流程图。

图3示意性示出另一种软件更新方法的流程图。

图4示意性示出一种软件更新装置的方框图。

具体实施方式

现在将参考附图更全面地描述示例实施方式。然而，示例实施方式能够以多种形式实施，且不应被理解为限于在此阐述的范例；相反，提供这些实施方式使得本公开将更加全面和完整，并将示例实施方式的构思全面地传达给本领域的技术人员。所描述的特征、结构或特性可以以任何合适的方式结合在一个或更多实施方式中。在下面的描述中，提供许多具体细节从而给出对本公开的实施方式的充分理解。然而，本领域技术人员将意识到，可以实践本公开的技术方案而省略所述特定细节中的一个或更多，或者可以采用其它的方法、组元、装置、步骤等。在其它情况下，不详细示出或描述公知技术方案以避免喧宾夺主而使得本公开的各方面变得模糊。

此外，附图仅为本公开的示意性图解，并非一定是按比例绘制。图中相同的附图标记表示相同或类似的部分，因而将省略对它们的重复描述。附图中所示的一些方框图是功能实体，不一定必须与物理或逻辑上独立的实体相对应。可以采用软件形式来实现这些功能实体，或在一个或多个硬件模块或集成电路中实现这些功能实体，或在不同网络和/或处理器装置和/或微控制器装置中实现这些功能实体。

传统的软件公司的应用软件部署以及配置文件编辑方式可以包括由开发人员本地编辑后存放到指定应用的相关目录；其上线部署方式可以包括将配置文件与war包一同发布到服务器上。上述过程是由开发人员将配置文件以及war包提交申请给运营维护人员，然后运营维护人员在适当时机分别对应用的多台服务器一一人工部署。其中，配置文件的内容准确性完全由开发人员提交方确保；当运维人员部署war包后再确认重启是否成功。上述过程完全依靠人工操作，不但费时而且费力。

基于上述问题，本示例实施方式中首先提供了一种软件升级方法。参考图1中所示，该软件升级方法可以包括以下步骤：

步骤S110.接收一包括将待更新软件的软件版本信息以及配置文件信息的软件安装数据上传的请求，并响应所述请求接收上传的所述软件安装数据。

步骤S120.在接收到上传的所述软件安装数据后，创建一与所述待更新软件关联的运行策略。

步骤S130.在所述运行策略创建完成后，将所述软件版本信息、配置文件版本信息以及运行策略版本信息发送至一Redis缓存中。

步骤S140.根据所述软件版本信息、配置文件版本信息以及运行策略版本信息更新所述Redis缓存中的指令信息以使得当一客户端扫描到更新后的指令信息时更新所述待更新软件。

上述软件升级方法中，一方面，通过将软件版本信息、软件配置文件信息以及运行策略发布到同一服务端，使得软件各个部分的数据管理和维护起来更加的方便，节省了人力和时间成本；另一方面，通过将更新Redis的指令信息，使得当客户端检测到有新的指令信息时，可以及时的更新待更新的软件，提升了用户体验。

下面，将对本示例实施方式中上述软件升级方法的各步骤进行详细的说明。

在步骤S110中，接收一包括将待更新软件的软件版本信息以及配置文件信息的软件安装数据上传的请求，并响应所述请求接收上传的所述软件安装数据。

在本示例实施方式中，软件开发人员可以在一客户端上传一待更新软件的软件版本信息以及配置文件信息，客户端向服务端发送一上传请求；服务端响应该上传请求并接收文件。当上传完成后，将上传的软件版本信息以及配置文件信息永久的保存到服务端的本地磁盘中，这样，当客户端通过HTTP(HyperText Transfer Protocol，超文本传输协议)或者Socket(套接字)发送下载文件版本信息以及配置文件的请求时，可以直接从本地磁盘进行下载，大大的减小了对数据库的请求压力；并且，在并发访问量较高的情况下，服务端本地磁盘的输入/输出性能高于数据库，可以支持更大的客户端请求量，大大的节省了客户端的时间成本。其中，上述服务端例如可以是双机HA(High Available，高可用性集群)；双机HA采用定时同步，保证了双机配置文件的一致性；双机HA支持双机之间的通信机制，请求路由到某台服务器，更新配置成功后，通知另外一台服务器更新最新配置并持久化；通过定时同步以及通信机制，从而实现业务的不中断或短暂中断。上述服务端操作界面例如可以包括权限管理、应用软件管理、配置管理、应用软件在线上传更新、配置在线编辑以及策略编辑等等；也可以包括软件开发、软件测试、软件预发布、软件生产环境以及人员角色(例如可以包括开发人员以及运营维护人员等，也可以根据实际操作流程设置相应的角色，本示例实施方式对此不做特殊限制)权限设置(通过设置角色权限，减少了出错率)等等。此外，在本公开的其他示例性实施例中，也可以根据实际情况对上述服务端操作界面进行其他的定义，本示例性实施例中对此不做特殊限定。

在步骤S120中，在接收到上传的所述软件安装数据后，创建一与所述待更新软件关联的运行策略。

在本示例实施方式中，当开发人员将软件版本信息以及配置文件上传完成以后，运营维护人员可以登录服务端操作界面定制与待更新软件关联的运行策略；运行策略例如可以包括重启/关闭容器重启指令标志信息、监控客户端状态或者监控客户端磁盘状态等等；上述容器例如可以包括应用服务器中位于组件和平台之间的接口集合，一般位于应用服务器之内，由应用服务器负责加载和维护。此外，在本公开的其他示例性实施例中，也可以根据实际情况对上述运行策略进行其他的定义，本示例性实施例中对此不做特殊限定。

在步骤S130中，在所述运行策略创建完成后，将所述软件版本信息、配置文件版本信息以及运行策略版本信息发送至一Redis缓存中。

在本示例实施方式中，上述Redis缓存例如可以是一开源的利用ANSIC语言编写的并且可以支持网络也可以基于内存亦可持久化的日志型或者Key-Value(分布式存储系统)数据库，并且可以提供多种编程语言的API(Application Programming Interface，应用程序编程接口)，具备高可用、数据结构丰富、简单易用、持久化以及高速读写等特点；服务端通过API接口将软件版本信息、配置文件版本信息以及运行策略版本信息发送至上述Redis缓存中。此外，在本公开的其他示例性实施例中，也可以根据实际情况将所述软件版本信息、配置文件版本信息以及运行策略版本信息发送至其他的缓存中，本示例性实施例中对此不做特殊限定。

在本示例的另一种实施方式中，在创建一与所述待更新软件关联的运行策略之后还包括：创建一与所述待更新软件关联的客户端运行流程；以及将所述软件安装数据、所述运行策略以及所述客户端运行流程保存至一数据库(例如可以包括mysql、oracle或者database等等，可以根据实际情况具体设定，本公开对此不做特殊限定)中。创建一与所述待更新软件关联的客户端运行流程可以使得客户端在后期更新软件时，可以更加有效的提高更新速度以及更新的准确率，减少了时间成本；将所有的数据备份至数据库中，可以防止由于服务端硬件设备损坏对软件更新造成的损失

在步骤S140中，根据所述软件版本信息、配置文件版本信息以及运行策略版本信息更新所述Redis缓存中的指令信息以使得当一客户端扫描到更新后的指令信息时更新所述待更新软件。参考图2所示，更新所述Redis缓存中的指令信息可以包括步骤S1402～S1404。其中：

在步骤S1402中，更新所述Redis缓存中与所述待更新软件相关的软件版本号以及软件配置版本号；在步骤S1404中，更新所述Redis缓存中与所述待更新软件相关的容器重启指令标志信息。

在本示例实施方式中，上述指令信息例如可以包括软件版本号信息、软件配置版本号信息以及容器重启指令标志信息等等；其中，容器重启指令标志信息用于指示所述待更新软件更新完成后是否需要重启所述客户端。具体而言：

当Redis缓存接收到服务端发送的软件版本信息、配置文件版本信息以及运行策略版本信息时，根据软件版本信息、配置文件版本信息以及运行策略版本信息更新Redis缓存中历史存储的软件版本号信息、软件配置版本号信息以及容器重启指令标志信息等等；例如可以包括将软件版本号+1、将软件配置版本号+1以及根据实际情况将tomcat(容器)重启指令标志信息更新为是否需要重新启动。此外，在本公开的其他示例性实施例中，也可以根据实际情况更新Redis缓存中的其他信息，例如系统指令内容等等，本示例性实施例中对此不做特殊限定。

在本公开的另一种示例实施方式中，所述软件更新方法还可以包括：获取所述Redis缓存中与所述待更新软件关联的更新结果并将所述更新结果更新到所述待更新软件的发布状态中。具体而言：

当客户端软件更新完成以后，会将软件更新的结果发送到Redis缓存中，然后服务端通过扫描Redis缓存获取最新的软件更新的结果；当扫描到有最新的软件更新的结果时，从Redis缓存中获取软件更新的结果并将软件更新的结果展现在服务端的界面中并更新软件的发布状态。此外，在本公开的其他示例性实施例中，也可以根据实际情况以其他的方式及时获取软件更新的结果，比如客户端直接将软件更新的结果发送给服务端，本示例性实施例中对此不做特殊限定。

本示例实施方式中还提供了另一种软件升级方法。参考图3中所示，该软件升级方法可以包括步骤S310～S350。其中：

在步骤S310中，每隔一预设时间，扫描一次上述任意一项所述的Redis缓存；在步骤S320中，当扫描到所述Redis缓存中有更新后的指令信息时，判断所述Redis缓存中更新以后的指令信息与原始的指令信息是否相同；在步骤S330中，在判断所述更新以后的指令信息与原始的指令信息不同时，获取所述软件安装数据；在步骤S340中，根据所述安装数据更新所述待更新软件，并扫描与所述待更新软件相关的日志，判断所述待更新软件是否更新成功；在步骤S350中，在判断所述待更新软件更新成功后，将更新结果发送至所述Redis缓存中。举例而言：

客户端每隔一预设时间(例如可以是1s、3s或者5s等等，可以根据实际情况具体设定，本公开对此不做特殊限定)扫描一次Redis缓存，当扫描到所述Redis缓存中有更新后的指令信息时，判断所述Redis缓存中更新以后的指令信息与原始的指令信息是否相同(例如可以包括判断更新后的版本号是否与原始的版本号相同、更新后的配置版本号是否与原始的版本号相同或者更新后的容器重启指令标志信息是否与原始的容器重启指令标志信息相同)；当判断更新以后的指令信息与原始的指令信息不同时，通过HTTP(HyperTextTransfer Protocol，超文本传送协议)或者Socket(套接字)拉取所述软件安装数据并从所述服务端磁盘中将所述软件安装数据按照指定的路径(可以通过环境变量设定客户端配置加载路径，例如可以是：$global.config.path＝/home/config-web/app-test,agentclient等等)下载到客户端本地磁盘中；下载完成后，根据管理人员制定的软件运行流程进行软件更新并扫描生成的相关日志，根据日志判断软件是否更新成功；当软件更新成功后，将更新成功的结果发送到Redis缓存中。此外，在本公开的其他示例性实施例中，也可以根据实际情况以其他的方式获取软件安装数据，本示例性实施例中对此不做特殊限定。

在本示例的另一种实施方式中，当判断更新以后的指令信息与原始的指令信息不同但是客户端并没有进行后面的通过HTTP或者Socket(拉取所述软件安装数据并从所述服务端磁盘中将所述软件安装数据按照指定的路径下载到客户端本地磁盘中的步骤时，客户端继续每隔一上述预设时间扫描一次Redis缓存。

在本示例的另一种实施方式中，当发生网络故障、网络阻塞等情况不能实现与服务端的通信连接时，客户端可以预设一延长时间(例如可以是5min、10min或者30min等等，可以根据实际情况具体设定，本公开对此不做特殊限定)停止拉取操作，当客户端恢复通信连接时，自动加载上一次拉取的配置信息，采用自动加载的方式节省了客户端的时间，提高了效率。此外，在本公开的其他示例性实施例中，也可以根据实际情况以其他的方式来解决由于网络故障导致拉取失败的问题，本示例性实施例中对此不做特殊限定。

此外，尽管在附图中以特定顺序描述了本公开中方法的各个步骤，但是，这并非要求或者暗示必须按照该特定顺序来执行这些步骤，或是必须执行全部所示的步骤才能实现期望的结果。附加的或备选的，可以省略某些步骤，将多个步骤合并为一个步骤执行，以及/或者将一个步骤分解为多个步骤执行等。

本示例实施方式提供了另一种软件更新装置，参考图4所示，上述软件更新装置可以包括：安装数据接收模块410、运行策略创建模块420、信息发送模块430以及指令信息更新模块440。其中：

安装数据接收模块410可以用于接收一包括将待更新软件的软件版本信息以及配置文件信息的软件安装数据上传的请求，并响应所述请求接收上传的所述软件安装数据。

运行策略创建模块420可以用于在接收到上传的所述软件安装数据后，创建一与所述待更新软件关联的运行策略。

信息发送模块430可以用于在所述运行策略创建完成后，将所述软件版本信息、配置文件版本信息以及运行策略版本信息发送至一Redis缓存中。

指令信息更新模块440可以用于根据所述软件版本信息、配置文件版本信息以及运行策略版本信息更新所述Redis缓存中的指令信息以使得当一客户端扫描到更新后的指令信息时更新所述待更新软件。

在本示例实施方式中，在创建一与所述待更新软件关联的运行策略之前还包括：

将接收到的上传的所述软件安装数据保存到服务端本地磁盘中。

在本示例实施方式中，在创建一与所述待更新软件关联的运行策略之后还包括：

创建一与所述待更新软件关联的客户端运行流程；以及将所述软件安装数据、所述运行策略以及所述客户端运行流程保存至一数据库中。

在本示例实施方式中，所述软件更新装置还包括：

更新结果获取模块可以用于获取所述Redis缓存中与所述待更新软件关联的更新结果并将所述更新结果更新到所述待更新软件的发布状态中。

在本示例实施方式中，所述指令信息包括软件版本号信息、软件配置版本号信息以及容器重启指令标志信息中的一种或多种；其中，更新所述Redis缓存的指令信息包括：

更新所述Redis缓存中与所述待更新软件相关的软件版本号以及软件配置版本号；更新所述Redis缓存中与所述待更新软件相关的容器重启指令标志信息；其中，所述容器重启指令标志信息用于指示所述待更新软件更新完成后是否需要重启所述客户端。

在另一种示例实施方式中上述软件更新装置还包括：

扫描模块可以用于每隔一预设时间，扫描一次上述任意一项所述的Redis缓存。

指令信息判断模块可以用于当扫描到所述Redis缓存中有更新后的指令信息时，判断所述Redis缓存中更新以后的指令信息与原始的指令信息是否相同。

安装数据获取模块可以用于在判断所述更新以后的指令信息与原始的指令信息不同时，获取所述软件安装数据。

软件更新模块可以用于根据所述安装数据更新所述待更新软件，并扫描与所述待更新软件相关的日志，判断所述待更新软件是否更新成功。

更新结果发送模块可以用于在判断所述待更新软件更新成功后，将更新结果发送至所述Redis缓存。

在本示例实施方式中，获取所述软件安装数据包括：

通过超文本传送协议拉取所述软件安装数据并从所述服务端磁盘中将所述软件安装数据按照指定的路径下载到客户端本地磁盘中。

上述软件更新装置中各模块的具体细节已经在对应的软件更新方法中进行了详细想描述，因此此处不再赘述。

应当注意，尽管在上文详细描述中提及了用于动作执行的设备的若干模块或者单元，但是这种划分并非强制性的。实际上，根据本公开的实施方式，上文描述的两个或更多模块或者单元的特征和功能可以在一个模块或者单元中具体化。反之，上文描述的一个模块或者单元的特征和功能可以进一步划分为由多个模块或者单元来具体化。

通过以上的实施方式的描述，本领域的技术人员易于理解，这里描述的示例实施方式可以通过软件实现，也可以通过软件结合必要的硬件的方式来实现。因此，根据本公开实施方式的技术方案可以以软件产品的形式体现出来，该软件产品可以存储在一个非易失性存储介质(可以是CD-ROM，U盘，移动硬盘等)中或网络上，包括若干指令以使得一台计算设备(可以是个人计算机、服务器、移动终端、或者网络设备等)执行根据本公开实施方式的方法。

本领域技术人员在考虑说明书及实践这里公开的发明后，将容易想到本公开的其它实施方案。本申请旨在涵盖本公开的任何变型、用途或者适应性变化，这些变型、用途或者适应性变化遵循本公开的一般性原理并包括本公开未公开的本技术领域中的公知常识或惯用技术手段。说明书和实施例仅被视为示例性的，本公开的真正范围和精神由所附的权利要求指出。

Claims (12)

1.一种软件更新方法，其特征在于，应用于服务端，所述服务端为双机高可用性集群，所述双机高可用性集群采用定时同步以及通信机制，以实现软件更新的不中断，所述软件更新方法包括：

接收一包括将待更新软件的软件版本信息以及配置文件信息的软件安装数据上传的请求，并响应所述请求接收上传的所述软件安装数据；

在接收到上传的所述软件安装数据后，创建一与所述待更新软件关联的运行策略；其中，所述运行策略包括重启/关闭容器重启指令标志信息；

在所述运行策略创建完成后，将所述软件版本信息、配置文件版本信息以及运行策略版本信息发送至一Redis缓存中；以及

根据所述软件版本信息、配置文件版本信息以及运行策略版本信息更新所述Redis缓存中的指令信息以使得当一客户端扫描到更新后的指令信息时更新所述待更新软件；所述指令信息包括软件版本号信息、软件配置版本号信息以及容器重启指令标志信息中的一种或多种；

其中，更新所述Redis缓存中的指令信息包括：

更新所述Redis缓存中与所述待更新软件相关的软件版本号以及软件配置版本号；

更新所述Redis缓存中与所述待更新软件相关的容器重启指令标志信息；其中，容器重启指令标志信息用于指示所述待更新软件更新完成后是否需要重启所述客户端。

2.根据权利要求1所述的软件更新方法，其特征在于，在创建一与所述待更新软件关联的运行策略之前还包括：

将接收到的上传的所述软件安装数据保存到服务端本地磁盘中。

3.根据权利要求1所述的软件更新方法，其特征在于，在创建一与所述待更新软件关联的运行策略之后还包括：

创建一与所述待更新软件关联的客户端运行流程；以及

将所述软件安装数据、所述运行策略以及所述客户端运行流程保存至一数据库中。

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

获取所述Redis缓存中与所述待更新软件关联的更新结果并将所述更新结果更新到所述待更新软件的发布状态中。

5.一种软件更新方法，其特征在于，包括：

每隔一预设时间，扫描一次权利要求1～4中任意一项所述的Redis缓存；

当扫描到所述Redis缓存中有更新后的指令信息时，判断所述Redis缓存中更新以后的指令信息与原始的指令信息是否相同；

在判断所述更新以后的指令信息与原始的指令信息不同时，获取所述软件安装数据；

根据所述安装数据更新所述待更新软件，并扫描与所述待更新软件相关的日志，判断所述待更新软件是否更新成功；

在判断所述待更新软件更新成功后，将更新结果发送至所述Redis缓存中。

6.根据权利要求5所述的软件更新方法，其特征在于，获取所述软件安装数据包括：

通过超文本传送协议拉取所述软件安装数据并从所述服务端磁盘中将所述软件安装数据按照指定的路径下载到客户端本地磁盘中。

7.一种软件更新装置，应用于服务端，所述服务端为双机高可用性集群，所述双机高可用性集群采用定时同步以及通信机制，以实现软件更新的不中断，其特征在于，该软件更新装置包括：

安装数据接收模块：用于接收一包括将待更新软件的软件版本信息以及配置文件信息的软件安装数据上传的请求，并响应所述请求接收上传的所述软件安装数据；

运行策略创建模块：用于在接收到上传的所述软件安装数据后，创建一与所述待更新软件关联的运行策略；其中，所述运行策略包括重启/关闭容器重启指令标志信息、监控客户端状态或者监控客户端磁盘状态中的至少一种；

信息发送模块：用于在所述运行策略创建完成后，将所述软件版本信息、配置文件版本信息以及运行策略版本信息发送至一Redis缓存中；以及

指令信息更新模块：用于根据所述软件版本信息、配置文件版本信息以及运行策略版本信息更新所述Redis缓存中的指令信息以使得当一客户端扫描到更新后的指令信息时更新所述待更新软件；其中，所述指令信息包括软件版本号信息、软件配置版本号信息以及容器重启指令标志信息中的一种或多种；

其中，更新所述Redis缓存的指令信息包括：

更新所述Redis缓存中与所述待更新软件相关的软件版本号以及软件配置版本号；

更新所述Redis缓存中与所述待更新软件相关的容器重启指令标志信息；其中，所述容器重启指令标志信息用于指示所述待更新软件更新完成后是否需要重启所述客户端。

8.根据权利要求7所述的软件更新装置，其特征在于，在创建一与所述待更新软件关联的运行策略之前还包括：

将接收到的上传的所述软件安装数据保存到服务端本地磁盘中。

9.根据权利要求7所述的软件更新装置，其特征在于，在创建一与所述待更新软件关联的运行策略之后还包括：

创建一与所述待更新软件关联的客户端运行流程；以及

将所述软件安装数据、所述运行策略以及所述客户端运行流程保存至一数据库中。

10.根据权利要求7所述的软件更新装置，其特征在于，所述软件更新装置还包括：

更新结果获取模块：用于获取所述Redis缓存中与所述待更新软件关联的更新结果并将所述更新结果更新到所述待更新软件的发布状态中。

11.一种软件更新装置，其特征在于，包括：

扫描模块：用于每隔一预设时间，扫描一次权利要求1～4中任意一项所述的Redis缓存；

指令信息判断模块：用于当扫描到所述Redis缓存中有更新后的指令信息时，判断所述Redis缓存中更新以后的指令信息与原始的指令信息是否相同；

安装数据获取模块：用于在判断所述更新以后的指令信息与原始的指令信息不同时，获取所述软件安装数据；

软件更新模块：用于根据所述安装数据更新所述待更新软件，并扫描与所述待更新软件相关的日志，判断所述待更新软件是否更新成功；

更新结果发送模块：用于在判断所述待更新软件更新成功后，将更新结果发送至所述Redis缓存。

12.根据权利要求11所述的软件更新装置，其特征在于，获取所述软件安装数据包括：

通过超文本传送协议拉取所述软件安装数据并从所述服务端磁盘中将所述软件安装数据按照指定的路径下载到客户端本地磁盘中。

Images