CN115454762A - 系统监测和升级方法、电子设备和计算机可读存储介质 - Google Patents

Abstract

本申请公开了一种系统监测和升级方法、电子设备和计算机可读存储介质，该方法包括：获得启动指令，执行启动指令启动系统的监测进程，利用监测进程启动系统中的各个子服务，并对各个子服务进行健康监测，获得至少一轮健康监测结果；响应于第一预设轮次的健康监测结果为异常，重启系统；响应于系统的上层应用调用应用程序接口，利用应用程序接口获得系统的升级包，备份系统当前的安装包，得到备份版本，利用系统的定时任务加载升级包对系统进行升级，完成升级后重启系统并返回获得启动指令的步骤；响应于第二预设轮次的健康监测结果为异常，将系统回滚至备份版本，其中，第二预设轮次在系统升级之后。上述方案，能够提高系统使用的便捷度和稳定性。

Description

系统监测和升级方法、电子设备和计算机可读存储介质

技术领域

本申请涉及系统管理技术领域，特别是涉及一种系统监测和升级方法、电子设备和计算机可读存储介质。

背景技术

随着各类系统所能支持的功能愈发强大，如何对系统进行健康监测以及如何在功能更新后对系统进行升级愈发得到重视，现有技术中，通常需要系统开发者定期对系统进行监测，获取监测数据来确定系统的健康状况，并且，当需要对系统进行升级时，也需要系统开发者接入系统的服务器端提供服务支持，并指定升级包才能对系统进行升级，导致对系统进行健康监测和升级较为不便，同时，对于升级包是否与系统匹配缺乏必要的检测手段，以致升级后的系统可能无法使用，系统的稳定性受到影响。有鉴于此，如何提高系统使用的便捷度和稳定性成了亟待解决的问题。

发明内容

本申请主要解决的技术问题是提供一种系统监测和升级方法、电子设备和计算机可读存储介质，能够提高系统使用的便捷度和稳定性。

为解决上述技术问题，本申请第一方面提供一种系统监测和升级方法，包括：获得启动指令，执行所述启动指令启动系统的监测进程，利用所述监测进程启动所述系统中的各个子服务，并对各个所述子服务进行健康监测，获得至少一轮健康监测结果；响应于第一预设轮次的健康监测结果为异常，重启所述系统；响应于所述系统的上层应用调用应用程序接口，利用所述应用程序接口获得所述系统的升级包，备份所述系统当前的安装包，得到备份版本，利用所述系统的定时任务加载所述升级包对所述系统进行升级，完成升级后重启所述系统并返回所述获得启动指令的步骤；响应于第二预设轮次的健康监测结果为异常，将所述系统回滚至所述备份版本，其中，所述第二预设轮次在所述系统升级之后。

为解决上述技术问题，本申请第二方面提供一种电子设备，该电子设备包括：相互耦接的存储器和处理器，其中，所述存储器存储有程序数据，所述处理器调用所述程序数据以执行上述第一方面所述的方法。

为解决上述技术问题，本申请第三方面提供一种计算机存储介质，其上存储有程序数据，所述程序数据被处理器执行时实现上述第一方面所述的方法。

上述方案，当获得启动指令后，执行启动指令以启动系统的监测进程，利用监测进程启动系统的各个子服务，并利用监测进程对各个子服务进行健康监测，从而在系统启动后立即对系统进行健康监测，仅利用监测进程即可得到至少一轮健康监测结果，提高对系统进行健康监测的便捷度，当第一预设轮次的健康监测结果为异常时，重启系统以便能够尝试恢复系统的功能，提高系统的稳定性，当上层应用调用应用程序接口时，利用应用程序接口获得系统的升级包，以便用户端能够自主获取升级包，提高获取升级包的便捷性，同时备份系统当前的安装包，得到安装包的备份版本，进而利用系统的定时任务加载升级包对系统进行升级，通过系统的定时任务以便于准确获取系统的升级包对系统进行升级，并在完成升级后重启系统对系统继续进行健康监测，当系统升级之后所获得的第二预设轮次的健康监测结果为异常时，将系统回滚至备份版本，以确保系统能够继续使用，从而提高系统使用的便捷度和稳定性。

附图说明

为了更清楚地说明本申请实施例中的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。其中：

图1是本申请系统监测和升级方法一实施方式的流程示意图；

图2是本申请系统监测和升级方法另一实施方式的流程示意图；

图3是本申请系统监测和升级方法又一实施方式的流程示意图；

图4是本申请电子设备一实施方式的结构示意图；

