CN114884840A - 应用健康状态检查方法及电子设备 - Google Patents

Abstract

本发明涉及服务器技术领域，具体涉及应用健康状态检查方法及电子设备，该方法应用于健康状态检查模块，所述健康状态检查模块独立于目标应用对应的部署对象设置，所述部署对象用于运行目标应用，所述方法包括获取目标应用对应的当前检查方式，所述当前检查方式是基于目标应用的上一次健康检查的结果确定的；当当前检查方式为非主动检查时，获取目标应用的接口访问状态；基于接口访问状态与对应的目标状态的关系，确定目标应用的当前健康检查结果以及下一次检查方式，所述当前健康检查结果包括在线或离线。根据实际业务需求确定的检查方式，在无需进行主动检查时，仅通过目标应用的接口访问状态确定，避免了在业务繁忙时进行主动检查。

Description

应用健康状态检查方法及电子设备

技术领域

本发明涉及服务器技术领域，具体涉及应用健康状态检查方法及电子设备。

背景技术

对于应用的部署而言，其可以部署容器应用，又可以部署虚拟机应用。对于容器应用而言，K8s提供了两种探针来检查容器的状态，存活探针livenessProbe和就绪探针readinessProbe。livenessProbe是为了查看容器是否正在运行，readinessProbe是为了查看容器是否准备好接受HTTP请求。在K8s中，Pod是K8s创建及管理的最小的可部署的计算单元，一个Pod由一个或者多个容器组成，在K8s上下文中存活探针和就绪探针被称作健康检查，这些容器探针是一些周期性运行的小进程。

如图1所示，K8s提供service资源对外提供访问入口，就绪探针用于让K8s知道应用是否准备好为请求提供服务。K8s只有在就绪探针通过后，才会把容器访问方式加入到endpoints资源中，service访问才会把流量转发到该Pod。如果就绪探针检测失败，K8s将从endpoints资源中移除该容器访问，停止向该容器发送流量，直到它通过。

K8s原生的应用健康检查是K8s节点主动发起请求探测应用就绪性，然而，这种方式会产生格外的网络流量，增加节点压力。

发明内容

有鉴于此，本发明实施例提供了一种应用健康状态检查方法及电子设备，以解决由于应用就绪性检查导致的节点压力增加的问题。

根据第一方面，本发明实施例提供了一种应用健康状态检查方法，应用于健康状态检查模块，所述健康状态检查模块独立于目标应用对应的部署对象设置，所述部署对象用于运行所述目标应用，所述方法包括：

获取目标应用对应的当前检查方式，所述当前检查方式是基于所述目标应用的上一次健康检查的结果确定的；

当所述当前检查方式为非主动检查时，从所述目标应用的就绪性探针接口获取所述目标应用的接口访问状态；

基于所述接口访问状态与对应的目标状态的关系，确定所述目标应用的当前健康检查结果以及下一次检查方式，所述当前健康检查结果包括在线或离线。

本发明实施例提供的应用健康状态检查方法，在每次对目标应用进行健康检查之后，依据健康检查的结果确定下一次检查方式，从而使得每次健康检查的检查方式均是基于上一次的检查结果确定的，即，是根据实际业务需求确定的而并不是固定不变的，在无需进行主动检查时，仅通过目标应用的接口访问状态确定当前健康检查结果，避免了在业务繁忙时进行主动检查，减轻了节点压力及网络流量。

结合第一方面，在第一方面第一实施方式中，所述接口访问状态包括接口访问成功次数、访问失败次数以及超时次数中的至少一种，所述基于所述接口访问状态与对应的目标状态的关系，确定所述目标应用的当前健康检查结果以及下一次检查方式，包括：

当所述接口访问成功次数、所述访问失败次数以及所述超时次数中的至少一种发生变化时，获取所述目标应用的接口访问成功率；

当所述接口访问成功率大于或等于目标访问成功率时，确定所述目标应用的当前健康检查结果为在线且所述下一次检查方式为非主动检查。

本发明实施例提供的应用健康状态检查方法，由于次数发生变化不一定表示访问成功，因此，通过发生变化的次数以及访问成功率的结合，保证了所确定出的当前健康检查结果为在线的准确性。

结合第一方面第一实施方式，在第一方面第二实施方式中，所述获取所述目标应用的接口访问成功率，包括：

获取发生变化的接口访问状态的连续变化次数；

当所述连续变化次数达到目标变化阈值时，获取所述目标应用的接口访问成功率。

本发明实施例提供的应用健康状态检查方法，将连续变化次数作为筛选阈值，在未达到目标变化阈值时表示当前检查未结束需要再次进行检查，避免了无效的判断，减少了节点的数据处理量。

结合第一方面第一实施方式，在第一方面第三实施方式中，所述基于所述接口访问状态与对应的目标状态的关系，确定所述目标应用的当前健康检查结果以及下一次检查方式，包括：

当所述接口访问成功次数、所述访问失败次数以及所述超时次数均未发生变化且连续未变化次数达到目标未变化阈值时，确定所述目标应用的当前健康检查结果为离线且所述下一次检查方式为主动检查。

本发明实施例提供的应用健康状态检查方法，因为之前只统计了访问次数，没计算成功率，之所以要统计几次变化，主要是针对未变化的情况，防止应用假死，针对几次未变化，修改健康检查为主动检查，访问次数未变化，统计成功率来准确判断目标应用是否在线。

结合第一方面，在第一方面第四实施方式中，所述方法还包括：