图5是本申请系统监测和升级方法一实施方式的应用场景示意图；

图6是本申请计算机可读存储介质一实施方式的结构示意图。

具体实施方式

下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请一部分实施例，而不是全部实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性的劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

本文中术语“系统”和“网络”在本文中常被可互换使用。本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，本文中字符“/”，一般表示前后关联对象是一种“或”的关系。此外，本文中的“多”表示两个或者多于两个。

本申请所提供的系统监测和升级方法用于对用户端的系统进行健康监测和系统升级，其中，系统监测和升级方法对应的执行主体为用户端的处理器或处理模块。

请参阅图1，图1是本申请系统监测和升级方法一实施方式的流程示意图，该方法包括：

S101：获得启动指令，执行启动指令启动系统的监测进程，利用监测进程启动系统中的各个子服务，并对各个子服务进行健康监测，获得至少一轮健康监测结果。

具体地，当获得启动指令时，执行启动指令以启动系统的监测进程，利用监测进程启动系统中的各个子服务，并且利用监测进程对各个子服务进行健康监测，从而在系统启动后立即对系统进行健康监测，仅利用监测进程即可得到健康监测结果，提高对系统进行健康监测的便捷度。

进一步地，当监测进程完成一次对系统中所有子服务的健康监测，即为完成一轮健康监测，获得一轮健康监测结果。

在一应用方式中，触发启动指令后，获得启动指令并执行，基于启动指令启动系统的监测进程，利用监测进程启动系统中的各个子服务，各个子服务向监测进程发送生命周期信号，利用监测进程对各个子服务的生命周期信号进行监测，基于各个子服务的生命周期信号对各个子服务进行健康监测，从而获得至少一轮健康监测结果。

在另一应用方式中，触发启动指令后，获得启动指令并执行，基于启动指令启动系统的监测进程，利用监测进程启动系统中的各个子服务，各个子服务向监测进程发送通信请求，利用监测进程对各个子服务的通信请求进行监测，基于各个子服务的通信请求对各个子服务进行健康监测，从而获得至少一轮健康监测结果。

在一应用场景中，系统基于Docker容器构建，系统中的子服务对应有子服务模块，监测进程为系统的入口脚本，当获得启动指令后，执行启动指令启动系统则立即启动系统的入口脚本对应的监测进程，利用监测进程依次启动各个子服务对应的子服务模块，子服务模块向监测进程发送生命周期信号或通信请求，利用监测进程对各个子服务的生命周期信号或通信请求进行监测，基于各个子服务的生命周期信号或通信请求对各个子服务进行健康监测，从而获得至少一轮健康监测结果。

S102：响应于第一预设轮次的健康监测结果为异常，重启系统。

具体地，当第一预设轮次的健康监测结果为异常时，重启系统以便能够尝试恢复系统的功能，提高系统的稳定性。

在一应用场景中，第一预设轮次包括第一轮次之外的其他轮次，当区别于第一轮次的其他轮次的健康监测结果为异常时，直接重启系统，以尽快重启系统，以尝试恢复系统的功能。

在另一应用场景中，第一预设轮次包括任意轮次，当第一轮次的健康监测结果为异常时，等待子服务返回的通信请求，直至等待时长超过时长阈值，重启系统，当区别于第一轮次的其他轮次的健康监测结果为异常时，直接重启系统，以便在系统刚启动时，降低启动阶段通信请求返回迟滞的影响。

S103：响应于系统的上层应用调用应用程序接口，利用应用程序接口获得系统的升级包，备份系统当前的安装包，得到备份版本，利用系统的定时任务加载升级包对系统进行升级，完成升级后重启系统并返回获得启动指令的步骤。

具体地，当系统的上层应用调用应用程序接口时，利用应用程序接口获得系统的升级包，以便用户端能够自主获取升级包，提高获取升级包的便捷性，同时备份系统当前的安装包，得到安装包的备份版本。

在一应用方式中，升级包对应有可供下载的链接地址，当系统的上层应用调用应用程序接口时，利用应用程序接口获取链接地址并下载获得升级包，对系统当前的安装包的版本进行备份，得到备份版本。

在另一应用方式中，升级包对应有共享的安装文件，当系统的上层用于调用用于程序接口时，利用应用程序接口拷贝升级包的安装文件获得升级包，对系统当前的安装包的版本进行备份，得到备份版本。

进一步地，利用系统的定时任务加载升级包对系统进行升级，其中，定时任务用于在经过预设时间间隔后加载升级包，以免系统所获得的仍是原来的安装包，通过系统的定时任务以便于准确获取系统的升级包对系统进行升级，并在完成升级后重启系统，返回至步骤S101对系统继续进行健康监测。

在一应用场景中，升级包对应有名称，获得备份版本后，重启系统并利用系统的定时任务在系统重启后基于升级包的名称，加载名称对应的升级包以便准确获取到升级包对系统进行升级，并在完成升级后重启系统对系统继续进行健康监测。

在另一应用场景中，升级包对应有版本号，获得备份版本后，重启系统并利用系统的定时任务在系统重启后基于升级包的版本号，加载版本号对应的升级包以便准确获取到升级包对系统进行升级，并在完成升级后重启系统对系统继续进行健康监测。

S104：响应于第二预设轮次的健康监测结果为异常，将系统回滚至备份版本，其中，第二预设轮次在系统升级之后。

具体地，当系统升级之后的第二预设轮次的健康监测结果为异常时，获取备份版本的安装包，将系统回滚至备份版本，以确保系统能够继续使用，从而提高系统使用的便捷度和稳定性。

在一应用场景中，第二预设轮次为系统升级后的第一轮次，当第一轮次的健康监测结果为异常时，获取备份版本的安装包，将系统回滚至备份版本。

在另一应用场景中，第二预设轮次包括系统升级后预设时间段内的轮次，当预设时间段内的轮次对应的健康监测结果为异常时，获取备份版本的安装包，将系统回滚至备份版本。

可选地，系统升级后初次启动时包括升级记录，当第二预设轮次为第一轮次时，若第一轮次的健康监测结果为正常，则将升级记录删除，或者，当第二预设轮次为预设时间段内的轮次时，若超过预设时间段后的健康监测结果仍为正常，则将升级记录删除。

上述方案，当获得启动指令后，执行启动指令以启动系统的监测进程，利用监测进程启动系统的各个子服务，并利用监测进程对各个子服务进行健康监测，从而在系统启动后立即对系统进行健康监测，仅利用监测进程即可得到至少一轮健康监测结果，提高对系统进行健康监测的便捷度，当第一预设轮次的健康监测结果为异常时，重启系统以便能够尝试恢复系统的功能，提高系统的稳定性，当上层应用调用应用程序接口时，利用应用程序接口获得系统的升级包，以便用户端能够自主获取升级包，提高获取升级包的便捷性，同时备份系统当前的安装包，得到安装包的备份版本，进而利用系统的定时任务加载升级包对系统进行升级，通过系统的定时任务以便于准确获取系统的升级包对系统进行升级，并在完成升级后重启系统对系统继续进行健康监测，当系统升级之后所获得的第二预设轮次的健康监测结果为异常时，将系统回滚至备份版本，以确保系统能够继续使用，从而提高系统使用的便捷度和稳定性。

请参阅图2，图2是本申请系统监测和升级方法另一实施方式的流程示意图，其中，系统基于容器和容器管理工具构建，且系统在容器上运行，监测进程与系统的容器绑定。

具体地，系统基于容器(Docker)和容器管理工具(Docker Compose)构建。其中，系统对应有一个或多个容器，也就是说，系统对应至少一个容器且系统在容器上运行，从而能够在容器内提供系统的服务，监测进程作为系统的容器的入口脚本与系统的容器绑定，当系统启动时，监测进程随即启动，当监测进程退出后会使得所绑定的系统的容器也退出，以便当健康监测结果异常时，能够及时重启系统。

进一步地，容器管理工具通过配置文件来管理容器，在配置文件内可进行自定义设置，提高容器管理的自由度，藉由配置文件停止和重启应用，以及应用中的服务以及所有依赖服务的容器。

具体地，该系统监测和升级方法包括以下步骤：

S201：获得启动指令，利用容器管理工具执行启动指令，启动系统对应的容器及其绑定的监测进程。

具体地，获得启动指令，利用容器管理工具指定配置文件执行启动指令，基于启动指令启动系统对应的容器和容器所绑定的监测进程。

在一应用场景中，利用Docker Compose指定特定的yml配置文件执行启动指令，当系统启动时，即系统所在的Docker启动时，监测进程作为Docker的入口脚本执行。

S202：利用监测进程调用各个子服务的启动命令，启动系统中的各个子服务。

具体地，监测进程启动时首先依次调用各个子服务启动命令，以尝试启动子服务，当子服务响应启动命令后，系统中的子服务启动。

S203：接收各个子服务的通信请求，基于当前轮次的通信请求，确定当前轮次的健康监测结果，得到至少一轮健康监测结果。