当所述当前检查方式为主动检查时，对所述目标应用发起访问，确定所述主动检查的结果；

基于所述主动检查的结果与对应的目标结果的关系，确定所述目标应用的当前健康检查结果以及下一次检查方式。

本发明实施例提供的应用健康状态检查方法，通过向目标应用发起访问以进行主动检查，以实现后续对地址访问资源的及时更新。

结合第一方面第四实施方式，在第一方面第五实施方式中，所述主动检查的结果包括连续成功的次数或连续失败的次数，所述基于所述主动检查的结果与对应的目标结果的关系，确定所述目标应用的当前健康检查结果以及下一次检查方式，包括：

当所述连续成功的次数大于或等于第一阈值时，确定所述目标应用的当前健康检查结果为在线且所述下一次检查方式为非主动检查；

当所述连续失败的次数大于或等于第二阈值时，确定所述目标应用的当前健康检查结果为离线且所述下一次检查方式为主动检查。

结合第一方面，在第一方面第六实施方式中，所述方法还包括：

当所述当前健康检查结果为在线时，在地址访问资源中添加所述目标应用对应的部署对象的地址，所述地址访问资源用于记录在线的应用对应的部署对象的地址；

当所述当前健康检查结果为离线时，在所述地址访问资源中删除所述目标应用对应的部署对象的地址。

本发明实施例提供的应用健康状态检查方法，利用当前健康检查结果对地址访问资源进行实时更新，能够保证其对外提供服务的可靠性。

结合第一方面，在第一方面第七实施方式中，所述目标应用包括容器应用或虚拟机应用，所述方法还包括：

每隔预设时间，从所述目标应用的就绪性探针接口中获取所述目标应用的离线次数；

当获取所述离线次数的时间超过预设时间或所述离线次数超过目标存活检查次数时，重启所述容器应用对应的部署对象或重启所述虚拟机应用。

本发明实施例提供的应用健康状态检查方法，对于容器应用直接通过应用提供的探针接口，确定应用是否存活，没有额外多余的网络流量，因此节点网络压力减少；对于虚拟机应用，重启对应虚拟机中的应用，从而达到恢复业务目的，减少原生容器应用。通过统一的健康检查方式，解决原生K8s不支持虚拟机应用的健康检查场景。

根据第二方面，本发明实施例提供了一种电子设备，包括：存储器和处理器，所述存储器和所述处理器之间互相通信连接，所述存储器中存储有计算机指令，所述处理器通过执行所述计算机指令，从而执行第一方面或者第一方面的任意一种实施方式中所述的应用健康状态检查方法。

根据第三方面，本发明实施例提供了一种计算机可读存储介质，所述计算机可读存储介质存储计算机指令，所述计算机指令用于使所述计算机执行第一方面或者第一方面的任意一种实施方式中所述的应用健康状态检查方法。

需要说明的是，本发明实施例中提供的电子设备以及计算机可读存储介质的相应有益效果，请参见上文应用健康状态检查方法的对应描述，在此不再赘述。

附图说明

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

图1示出了K8s集群中资源访问的示意图；

图2是根据本发明实施例的应用健康状态检查方法的流程图；

图3是根据本发明实施例的应用健康状态检查方法的流程图；

图4是根据本发明实施例的应用健康状态检查方法的流程图；

图5是根据本发明实施例的应用健康状态检查方法的流程图；

图6是根据本发明实施例的应用健康状态检查装置的结构框图；

图7是本发明实施例提供的电子设备的硬件结构示意图。

具体实施方式

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

需要说明的是，本发明实施例提供的应用健康状态检查由健康状态检查模块执行，用于对目标应用的健康状态进行检查，以便后续基于健康检查结果对地址访问资源进行更新。需要说明的是，该健康状态检查模块独立于目标应用对应的部署对象设置，该部署对象用于运行目标应用。其中，地址访问资源用于存储在线的应用对应的部署对象的地址。例如，对于K8s集群而言，地址访问资源为endpoints资源。应用对应的部署对象可以是容器，也可以是虚拟机等等，在此对其并不做任何限定，具体根据实际需求进行设置。当应用对应的部署对象为容器时，即目标应用部署在容器中，此时部署对象的地址为容器所在的Pod的地址，该Pod的IP直接从K8s获取，这是由于Pod IP和容器网络插件有关系，Pod重启后可能会变。端口则从配置的k8s资源service中获取，因service配置后，才有endpoints资源，K8s通过service对外提供访问，最终调度到service关联的endpoints指定的虚拟机或容器上，用户如果不配置service资源，则健康检查模块不启动检查。当应用对应的部署对象为虚拟机时，即目标应用部署在虚拟机中，此时部署对象的地址为该虚拟机的地址，在部署应用时配置已经下发至虚拟机中，虚拟机应用会保存虚拟机的IP。

作为本发明实施例的一个可选应用场景，当目标应用为容器应用时，健康检查模块部署在容器中。即，当部署容器应用时，健康检查模块和业务容器部署在一个Pod中。其中，业务容器用于部署目标应用。当部署虚拟机应用时，只部署一个健康检查容器在Pod中，虚拟机应用单独部署在虚拟机中。

在对目标应用进行健康检查时，包括就绪性和存活性检查。其中，就绪性检查用于确定目标应用是否准备好为请求提供服务，存活性检查用于确定应用是否活着。在就绪性检查中，通过检查目标应用是否在线，从而对地址访问资源进行更新；在存活性检查中，通过检查目标应用是否存活，以对目标应用或目标应用对应的部署对象进行重启，以达到恢复业务的目的。