具体地，各个子服务在启动后向监测进程发送通信请求，接收各个子服务的通信请求即可基于当前轮次的通信请求，判断当前轮次的健康监测结果，若所有子服务在当前轮次均返回有通信请求且返回值正确，则当前轮次的健康监测结果为正常，若所有子服务中存在子服务未返回通信请求或者存在子服务返回的返回值错误，则当前轮次的健康监测结果为异常。

进一步地，不同的子服务可能基于不同的编程语言构建，利用监测进程获取子服务的通信请求即可对子服务进行健康监测，无需对不同的编程语言的子服务进行针对性开发，减少对系统进行健康监测的资源消耗，提高系统使用的便捷度。

在一应用场景中，子服务向监测进程发送包括健康状况的Http请求，监测进程轮询调用各子服务提供的包含健康状况的Http请求，若其中某个子服务的Http请求返回的返回值错误或者未返回Http请求，监测进程在间隔5秒连续重试3次，若返回值仍错误或未返回Http请求，则判定该子服务异常，以便通过重复调用，降低离散值的影响，提高系统的稳定性。

可以理解的是，当监测进程启动任一子服务失败时，系统启动后的第一轮次的健康监测结果为异常，当监测进程接收到的当前轮次的通信请求存在异常时，当前轮次的健康监测结果为异常。其中，当监测进程启动任一子服务失败时，监测进程无法获取对应的子服务的通信请求，进而，第一轮次的健康监测结果为异常。

S204：响应于系统的上层应用调用应用程序接口，利用应用程序接口获得系统的升级包，备份系统当前的安装包，得到备份版本，利用系统的定时任务加载升级包对系统进行升级，完成升级后重启系统。

具体地，当系统的上层应用调用应用程序接口时，利用应用程序接口获得系统的升级包，以便用户端能够自主获取升级包，提高获取升级包的便捷性，同时备份系统当前的安装包，得到安装包的备份版本。

进一步地，利用系统的定时任务加载升级包对系统进行升级，并在完成升级后重启系统返回步骤S201。

需要说明的是，步骤S204的进入条件是系统的上层应用调用应用程序接口，若系统的上层应用未调用应用程序接口，则从步骤S203直接进入步骤S205，且在系统的健康监测结果为正常时，可随时响应上层应用调用应用程序接口，执行系统升级的过程，因此，步骤S204并不局限于在步骤S203和S205之间。

S205：判断当前轮次健康监测结果是否异常。

具体地，判断当前轮次的健康监测结果是否异常，若正常则进入步骤S206，若异常则进入步骤S207。

S206：响应于当前轮次的健康监测结果为正常，进入下一轮次的健康监测。

具体地，若当前轮次的监测结果为正常，则进入下一轮次的健康监测过程，返回至步骤S203，从而保证对系统中各个子服务持续不断地进行健康监测，并在健康监测结果出现异常时，及时执行对应的操作，提高系统的稳定性。

S207：判断当前轮次是否为第一预设轮次。

具体地，判断当前轮次是否为第一预设轮次，若是，则进入步骤S208，否则，进入步骤S210。

S208：响应于当前轮次为第一预设轮次且健康监测结果为异常，退出监测进程以使监测进程绑定的容器退出，返回第一错误码。

具体地，第一预设轮次为区别于第一轮次的其他轮次，第一错误码与第一预设轮次的通信请求存在异常相关。也就是说，第一预设轮次为系统启动后的第一轮次之外的其他任意轮次，第一错误码与第一预设轮次的通信请求存在异常相关，若当前轮次为第一预设轮次且健康监测结果为异常，则退出监测进程，使得监测进程所绑定的容器退出，使系统能够尽快重启并返回第一错误码，通过第一错误码来反馈健康监测结果，以便于处理终端基于第一错误码来执行相应操作。

S209：响应于获得第一错误码，利用容器管理工具重启系统对应的容器及其绑定的监测进程。

具体地，当获得第一错误码时，利用容器管理工具再次指定配置文件执行启动指令，基于启动指令启动系统对应的容器和容器所绑定的监测进程。

S210：响应于当前轮次为第二预设轮次且健康监测结果为异常，退出监测进程以使监测进程绑定的容器退出，返回第二错误码。

具体地，第二预设轮次为第一轮次且在系统升级之后，第二错误码与第二预设轮次的通信请求存在异常相关。也就是说，第二预设轮次为系统升级后再次启动时进行健康监测的第一轮次，第二错误码与第二预设轮次的通信请求存在异常或者在第一轮次子服务启动失败相关，若当前轮次为第二预设轮次且健康监测结果为异常，则退出监测进程，使得监测进程所绑定的容器退出，使系统能够尽快重启并返回第二错误码，通过第二错误码来反馈健康监测结果，以便于处理终端基于第二错误码来执行相应操作。

S211：响应于获得第二错误码，利用系统的定时任务加载备份版本的安装包，将系统回滚至备份版本。

具体地，当获得第二错误码时，利用系统的定时任务加载备份版本的安装包，此时，定时任务用于在经过预设时间间隔后加载安装包，利用备份版本的安装包将系统回滚至备份版本，从而确保系统能够继续使用。

需要说明的是，由于第二预设轮次对应为系统升级后再次启动之后的第一轮次，通常系统启动后第一轮次的健康监测结果即为异常，对应着升级包与系统不匹配，或者升级包存在漏洞的情景，因此，当第二预设轮次的健康监测结果为异常并返回第二错误码时，需要将系统回滚至备份版本。

在本实施例中，监测进程与系统的容器绑定，利用监测进程即可进行健康监测，且在系统运行过程中对系统进行持续的健康监测，当第一预设轮次的健康监测结果为异常时，最终返回第一错误码，从而基于第一错误码对系统进行重启，当第二预设轮次的健康监测结果为异常时，最终返回第二错误码，此时对应升级过后的系统，则获取备份的安装包将系统回滚至备份版本，从而确保系统能够稳定使用。

请参阅图3，图3是本申请系统监测和升级方法又一实施方式的流程示意图，其中，系统基于容器和容器管理工具构建，且系统在容器上运行，监测进程与系统的容器绑定。其中，具体内容可参见上一实施例，在此不再赘述。

进一步地，升级包和安装包基于容器的镜像生成，且升级包和安装包对应有与镜像匹配的镜像名称，升级包在系统的存储平台上对应有可供下载的链接地址。

具体地，容器的镜像包含了一个打包的应用，以及应用的依赖关系，还有应用在启动时运行的进程信息，镜像可以通过分层来进行集成，我们可以基于一个基础的镜像，然后制作出各种各样不同类型的应用镜像，从而提高升级包和安装包创建的自由度。此外，升级包和安装包对应有与镜像匹配的镜像名称，升级包在系统的存储平台上对应有可供下载的链接地址，从而实现升级包在多个系统之间的共享，同时通过应用程序接口也可以获得该链接地址。

具体地，该系统监测和升级方法包括以下步骤：

S301：获得启动指令，执行启动指令启动系统的监测进程，利用监测进程启动系统中的各个子服务，并对各个子服务进行健康监测，获得至少一轮健康监测结果。

S302：响应于第一预设轮次的健康监测结果为异常，重启系统。

具体地，上述步骤S301-S302可参阅上述第一个实施例中的步骤S101-S102，或者第二个实施例中的步骤S201-S209，在此不再赘述。

S303：响应于系统的上层应用调用应用程序接口，利用应用程序接口从链接地址下载得到升级包。

具体地，当系统的上层应用调用应用程序接口，利用应用程序接口来获取链接地址，从而从链接地址下载得到升级包。

S304：将系统当前的安装包对应的第一名称修改为第二名称，备份当前的安装包对应的第二名称，得到系统当前的安装包对应的备份版本。

具体地，系统当前的安装包对应的镜像名称为第一名称，将系统正在运行的安装包对应的镜像名称做修改，修改为第二名称，将第二名称记录下来，得到系统当前的安装包对应的备份版本。

在一应用方式中，镜像名称包括镜像命名和镜像标签，例如A：B，其中，A表示镜像命名，B表示镜像标签，在修改当前安装包对应的镜像名称时，对镜像命名或者镜像标签或者镜像命名和镜像标签进行修改均可，使得第二名称区别于第一名称即可，进而备份修改后的镜像名称作为第二名称。

在一应用场景中，当经过多次升级后，则对应有多个版本的安装包，不同版本的安装包在备份时可以选择修改为各不相同的名称，也就是安装包对应的第二名称并非完全相同，只是在执行的步骤中为区别于第一名称将其称为第二名称，进而不同版本的安装包均可以进行回溯，以便基于不同的需求和应用场景回滚至指定版本的安装包。

在另一应用场景中，当经过多次升级后，则对应有多个版本的安装包，不同版本的安装包在备份时可以选择修改为相同的第二名称，每当有新的安装包备份时则覆盖上一次备份的安装包，进而在回溯时只向上回溯一个版本，将系统回滚至上一个运行的安装包对应的版本，以便降低系统回滚出错的概率。