在本发明实施例中依次从就绪性检查以及存活性检查两个方面进行描述。

根据本发明实施例，提供了一种应用健康状态检查方法实施例，需要说明的是，在附图的流程图示出的步骤可以在诸如一组计算机可执行指令的计算机系统中执行，并且，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

在本实施例中提供了一种应用健康状态检查方法，可用于上述电子设备，如服务器等，图2是根据本发明实施例的应用健康状态检查方法的流程图，如图2所示，该流程包括如下步骤：

S11，获取目标应用对应的当前检查方式。

其中，所述当前检查方式是基于所述目标应用的上一次健康检查的结果确定的。

如上文所述，在对目标应用进行就绪性检查时，是通过检查目标应用是否在线以对地址访问资源进行更新。其中，对目标应用的就绪性检查，可以是定时触发的，也可以是定期触发的，等等，在此对其并不做任何限定，具体触发方式可以在部署应用时确定。

不论是定时触发还是定期触发，对于目标应用的就绪性检查是一个循环的处理过程。在每次检查之后可以存储当前检查结果，并基于当前检查结果确定下一次健康检查的检查方式。例如，上一次健康检查的结果为不在线，那么，当前检查方式为主动检查；若上一次健康检查的结果为在线，那么，当前检查方式为非主动检查。进一步地，当前健康检查的结果决定了下一次健康检查的检查方式。基于此，本实施例提供的就绪性检查中，是基于业务需求确定检查方式的，而并不是每次均是主动检查。

S12，当当前检查方式为非主动检查时，从目标应用的就绪性探针接口获取目标应用的接口访问状态。

电子设备在确定出当前检查方式为非主动检查时，电子设备通过访问目标应用的就绪性探针接口获取其接口访问状态。其中，该就绪性探针接口可以是JavaAgent探针。具体地，jdk1.5以后引入了JavaAgent技术，JavaAgent是运行方法之前的拦截器。利用JavaAgent和ASM(jvm字节码操纵框架)字节码技术，在运行应用健康状态检查方法时，指定JavaAgent参数，启动JavaAgent功能：java-javaAgent实现的javaAgent-jar业务jar包，在jvm加载class二进制文件的时候，jvm利用ASM动态的修改加载的class文件，监控加载类中方法返回值、方法前后添加计时器功能，用于计算监控方法访问超时，并实现健康检查，对加载类的业务进行健康检查。

目标应用的接口访问状态包括但不限于接口访问成功次数、接口访问失败次数、超时次数等等。电子设备从目标应用的就绪性探头接口获取到上述接口访问状态，所获取到的接口访问状态的类型是根据实际需求确定的，在此对其并不做任何限定。

其中，非主动检查表示经过上一次健康检查之后目标应用的业务状态较好，通过直接调用接口探针的方式进行当前的健康检查，能够降低节点数据处理量，提高处理效率。

需要说明的是，若目标应用是初次启动，则电子设备对其进行主动检查。后续健康检查的检查方式则是依据上一次健康检查的结果确定的。

S13，基于接口访问状态与对应的目标状态的关系，确定目标应用的当前健康检查结果以及下一次检查方式。

其中，所述当前健康检查结果包括在线或离线。

目标状态是与各个接口访问状态对应的，用于表示应用在线的接口访问状态的目标值。电子设备将S12中获取到的各个接口访问状态与对应的目标状态进行比较，即可确定其是否满足相应目标状态，从而确定出模板应用的当前健康检查结果。电子设备再利用当前健康检查结果确定下一次检查方式，例如，当前健康检查结果为在线，那么，下一次检查方式为非主动检查；若当前健康检查结果为离线，那么，下一次检查方式为主动检查。

关于该步骤具体将在下文中进行详细描述。

本实施例提供的应用健康状态检查方法，在每次对目标应用进行健康检查之后，依据健康检查的结果确定下一次检查方式，从而使得每次健康检查的检查方式均是基于上一次的检查结果确定的，即，是根据实际业务需求确定的而并不是固定不变的，在无需进行主动检查时，仅通过目标应用的接口访问状态确定当前健康检查结果，避免了在业务繁忙时进行主动检查，减轻了节点压力及网络流程，提高了地址访问资源更新的实时性。

在一些可选实施方式中，该方法还包括：根据当前健康检查结果更新地址访问资源。其中，所述地址访问资源用于记录在线的应用对应的部署对象的地址。

电子设备在确定出目标应用的当前健康检查结果之后，对地址访问资源进行更新。如上文所述，地址访问资源是用于提供给外界与各个目标应用进行连接的对象，例如，K8s集群中的endpoints资源。该地址访问资源记录在线的应用对应的部署对象的地址。基于此，若目标应用的当前健康检查结果为在线，则在地址访问资源中添加该目标应用对应的部署对象的地址。若在历史地址访问资源中记录有该目标应用对应的部署对象的地址，则先进行地址匹配，确定地址是否发生变更，若地址发生变更，则用最新的地址替换历史地址；若未发生变更，则地址访问资源中的对应地址保持不变。

若目标应用的当前健康检查结果为离线，则在地址访问资源中将该目标应用对应的部署对象的地址删除。若历史地址访问资源中未记录有该当前应用对应的部署对象的地址，则对历史地址访问资源无需修改；若历史地址访问资源中记录有该当前应用对应的部署对象的地址，则在历史地址访问资源中将该当前应用对应的部署对象的地址删除。