S305：将升级包对应的镜像名称修改为第一名称，其中，第一名称与系统的初始安装包对应的镜像名称相同。

具体地，将升级包对应的镜像名称修改为第一名称，此处的第一名称与系统的初始安装包的镜像名称相同，也就是修改后的升级包的镜像名称与系统第一次加载的安装包对应的镜像名称相同，以便于匹配后续配置文件定义的规则。

S306：利用系统的定时任务，在经过预设时间间隔后调用容器管理工具，利用容器管理工具指定配置文件，其中，配置文件定义有基于第一名称获取镜像的规则。

具体地，正常的重启系统对应着容器的重启，容器重启时通过读取安装包的镜像对应的镜像ID来启动系统，在未读取升级包之前，容器内的镜像ID仍为原先安装包的镜像所对应的镜像ID，当系统需要升级时，若仍采用常规的重启方法，所读取的仍是原先的镜像ID对应的安装包，从而导致升级失败。故此，利用系统的定时任务，在经过预设时间间隔后调用容器管理工具，利用容器管理工具指定配置文件，其中，配置文件中定义的规则为基于第一名称获取升级包对应的镜像，从而与重启过程区分，以便于对系统进行升级。

在一应用场景中，定时任务基于Linux系统提供的crontab实现，crontab用于设置周期性被执行的指令，从而实现经过预设时间间隔后调用容器管理工具Docker Compose，其中，预设时间间隔可以是一分钟，在其他应用场景中也可以自定义设置为其他时长，本申请对此不做具体限制。

S307：基于配置文件定义的规则，依据第一名称加载升级包对应的镜像，对系统进行升级，完成升级后重启系统并返回获得启动指令的步骤。

具体地，基于配置文件定义的规则，通过升级包的镜像名称来加载升级包对应的镜像，也就是基于第一名称获取到升级包对应的镜像，以便确保获取到升级包而非之前的安装包，从而完成对系统的升级，完成升级后重启系统并返回步骤S301，持续对系统进行健康监测。

S308：响应于第二预设轮次的健康监测结果为异常，将系统回滚至备份版本。

具体地，第二预设轮次在系统升级之后，通常对应系统升级之后的首次启动的第一轮次，当第二预设轮次的健康监测结果为异常时，对系统进行回滚，回滚至备份版本。

在一应用场景中，将系统回滚至备份版本，包括：基于安装包对应的第二名称，确定安装包对应的备份版本；清除升级包对应的升级记录，并将安装包的第二名称修改为第一名称；其中，升级记录包括升级包的镜像名称；利用系统的定时任务，在经过预设时间间隔后调用容器管理工具，利用容器管理工具指定配置文件；基于配置文件定义的规则，依据第一名称加载安装包对应的镜像，对系统进行回滚。

具体地，基于已经备份过的第二名称来确定安装包对应的备份版本，将上一次升级过程中升级包对应的升级记录清除，为系统回滚做好准备，其中，升级记录包括升级包对应的镜像名称，从而空出第一名称。

可以理解的是，基于相同的修改规则，将安装包对应的镜像名称修改为第一名称，从而与配置文件对应的规则相匹配，进而，利用系统的定时任务，在经过预设时间间隔后调用容器管理工具，利用容器管理工具指定配置文件，基于配置文件定义的规则，通过第一名称来加载安装包对应的镜像，以便确保获取到备份的安装包而非升级后导致系统异常的升级包，从而完成对系统的回滚，确保系统能够稳定使用。

在本实例中，升级包和安装包基于容器的镜像生成，在升级或回滚的过程中，利用系统的定时任务，在经过预设时间间隔后调用容器管理工具，利用容器管理工具指定配置文件，配置文件定义有基于第一名称获取镜像的规则，在升级时，将系统当前的安装包对应的第一名称修改为第二名称并备份第二名称，基于配置文件定义的规则，依据第一名称加载升级包对应的镜像，对系统进行升级，在回滚时，将安装包的镜像名称从第二名称修改为第一名称，基于配置文件定义的规则，依据第一名称加载安装包对应的镜像，对系统进行回滚，从而确保升级和回滚的准确性，提高系统运行的稳定性。

请参阅图4，图4是本申请电子设备一实施方式的结构示意图，该电子设备40包括相互耦接的存储器401和处理器402，其中，存储器401存储有程序数据(图未示)，处理器402调用程序数据以实现上述任一实施例中的方法，相关内容的说明请参见上述方法实施例的详细描述，在此不再赘叙。

在一应用场景中，请参阅图5，图5是本申请系统监测和升级方法一实施方式的应用场景示意图，其中，整个系统需要在linux环境上基于Docker和Docker Compose部署。

具体地，系统的启动方式为Docker Compose指定特定的yml配置文件执行启动指令。当系统启动时，即系统所在的Docker启动时，监测进程作为Docker的入口脚本执行，若该进程退出则将导致系统退出。其中，监测进程的作用主要是按顺序启动各子服务、系统回滚，以及轮询监测各子服务的健康状况。其中，轮询监测即轮询调用各子服务提供的包含健康状况的Http请求，若其中某个子服务的Http请求返回异常，并且在间隔5秒连续重试3次都是一样的情况下，则判定该子服务异常，监测进程退出，引起系统Docker退出，退出为特定错误码，包括上述实施例中的第一错误码和第二错误码，进而Docker Compose根据错误码重新启动系统Docker，对系统进行重启或者将系统回滚至备份版本。

进一步地，系统提供了一个可供上层应用调用的应用程序接口(ApplicationProgramming Interface，API)，该API支持上传系统升级包，其中，升级包由docker镜像制作而成，内部包含新的系统程序以及相应的配置文件等。当系统接收到该API请求后，首先修改当前使用的镜像标签并记录，用于在升级出现异常后能进行回滚。进而，在系统Docker内连接宿主机上的Docker服务，加载升级包中的镜像，此处，升级包的镜像名称与原始安装程序的镜像名称保持一致。接着通过修改宿主机的crontab增加定时任务，在一分钟后定时调用一次Docker Compose，用于基于镜像名称获取升级包的镜像，从而使用新的镜像启动系统。当系统重新启动后，监测进程会依次启动各子服务，若在启动后的第一轮健康监测过程中即发现有子服务出现异常，并且存在升级记录，则表明该系统是在升级过程中出现异常，需要回滚。此时，监测进程会向系统发送一个回滚信号，当系统接收到该回滚信号后，首先解析记录的上一次升级前能正常运行的镜像标签，并将宿主机上将该镜像名称修改为特定规范的镜像名称，同时清理升级记录，然后，同样在宿主机的crontab上增加定时任务，在一分钟后定时调用一次Docker Compose，用于使用上一次的镜像启动系统，实现系统的回滚。

请参阅图6，图6是本申请计算机可读存储介质一实施方式的结构示意图，该计算机可读存储介质60存储有程序数据600，该程序数据600被处理器执行时实现上述任一实施例中的方法，相关内容的说明请参见上述方法实施例的详细描述，在此不再赘叙。

需要说明的是，作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部单元来实现本实施方式方案的目的。

另外，在本申请各个实施例中的各功能单元可以集成在一个处理单元中，也可以是各个单元单独物理存在，也可以两个或两个以上单元集成在一个单元中。上述集成的单元既可以采用硬件的形式实现，也可以采用软件功能单元的形式实现。

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

以上所述仅为本申请的实施方式，并非因此限制本申请的专利范围，凡是利用本申请说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本申请的专利保护范围内。

Claims (10)

1.一种系统监测和升级方法，其特征在于，所述方法包括：

获得启动指令，执行所述启动指令启动系统的监测进程，利用所述监测进程启动所述系统中的各个子服务，并对各个所述子服务进行健康监测，获得至少一轮健康监测结果；

响应于第一预设轮次的健康监测结果为异常，重启所述系统；

响应于所述系统的上层应用调用应用程序接口，利用所述应用程序接口获得所述系统的升级包，备份所述系统当前的安装包，得到备份版本，利用所述系统的定时任务加载所述升级包对所述系统进行升级，完成升级后重启所述系统并返回所述获得启动指令的步骤；

响应于第二预设轮次的健康监测结果为异常，将所述系统回滚至所述备份版本；其中，所述第二预设轮次在所述系统升级之后。

2.根据权利要求1所述的系统监测和升级方法，其特征在于，所述系统基于容器和容器管理工具构建，且所述系统在容器上运行，所述监测进程与所述系统的容器绑定。

3.根据权利要求2所述的系统监测和升级方法，其特征在于，所述获得启动指令，执行所述启动指令启动系统的监测进程，利用所述监测进程启动所述系统中的各个子服务，并对各个所述子服务进行健康监测，获得至少一轮健康监测结果，包括：

获得启动指令，利用所述容器管理工具执行所述启动指令，启动所述系统对应的容器及其绑定的监测进程；