此处所述的当前健康检查结果为对目标应用进行就绪性检查的结果，在线表示该目标应用已经准备好接收访问请求；离线表示该目标应用未准备好接收访问请求。

具体地，

(1)当当前健康检查结果为在线时，在地址访问资源中添加目标应用对应的部署对象的地址。

(2)当当前健康检查结果为离线时，在地址访问资源中删除目标应用对应的部署对象的地址。

在本实施例中提供了一种应用健康状态检查方法，可用于上述电子设备，如服务器等，图3是根据本发明实施例的应用健康状态检查方法的流程图，如图3所示，该流程包括如下步骤：

S21，获取目标应用对应的当前检查方式。

其中，所述当前检查方式是基于所述目标应用的上一次健康检查的结果确定的。

详细请参见图2所示实施例的S11，在此不再赘述。

S22，当当前检查方式为非主动检查时，从目标应用的就绪性探针接口获取目标应用的接口访问状态。

其中，所述接口访问状态包括接口访问成功次数、访问失败次数以及超时次数中的至少一种。

在健康检查模块中设置有多个计数器，分别用于统计接口访问成功次数、访问失败次数以及超时次数等等。其中，对于当前健康检查而言，目标应用的接口访问状态是通过访问接口探针获得的。

S23，基于接口访问状态与对应的目标状态的关系，确定目标应用的当前健康检查结果以及下一次检查方式。

其中，所述当前健康检查结果包括在线或离线。

具体地，上述S23包括：

S231，当接口访问成功次数、访问失败次数以及超时次数中的至少一种发生变化时，获取目标应用的接口访问成功率。

电子设备对获取到的接口访问成功次数、访问失败次数以及超时次数进行分析，确定其是否发生变化，若只要有其中一个发生变化，则就触发电子设备获取目标应用的接口访问成功率。

在一些可选实施方式中，上述的获取目标应用的接口访问成功率包括：

(1)获取发生变化的接口访问状态的连续变化次数。

(2)当连续变化次数达到目标变化阈值时，获取目标应用的接口访问成功率。

电子设备在确定出接口访问成功次数、访问失败次数以及超时次数中的至少一种发生变化时，先获取发生变化的接口访问状态的连续变化次数。例如，若接口访问成功次数发生变化，则获取接口访问成功次数发生连续变化的次数；若访问失败次数发生变化，则获取访问失败次数发生连续变化的次数。

电子设备将连续变化次数与目标变化阈值进行比较，在连续变化次数达到目标变化阈值时，再获取目标应用的接口访问成功率。其中，对于接口访问成功率，可以计算接口访问成功次数与统计时间的比值，从而确定出目标应用的接口访问成功率。

其中，再连续变化次数未达到目标变化阈值时，需要继续进行统计。

将连续变化次数作为筛选阈值，在未达到目标变化阈值时表示当前检查未结束需要再次进行检查，避免了无效的判断，减少了节点的数据处理量。

S232，当接口访问成功率大于或等于目标访问成功率时，确定目标应用的当前健康检查结果为在线且下一次检查方式为非主动检查。

电子设备在确定出接口访问成功率大于或等于目标访问成功率时，则确定该目标应用在线且下一次检查方式为非主动检查；否则，确定目标应用离线且下一次检查方式为主动检查。

在另一些可选实施方式中，上述S23还可以包括：

当接口访问成功次数、访问失败次数以及超时次数均未发生变化且连续未变化次数达到目标未变化阈值时，确定目标应用的当前健康检查结果为离线且下一次检查方式为主动检查。

因为之前只统计了访问次数，没计算成功率，之所以要统计几次变化，主要是针对未变化的情况，防止应用假死，针对几次未变化，修改健康检查为主动检查，访问次数未变化，统计成功率来准确判断目标应用是否在线。

本实施例提供的应用健康状态检查方法，由于次数发生变化不一定表示访问成功，因此，通过发生变化的次数以及访问成功率的结合，保证了所确定出的当前健康检查结果为在线的准确性。

在本实施例的一个具体应用示例中，所述的应用健康状态检查方法是利用javaAgent探针技术，实现javaAgent达到如下功能：

(1)部署容器或虚拟机应用时，电子设备的界面提供健康检查可开启、关闭。在开启的时候，提供就绪行检查配置参数：探测频率可配置。对于主动检查(javaAgent通过内部实行的健康检查，主动发起业务检查，确定业务在线)。其中，可配置参数：支持命令、http、tcp、数据库常用健康检查方式、初次启动时间、超时时间、成功次数阈值、失败次数阈值配置。对于非主动检查((javaAgent通过统计的接口访问成功次数，计算访问成功率是否达到在线阈值，确定业务在线)可配置参数：业务接口访问变化次数阈值、业务接口访问未变化次数阈值、访问成功率在线阈值。

(2)应用若开启健康检查，应用运行增加javaAgent参数：java-javaAgent实现的javaAgent-jar业务jar包；

(3)应用初次启动，检查方式默认为主动检查；

(4)按配置的探针频率周期性判断检查方式，若主动检查开启，根据配置的主动检查参数，如配置http请求方式检查，应用初次启动时间过后，对应用发起http请求，当请求连续成功次数达到成功次数阈值，则业务检查通过，业务在线，容器所属POD的IP或虚拟机IP、业务端口，加入到endpoints资源中，关闭主动检查方式；当请求连续成功次数未达到成功次数阈值，则继续检查；当请求连续失败次数达到失败次数阈值，则业务检查不通过，业务离线，从endpoints中删除该资源；当请求连续失败次数未达到失败次数阈值，则继续检查；

(5)按配置的探针频率周期性判断检查方式，若主动检查关闭，该javaAgent开始统计业务接口访问成功、失败、超时次数；若连续未变化次数达到阈值，则清除访问各计数，开启主动检查；若连续未变化次数未达到阈值，则继续检查；若连续变化次数达到阈值，则计算访问成功率是否达到在线阈值，达到，业务在线，则业务容器所属POD的IP或虚拟机IP、业务端口，加入到endpoints资源中，未达到在线阈值，业务离线，则从endpoints中删除该资源，清除各计数器，开启主动检查；若连续变化次数未达到阈值，则继续检查。

在本实施例中提供了一种应用健康状态检查方法，可用于上述电子设备，如服务器等，图4是根据本发明实施例的应用健康状态检查方法的流程图，如图4所示，该流程包括如下步骤：

S31，获取目标应用对应的当前检查方式。

其中，所述当前检查方式是基于所述目标应用的上一次健康检查的结果确定的。

详细请参见图2所示实施例的S11，在此不再赘述。

S32，当当前检查方式为主动检查时，对目标应用发起访问，确定主动检查的结果。

其中，所述主动检查的结果包括连续成功的次数或连续失败的次数。电子设备通过向目标应用发起访问，实现主动检查并确定主动检查的结果。具体地，根据配置的检查方法http、tcp或数据库访问，对目标应用发起访问，访问成功则主动检查成功，访问失败，则主动检查失败。若主动检查成功，则统计连续成功的次数；若主动检查失败，则统计连续失败的次数。

S33，基于主动检查的结果与对应的目标结果的关系，确定目标应用的当前健康检查结果以及下一次检查方式。

其中，目标结果为对应于连续成功次数的第一阈值，以及对应于连续失败次数的第二阈值。具体地，上述S33包括：

S331，当连续成功的次数大于或等于第一阈值时，确定目标应用的当前健康检查结果为在线且下一次检查方式为非主动检查。

S332，当连续失败的次数大于或等于第二阈值时，确定目标应用的当前健康检查结果为离线且下一次检查方式为主动检查。

本实施例提供的应用健康状态检查方法，通过向目标应用发起访问以进行主动检查，实现对地址访问资源的及时更新。

上述示例中描述的是对目标应用进行就绪性检查，在一些可选实施方式中，对目标应用进行存活性检查。具体地，所述目标应用包括容器应用或虚拟机应用，所述方法还包括：

(1)每隔预设时间，从目标应用的就绪性探针接口中获取目标应用的离线次数。

(2)当获取离线次数的时间超过预设时间或离线次数超过目标存活检查次数时，重启容器应用对应的部署对象或重启虚拟机应用。

其中，预设时间为对目标应用进行存活性检查的周期，该周期可以与对目标应用进行就绪性检查的周期相同，也可以不同，具体取决于系统配置。当预设时间到时，电子设备就从目标应用的就绪性探针接口中获取模板应用的离线次数。其中，对于离线次数的获取可能获取到，也可能获取不到。若获取到，则将离线次数与目标存储检查次数进行比较，确定其是否超过目标存活检查次数；若获取不到，则统计获取离线次数的时间。因此，当获取离线次数的时间超过预设时间，或离线次数超过目标存活检查次数时，则电子设备确定目标应用出现问题，重启容器应用对应的部署对象或者重启虚拟机应用。

在一个具体示例中，存活性检查是确认应用是否存活，能否继续对外提供业务。具体地，包括如下步骤：

(1)部署容器应用或虚拟机应用时，电子设备的界面提供存活性检查配置参数：探测频率、初次启动时间、超时时间、检查次数；

(2)根据存活性配置，按探测频率周期性检查，健康检查模块获取对应应用容器或虚拟机应用中的就绪性javaAgent探针接口，检查应用在线结果，若连续获取结果超时或离线次数，超过存活性检查次数，容器应用，则重启业务容器所在Pod，虚拟机应用，则重启对应虚拟机中的应用。其中，在目标应用第一次启动时需等初始启动时间过后再从就绪性探针接口确定相应的结果。

对于容器应用直接通过应用提供的探针接口，确定应用是否存活，没有额外多余的网络流量，因此节点网络压力减少；对于虚拟机应用，重启对应虚拟机中的应用，从而达到恢复业务目的，减少原生容器应用。通过统一的健康检查方式，解决原生K8s不支持虚拟机应用的健康检查场景。

在一个具体应用实例中，如图5所示，该应用健康状态检查方法包括：

S401，在程序启动后确定是否主动检查；当主动检查时，执行S402；否则，执行S406；

S402，应用接口访问成功、失败、超时次数是否发生变化；当发生变化时，执行S403；否则，执行S405；

S403，连续变化次数是否达到目标变化阈值；当达到时，执行S404；否则，执行周期性检查；

S404，访问成功率是否达到目标访问成功率；当达到时，确定应用在线，在endpoints中添加访问pod IP或虚拟机IP和端口；当未达到时，确定应用离线，清除访问各计数器，开启主动检查；

S405，连续未变化次数是否达到目标未变化阈值；当达到时，确定应用离线，清除访问各计数器，开启主动检查；否则，进行周期性检查；

S406，主动检查是否成功；当成功时执行S407；否则执行S408；

S407，连续成功次数是否达到第一阈值；当达到时，执行S410；否则进行周期性检查；

S408，连续成功次数是否达到第二阈值；当达到时，执行S409；否则进行周期性检查；

S409，确定应用离线，endpoints删除访问pod IP或虚拟机IP和端口，开启主动检查；

S410，确定应用在线，endpoints添加访问pod IP或虚拟机IP和端口，关闭主动检查。

作为一个具体应用实例，在容器或虚拟机中部署一应用，对该应用进行就绪性检查以及存活性检查。其中，就绪性检查用于更新地址访问资源，存活性检查的目的在确定出应用出现问题时，对其进行相应的处理。具体地，如下配置：

(1)就绪性检查配置

就绪性检查：开启

探测频率：T秒

主动检查配置：检查方式(http)、初次启动时间(t1秒)、超时时间(t2秒)、成功次数阈值(s1)、失败次数阈值配置(f1)

非主动检查配置：访问成功率在线阈值(n％)、业务接口访问变化次数阈值(n1)、业务接口访问未变化次数阈值(n2)

(2)存活性检查配置

存活性检查：开启

探针频率：T秒

初次启动时间：t1秒

超时时间：t2秒

检查次数：n

该应用就绪性检查配置和存活性检查配置下发到健康检查模块容器中，应用运行增加javaAgent探针。

1、就绪性检查

应用在线情况：

(1)T秒检查周期，健康检查模块检查主动检查是否开启，开启，按http方式访问应用(若应用是初次启动，需等待t1秒后访问)，t2秒超时时间内，访问成功，连续访问成功次数达到成功次数阈值s1，业务在线，容器所属POD的IP或虚拟机IP、业务端口，加入到endpoints资源中，关闭主动检查方式。

(2)T秒检查周期，健康检查模块检查主动检查是否开启，关闭，通知应用javaAgent开始统计业务接口访问成功、失败、超时次数，若访问次数和上次有变化连续达到n1次，计算访问成功率达到在线阈值n％,则业务在线，则业务容器所属POD的IP或虚拟机IP、业务端口，加入到endpoints资源中。

应用离线情况：

(1)T秒检查周期，健康检查模块检查主动检查是否开启。若开启，按http方式访问应用(若应用是初次启动，需等待t1秒后访问)，t2秒超时时间内，访问失败，连续访问失败次数达到失败次数阈值f1,业务离线，容器所属POD的IP或虚拟机IP、业务端口，从endpoints资源中删除，开启主动检查。

(2)T秒检查周期，健康检查模块检查主动检查是否开启。若关闭，通知应用javaAgent开始统计业务接口访问成功、失败、超时次数，若访问次数和上次有变化连续达到n1次，计算访问成功率未达到在线阈值n％,则业务离线，则业务容器所属POD的IP或虚拟机IP、业务端口，从endpoints资源删除，访问各计数清0，开启主动检查。

(3)T秒检查周期，健康检查模块检查主动检查是否开启。若关闭，通知应用javaAgent开始统计业务接口访问成功、失败、超时次数，若访问次数和上次未变化连续达到n2次，访问各计数清0，开启主动检查。

2、存活性检查：

T秒检查周期，健康检查模块从应用中的就绪性javaAgent探针接口，检查应用在线结果(若应用是初次启动，需等待t1秒后获取结果)，若连续获取结果超过t2秒或离线次数，超过存活性检查次数n，容器应用，则重启业务容器所在Pod，虚拟机应用，则重启对应虚拟机中的应用。

本实施例提供的应用健康状态检查方法，针对容器应用，减少K8s节点健康检查增加的网络流量，减轻节点压力；同时在Pod过多时能够对检测结果进行更新，即及时更新地址访问资源。通过对各种类型的部署对象采用统一的方式对应用进行健康检查，解决了如数据库业务健康检查场景，做到业务真实就绪性检查，支持service对接虚拟机应用，提供对虚拟机应用就绪性和存活性健康检查。

具体地，利用Pod可以部署管理多个容器，实现健康检查模块容器，针对容器应用，健康检查模块容器和业务容器运行在一起；针对虚拟机应用，单独部署一健康检查模块容器。

针对应用就绪性健康检查：利用javaAgent探针技术，实现业务应用自适应主动、被动健康检查切换。根据业务访问情况，自适应开启关闭主动检查方式：当业务繁忙时，关闭主动检查，减轻应用节点压力及网络流量，统计接口访问情况计算成功率，根据阈值确定业务是否在线；当业务空闲时，开启主动检查，主动发起检查，检查业务是否在线，确保应用故障时，快速恢复业务。

针对应用存活性健康检查：健康检查模块容器(应用第一次启动时需等初始启动时间过后)，获取对应业务容器或虚拟机应用中的就绪性javaAgent探针接口，检查应用在线结果。若连续获取结果超时或离线次数超过存活性检查次数，对于容器应用，则重启业务容器所在Pod；对于虚拟机应用，则重启对应虚拟机中的应用，从而达到恢复业务目的，减少原生容器应用。对于K8s原生pod存活性检查，会主动发起请求检查业务在线，会有额外的网络流量，这里直接通过应用提供的探针接口，确定应用是否存活，没有额外多余的网络流量，因此节点网络压力减少。

针对容器和虚拟机应用，统一的健康检查方式，解决原生K8s不支持虚拟机应用健康检查场景。

在本实施例中还提供了一种应用健康状态检查装置，该装置用于实现上述实施例及优选实施方式，已经进行过说明的不再赘述。如以下所使用的，术语“模块”可以实现预定功能的软件和/或硬件的组合。尽管以下实施例所描述的装置较佳地以软件来实现，但是硬件，或者软件和硬件的组合的实现也是可能并被构想的。

本实施例提供一种应用健康状态检查装置，应用于健康状态检查模块，所述健康状态检查模块独立于目标应用对应的部署对象设置，所述部署对象用于运行所述目标应用，如图6所示，所述装置包括：

第一获取模块51，用于获取目标应用对应的当前检查方式，所述当前检查方式是基于所述目标应用的上一次健康检查的结果确定的；

第二获取模块52，用于当所述当前检查方式为非主动检查时，从所述目标应用的就绪性探针接口获取所述目标应用的接口访问状态；

第一确定模块53，用于基于所述接口访问状态与对应的目标状态的关系，确定所述目标应用的当前健康检查结果以及下一次检查方式，所述当前健康检查结果包括在线或离线。

在一些可选实施方式中，所述接口访问状态包括接口访问成功次数、访问失败次数以及超时次数中的至少一种，确定模块53包括：

获取单元，用于当所述接口访问成功次数、所述访问失败次数以及所述超时次数中的至少一种发生变化时，获取所述目标应用的接口访问成功率；

第一确定单元，用于当所述接口访问成功率大于或等于目标访问成功率时，确定所述目标应用的当前健康检查结果为在线且所述下一次检查方式为非主动检查。

在一些可选实施方式中，所述获取单元包括：

第一获取子单元，用于获取发生变化的接口访问状态的连续变化次数；

第二获取子单元，用于当所述连续变化次数达到目标变化阈值时，获取所述目标应用的接口访问成功率。

在一些可选实施方式中，确定模块53还包括：

第二确定单元，用于当所述接口访问成功次数、所述访问失败次数以及所述超时次数均未发生变化且连续未变化次数达到目标未变化阈值时，确定所述目标应用的当前健康检查结果为离线且所述下一次检查方式为主动检查。

在一些可选实施方式中，应用健康状态检查装置还包括：

访问模块，用于当所述当前检查方式为主动检查时，对所述目标应用发起访问，确定所述主动检查的结果；

第二确定模块，用于基于所述主动检查的结果与对应的目标结果的关系，确定所述目标应用的当前健康检查结果以及下一次检查方式。

在一些可选实施方式中，所述主动检查的结果包括连续成功的次数或连续失败的次数，第二确定模块包括：

第三确定单元，用于当所述连续成功的次数大于或等于第一阈值时，确定所述目标应用的当前健康检查结果为在线且所述下一次检查方式为非主动检查；

第四确定单元，用于当所述连续失败的次数大于或等于第二阈值时，确定所述目标应用的当前健康检查结果为离线且所述下一次检查方式为主动检查。

在一些可选实施方式中，该装置包括：

添加模块，用户当所述当前健康检查结果为在线时，在所述地址访问资源中添加所述目标应用对应的部署对象的地址，所述地址访问资源用于记录在线的应用对应的部署对象的地址；

删除模块，用于当所述当前健康检查结果为离线时，在所述地址访问资源中删除所述目标应用对应的部署对象的地址。

在一些可选实施方式中，所述目标应用包括容器应用或虚拟机应用，该应用健康状态检查装置还包括：

第二获取模块，用于每隔预设时间，从所述目标应用的就绪性探针接口中获取所述目标应用的离线次数；

重启模块，用于当获取所述离线次数的时间超过预设时间或所述离线次数超过目标存活检查次数时，重启所述容器应用对应的部署对象或重启所述虚拟机应用。

本实施例中的应用健康状态检查装置是以功能单元的形式来呈现，这里的单元是指ASIC电路，执行一个或多个软件或固定程序的处理器和存储器，和/或其他可以提供上述功能的器件。

上述各个模块的更进一步的功能描述与上述对应实施例相同，在此不再赘述。

本发明实施例还提供一种电子设备，具有上述图6所示的应用健康状态检查装置。

请参阅图7，图7是本发明可选实施例提供的一种电子设备的结构示意图，如图7所示，该电子设备可以包括：至少一个处理器601，例如CPU(Central Processing Unit，中央处理器)，至少一个通信接口603，存储器604，至少一个通信总线602。其中，通信总线602用于实现这些组件之间的连接通信。其中，通信接口603可以包括显示屏(Display)、键盘(Keyboard)，可选通信接口603还可以包括标准的有线接口、无线接口。存储器604可以是高速RAM存储器(Random Access Memory，易挥发性随机存取存储器)，也可以是非不稳定的存储器(non-volatile memory)，例如至少一个磁盘存储器。存储器604可选的还可以是至少一个位于远离前述处理器601的存储装置。其中处理器601可以结合图6所描述的装置，存储器604中存储应用程序，且处理器601调用存储器604中存储的程序代码，以用于执行上述任一方法步骤。

其中，通信总线602可以是外设部件互连标准(peripheral componentinterconnect，简称PCI)总线或扩展工业标准结构(extended industry standardarchitecture，简称EISA)总线等。通信总线602可以分为地址总线、数据总线、控制总线等。为便于表示，图7中仅用一条粗线表示，但并不表示仅有一根总线或一种类型的总线。

其中，存储器604可以包括易失性存储器(英文：volatile memory)，例如随机存取存储器(英文：random-access memory，缩写：RAM)；存储器也可以包括非易失性存储器(英文：non-volatile memory)，例如快闪存储器(英文：flash memory)，硬盘(英文：hard diskdrive，缩写：HDD)或固态硬盘(英文：solid-state drive，缩写：SSD)；存储器604还可以包括上述种类的存储器的组合。

其中，处理器601可以是中央处理器(英文：central processing unit，缩写：CPU)，网络处理器(英文：network processor，缩写：NP)或者CPU和NP的组合。

其中，处理器601还可以进一步包括硬件芯片。上述硬件芯片可以是专用集成电路(英文：application-specific integrated circuit，缩写：ASIC)，可编程逻辑器件(英文：programmable logic device，缩写：PLD)或其组合。上述PLD可以是复杂可编程逻辑器件(英文：complex programmable logic device，缩写：CPLD)，现场可编程逻辑门阵列(英文：field-programmable gate array，缩写：FPGA)，通用阵列逻辑(英文：generic arraylogic,缩写：GAL)或其任意组合。

可选地，存储器604还用于存储程序指令。处理器601可以调用程序指令，实现如本申请任一实施例中所示的应用健康状态检查方法。

本发明实施例还提供了一种非暂态计算机存储介质，所述计算机存储介质存储有计算机可执行指令，该计算机可执行指令可执行上述任意方法实施例中的应用健康状态检查方法。其中，所述存储介质可为磁碟、光盘、只读存储记忆体(Read-Only Memory，ROM)、随机存储记忆体(Random Access Memory，RAM)、快闪存储器(Flash Memory)、硬盘(HardDisk Drive，缩写：HDD)或固态硬盘(Solid-State Drive，SSD)等；所述存储介质还可以包括上述种类的存储器的组合。

虽然结合附图描述了本发明的实施例，但是本领域技术人员可以在不脱离本发明的精神和范围的情况下做出各种修改和变型，这样的修改和变型均落入由所附权利要求所限定的范围之内。

Claims (10)

1.一种应用健康状态检查方法，其特征在于，应用于健康状态检查模块，所述健康状态检查模块独立于目标应用对应的部署对象设置，所述部署对象用于运行所述目标应用，所述方法包括：

获取目标应用对应的当前检查方式，所述当前检查方式是基于所述目标应用的上一次健康检查的结果确定的；

当所述当前检查方式为非主动检查时，从所述目标应用的就绪性探针接口获取所述目标应用的接口访问状态；

基于所述接口访问状态与对应的目标状态的关系，确定所述目标应用的当前健康检查结果以及下一次检查方式，所述当前健康检查结果包括在线或离线。

2.根据权利要求1所述的方法，其特征在于，所述接口访问状态包括接口访问成功次数、访问失败次数以及超时次数中的至少一种，所述基于所述接口访问状态与对应的目标状态的关系，确定所述目标应用的当前健康检查结果以及下一次检查方式，包括：

当所述接口访问成功次数、所述访问失败次数以及所述超时次数中的至少一种发生变化时，获取所述目标应用的接口访问成功率；

当所述接口访问成功率大于或等于目标访问成功率时，确定所述目标应用的当前健康检查结果为在线且所述下一次检查方式为非主动检查。

3.根据权利要求2所述的方法，其特征在于，所述获取所述目标应用的接口访问成功率，包括：

获取发生变化的接口访问状态的连续变化次数；

当所述连续变化次数达到目标变化阈值时，获取所述目标应用的接口访问成功率。

4.根据权利要求2所述的方法，其特征在于，所述基于所述接口访问状态与对应的目标状态的关系，确定所述目标应用的当前健康检查结果以及下一次检查方式，包括：

当所述接口访问成功次数、所述访问失败次数以及所述超时次数均未发生变化且连续未变化次数达到目标未变化阈值时，确定所述目标应用的当前健康检查结果为离线且所述下一次检查方式为主动检查。

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

当所述当前检查方式为主动检查时，对所述目标应用发起访问，确定所述主动检查的结果；

基于所述主动检查的结果与对应的目标结果的关系，确定所述目标应用的当前健康检查结果以及下一次检查方式。

6.根据权利要求5所述的方法，其特征在于，所述主动检查的结果包括连续成功的次数或连续失败的次数，所述基于所述主动检查的结果与对应的目标结果的关系，确定所述目标应用的当前健康检查结果以及下一次检查方式，包括：

当所述连续成功的次数大于或等于第一阈值时，确定所述目标应用的当前健康检查结果为在线且所述下一次检查方式为非主动检查；

当所述连续失败的次数大于或等于第二阈值时，确定所述目标应用的当前健康检查结果为离线且所述下一次检查方式为主动检查。

7.根据权利要求1所述的方法，其特征在于，所述方法还包括：

当所述当前健康检查结果为在线时，在地址访问资源中添加所述目标应用对应的部署对象的地址，所述地址访问资源用于记录在线的应用对应的部署对象的地址；

当所述当前健康检查结果为离线时，在所述地址访问资源中删除所述目标应用对应的部署对象的地址。

8.根据权利要求1所述的方法，其特征在于，所述目标应用包括容器应用或虚拟机应用，所述方法还包括：

每隔预设时间，从所述目标应用的就绪性探针接口中获取所述目标应用的离线次数；

当获取所述离线次数的时间超过预设时间或所述离线次数超过目标存活检查次数时，重启所述容器应用对应的部署对象或重启所述虚拟机应用。

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

存储器和处理器，所述存储器和所述处理器之间互相通信连接，所述存储器中存储有计算机指令，所述处理器通过执行所述计算机指令，从而执行权利要求1-8中任一项所述的应用健康状态检查方法。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质存储有计算机指令，所述计算机指令用于使计算机执行权利要求1-8中任一项所述的应用健康状态检查方法。

Images