利用所述监测进程调用各个所述子服务的启动命令，启动所述系统中的各个所述子服务；

接收各个所述子服务的通信请求，基于当前轮次的通信请求，确定所述当前轮次的健康监测结果，得到至少一轮健康监测结果；

响应于所述当前轮次的健康监测结果为正常，进入下一轮次的健康监测，返回至接收各个所述子服务的通信请求，基于当前轮次的通信请求，确定所述当前轮次的健康监测结果的步骤。

4.根据权利要求3所述的系统监测和升级方法，其特征在于，当所述监测进程启动任一所述子服务失败时，所述系统启动后的第一轮次的健康监测结果为异常；当所述监测进程接收到的当前轮次的通信请求存在异常时，当前轮次的健康监测结果为异常；

所述接收各个所述子服务的通信请求，基于当前轮次的通信请求，确定所述当前轮次的健康监测结果，得到至少一轮健康监测结果之后，还包括：

响应于所述当前轮次为所述第一预设轮次且健康监测结果为异常，退出所述监测进程以使所述监测进程绑定的容器退出，返回第一错误码；其中，所述第一预设轮次为区别于所述第一轮次的其他轮次，所述第一错误码与所述第一预设轮次的通信请求存在异常相关；或者，

响应于所述当前轮次为所述第二预设轮次且健康监测结果为异常，退出所述监测进程以使所述监测进程绑定的容器退出，返回第二错误码；其中，所述第二预设轮次为所述第一轮次且在所述系统升级之后，所述第二错误码与所述第二预设轮次的通信请求存在异常相关。

5.根据权利要求4所述的系统监测和升级方法，其特征在于，所述响应于第一预设轮次的健康监测结果为异常，重启所述系统，包括：

响应于获得所述第一错误码，利用所述容器管理工具重启所述系统对应的容器及其绑定的监测进程；

所述响应于第二预设轮次的健康监测结果为异常，将所述系统回滚至所述备份版本，包括：

响应于获得所述第二错误码，利用所述系统的定时任务加载所述备份版本的安装包，将所述系统回滚至所述备份版本。

6.根据权利要求2所述的系统监测和升级方法，其特征在于，所述升级包和所述安装包基于容器的镜像生成，且所述升级包和所述安装包对应有与镜像匹配的镜像名称，所述升级包在所述系统的存储平台上对应有可供下载的链接地址。

7.根据权利要求6所述的系统监测和升级方法，其特征在于，所述系统当前的安装包对应的镜像名称为第一名称，所述响应于所述系统的上层应用调用应用程序接口，利用所述应用程序接口获得所述系统的升级包，备份所述系统当前的安装包，得到备份版本，利用所述系统的定时任务加载所述升级包对所述系统进行升级，包括：

响应于所述系统的上层应用调用应用程序接口，利用所述应用程序接口从所述链接地址下载得到所述升级包；

将所述系统当前的安装包对应的第一名称修改为第二名称，备份所述当前的安装包对应的所述第二名称，得到所述系统当前的安装包对应的备份版本；

将所述升级包对应的镜像名称修改为所述第一名称；其中，所述第一名称与所述系统的初始安装包对应的镜像名称相同；

利用所述系统的定时任务，在经过预设时间间隔后调用所述容器管理工具，利用所述容器管理工具指定配置文件；其中，所述配置文件定义有基于所述第一名称获取镜像的规则；

基于所述配置文件定义的规则，依据所述第一名称加载所述升级包对应的镜像，对所述系统进行升级。

8.根据权利要求7所述的系统监测和升级方法，其特征在于，所述将所述系统回滚至所述备份版本，包括：

基于所述安装包对应的所述第二名称，确定所述安装包对应的备份版本；

清除所述升级包对应的升级记录，并将所述安装包的第二名称修改为所述第一名称；其中，所述升级记录包括所述升级包的镜像名称；

利用所述系统的定时任务，在经过预设时间间隔后调用所述容器管理工具，利用所述容器管理工具指定所述配置文件；

基于所述配置文件定义的规则，依据所述第一名称加载所述安装包对应的镜像，对所述系统进行回滚。

9.一种电子设备，其特征在于，包括：相互耦接的存储器和处理器，其中，所述存储器存储有程序数据，所述处理器调用所述程序数据以执行如权利要求1-8中任一项所述的方法。

10.一种计算机可读存储介质，其上存储有程序数据，其特征在于，所述程序数据被处理器执行时实现如权利要求1-8中任一项所述的方法。

Images