CN105589787B - 应用程序的健康检查方法及健康检查系统 - Google Patents

Abstract

本发明提供了一种应用程序的健康检查方法和一种应用程序的健康检查系统，其中，所述应用程序的健康检查方法包括：获取CF平台中的与DEA组件关联的应用程序列表；判断所述应用程序列表中的应用程序是否处于运行状态；当判定所述应用程序处于运行状态时，通过所述DEA组件访问所述应用程序的健康检查接口以启动对所述应用程序的当前健康检查，并生成健康检查结果；将所述健康检查结果反馈至所述DEA组件，以供所述DEA组件根据所述健康检查结果对所述应用程序执行相应操作。该技术方案，可以有效地实现应用程序健康检查的负载均衡，并缩短检测周期、简化健康检查交互过程以及降低运维工作量，同时有效地避免对应用程序健康状态的误判，从而提升用户体验。

Description

应用程序的健康检查方法及健康检查系统

技术领域

本发明涉及计算机技术领域，具体而言，涉及一种应用程序的健康检查方法和一种应用程序的健康检查系统。

背景技术

目前，CloudFoundry(CF，云平台)提供了Link(连接)机制对App(Application，应用程序)进程进行监控，当进程退出，则Link中断，此时CF的DEA(Droplet ExecutionAgent，App的运行环境)组件发送crashed(崩溃)消息，CF平台的另一个组件HM(HealthManager，健康管理)负责将该进程重启。然而上述机制只是进程级的监控，当进程没有退出，但应用程序本身出现异常时，DEA无法感知，也就无法及时进行处理，影响了用户体验。

而针对上述问题，X3运行平台(eXtraction+eXtension+eXtreme，基于CloudFoundry平台构建，并对CloudFoundry进行了大量改造而实现的，负责整个平台的底层计算资源的管理)提供了一种应用级健康检查机制，具体地，X3运行平台上的每个应用程序都提供了健康检查接口，HM组件周期性从xif(X3Interface，X3接口)组件中获取虚机状态，遍历所有处于running(运行)状态的虚机接口，获取应用程序本身的状态信息，进而根据返回结果，判断虚机是否健康。比如：如果应用程序返回的状态码为200，则表明应用程序本身是健康的；如果返回的状态码为40X或无法访问，则报警，但不处理；如果返回的状态码为50X，则判断应用程序本身出现错误，重启虚机。该相关技术，虽然能够及时发现应用的异常并处理，当仍存在以下不足之处：

(1)检查时对DEA组件的压力不均衡。HM组件按xif组件返回的虚机记录发送请求，xif组件并没有记录某个虚机其属于哪一个DEA组件进行组织，因此HM组件发送请求时无法基于DEA组件平均分配请求，存在同时将大量请求发往同一个DEA组件的风险。当接口调用消耗DEA组件资源较多时，存在一定的风险。

(2)遍历时间长，实时性不够。为了避免压力多大影响DEA组件的正常运行，HM组件通常将所有处于running状态的虚机分成很多组，每次只对一组虚机进行检查，检查周期与处于running状态的虚机总数成正比。虚机数据越来越多，遍历时间也会越来越长，降低了实时性。

(3)交互过程复杂。在整个过程中，组件HM、xif和DEA都要参与，其中一个组件失效，则无法执行对应用程序的健康检查。

(4)数据有延迟，可能造成误判。HM组件从xif组件取到某个虚机的数据，到该虚机的接口调用成功，有一定的时间间隔，如果该段时间虚机状态发生变化，则HM组件可能造成误判。例如，HM组件获取虚机信息时，虚机状态为running，在遍历过程中，虚机状态变为suspended(暂停)，则HM组件检查到该虚机时，判断虚机无法访问，触发错误报警。

综上可知，面临的主要问题包括：

(1)健康检查接口响应时间长，2s左右，其风险在于：(a)导致主线程长期阻塞，Heartbeat(虚机心跳消息)中断，而heartbeat中断的后果是HM组件判断虚机丢失，在其他的DEA组件上重启虚机；(b)所有虚机信息存储在instance_registry(存储DEA组件中的所有虚机信息)中，对该数组遍历期间，其他线程无法访问，造成DEA工作异常。

(2)处理请求时CPU利用率高，举例来说，对一个DEA组件上10个处于running状态的App同时做健康检查时的CPU(Central Processing Unit，中央处理器)利用率，平均一个App的CPU利用率有30％左右，持续时间2到4秒，而处于running状态的App数量越多，健康检查操作所占用的CPU负载越高，可能会影响到其他操作，比如，整体CPU利用率可以按处于running状态的App数量乘以30％来算，当App数量上线达到40时，CPU利用率达到1200％，远高于平均值。

因此，如何实现应用程序健康检查的负载均衡，并缩短检测周期、简化健康检查交互过程以及降低运维工作量，同时有效地避免对应用程序健康状态的误判，从而提升用户体验成为亟待解决的技术问题。

发明内容

本发明正是基于上述技术问题，提出了一种新的技术方案，可以有效地实现应用程序健康检查的负载均衡，并缩短检测周期、简化健康检查交互过程以及降低运维工作量，同时有效地避免对应用程序健康状态的误判，从而提升用户体验。

有鉴于此，本发明的第一方面，提出了一种应用程序的健康检查方法，包括：获取CF平台中的与DEA组件关联的应用程序列表；判断所述应用程序列表中的应用程序是否处于运行状态；当判定所述应用程序处于运行状态时，通过所述DEA组件访问所述应用程序的健康检查接口以启动对所述应用程序的当前健康检查，并生成健康检查结果；将所述健康检查结果反馈至所述DEA组件，以供所述DEA组件根据所述健康检查结果对所述应用程序执行相应操作。

在该技术方案中，当对CF平台的应用程序进行健康状态检查时，首先获取CF平台中的不同的DEA组件的关联的应用程序列表，遍历该应用程序列表中的每个应用程序以确定其状态，对于处于运行状态的应用程序，通过CF平台的DEA组件访问其健康检查接口从而启动对该处于运行状态的应用程序的健康检查，并由DEA组件根据健康检查结果进行相应的处理，如此，通过CF平台的DEA组件发起对应用程序的健康检查，可以有效地实现应用程序健康检查的负载均衡，并缩短检测周期、简化健康检查交互过程以及降低运维工作量，同时有效地避免对应用程序健康状态的误判，从而提升用户体验。

在上述技术方案中，优选地，所述DEA组件通过调用转换层访问所述健康检查接口以及获取所述健康检查结果。

在该技术方案中，当通过CF平台的DEA组件访问处于运行状态的应用程序的健康检查接口时，具体地，在DEA组件和处于运行状态的应用程序的健康检查接口之间添加一个可在线更新的转换层，将具体的处理逻辑写在该转换层中，以供DEA组件通过该转换层访问处于运行状态的应用程序的健康检查接口并获取健康检查结果，优选地可以通过Shell(壳，是指“提供使用者使用界面”的软件(命令解析器))脚本实现该可在线更新的转换层的工作，如此，可以有效地避免由于将处理逻辑写在DEA组件中，需要在每次应用程序的健康检查接口更新或者判断应用程序状态的逻辑更新时修改DEA代码并重启DEA组件，从而提高服务重量，进一步提升用户体验。

在上述任一技术方案中，优选地，在所述DEA组件获取到所述健康检查结果之后以及根据所述健康检查结果执行相应操作之前，还包括：再次判断所述应用程序是否处于运行状态；在判断结果为是时，通过所述DEA组件根据所述健康检查结果对所述应用程序执行相应操作。

在该技术方案中，当DEA组件获取到对处于运行状态的应用程序的健康检查结果时，首先再次对其状态进行判断，以避免遍历过程中由于应用程序状态的改变而导致误判进而导致误处理，确保健康检查结果的实时有效性和准确性，然后在再次判定该应用程序依然处于运行状态时，才由DEA组件根据健康检查结果对该应用程序进行进一步的处理，从而提高对应用程序的健康检查结果的处理效率和准确性。

在上述任一技术方案中，优选地，所述健康检查结果包括：正常、有误、致命错误；以及当所述健康检查结果为正常时，所述DEA组件对所述应用程序不作处理；当所述健康检查结果为有误时，所述DEA组件对所述应用程序的错误提示进行打印操作；当所述健康检查结果为致命错误时，所述DEA组件对所述应用程序的错误提示进行打印操作并重新启动所述应用程序。

在该技术方案中，针对处于运行状态的应用程序的健康检查的不同结果对应有不同的处理策略，其中，健康检查结果包括但不限于正常(即Health)、有误(即error)和致命错误(即fatal)，具体地对应的处理策略为：若健康检查结果为正常，则DEA组件对该应用程序可不作任何处理；若健康检测结果为有误，即应用程序无法连接至数据库，则DEA组件打印错误提示；若健康检查结果为致命错误，即应用程序未启动，则DEA组件打印错误提示并重启该应用程序，如此，可以有效地解决当进程未退出但应用程序本身出现异常时无法及时处理的问题，提高健康检查结果的准确性以及处理的及时性。

在上述任一技术方案中，优选地，在所述获取CF平台中的与DEA组件关联的应用程序列表之前，还包括：判断是否到达进行所述当前健康检查的设定周期，以及所述当前健康检查的前次健康检查是否结束；在判定到达所述当前健康检查的所述设定周期且所述前次健康检查已结束时，获取所述应用程序列表。

在该技术方案中，在通过DEA组件发起对应用程序的健康检查，即获取与其关联的应用程序列表之前，首先判断是否到达了进行新的一次健康检查的设定周期以及上一次的健康检查是否已经结束，在判定均为是时，启动新的一次的健康检查，具体时间周期的设定可以根据CF平台中的DEA组件以及每个DEA组件的应用程序的情况而定，如此，通过设定对应用程序进行健康检查的周期可以及时有效地发现问题并进行处理，提高运行效率。

根据本发明的第二方面，提出了一种应用程序的健康检查系统，包括：获取模块，用于获取CF平台中的与DEA组件关联的应用程序列表；判断模块，用于判断所述应用程序列表中的应用程序是否处于运行状态；检查模块，用于当判定所述应用程序处于运行状态时，通过所述DEA组件访问所述应用程序的健康检查接口以启动对所述应用程序的当前健康检查，并生成健康检查结果；处理模块，用于将所述健康检查结果反馈至所述DEA组件，以供所述DEA组件根据所述健康检查结果对所述应用程序执行相应操作。

在该技术方案中，当对CF平台的应用程序进行健康状态检查时，首先获取CF平台中的不同的DEA组件的关联的应用程序列表，遍历该应用程序列表中的每个应用程序以确定其状态，对于处于运行状态的应用程序，通过CF平台的DEA组件访问其健康检查接口从而启动对该处于运行状态的应用程序的健康检查，并由DEA组件根据健康检查结果进行相应的处理，如此，通过CF平台的DEA组件发起对应用程序的健康检查，可以有效地实现应用程序健康检查的负载均衡，并缩短检测周期、简化健康检查交互过程以及降低运维工作量，同时有效地避免对应用程序健康状态的误判，从而提升用户体验。

在上述技术方案中，优选地，所述DEA组件通过调用转换层访问所述健康检查接口以及获取所述健康检查结果。

在该技术方案中，当通过CF平台的DEA组件访问处于运行状态的应用程序的健康检查接口时，具体地，在DEA组件和处于运行状态的应用程序的健康检查接口之间添加一个可在线更新的转换层，将具体的处理逻辑写在该转换层中，以供DEA组件通过该转换层访问处于运行状态的应用程序的健康检查接口并获取健康检查结果，优选地可以通过Shell(壳，是指“提供使用者使用界面”的软件(命令解析器))脚本实现该可在线更新的转换层的工作，如此，可以有效地避免由于将处理逻辑写在DEA组件中，需要在每次应用程序的健康检查接口更新或者判断应用程序状态的逻辑更新时修改DEA代码并重启DEA组件，从而提高服务重量，进一步提升用户体验。

在上述任一技术方案中，优选地，所述判断模块还用于：在所述DEA组件获取到所述健康检查结果之后以及根据所述健康检查结果执行相应操作之前，再次判断所述应用程序是否处于运行状态；所述处理模块具体用于：在判断结果为是时，通过所述DEA组件根据所述检查模块生成的所述健康检查结果对所述应用程序执行相应操作。

在该技术方案中，当DEA组件获取到对处于运行状态的应用程序的健康检查结果时，首先再次对其状态进行判断，以避免遍历过程中由于应用程序状态的改变而导致误判进而导致误处理，确保健康检查结果的实时有效性和准确性，然后在再次判定该应用程序依然处于运行状态时，才由DEA组件根据健康检查结果对该应用程序进行进一步的处理，从而提高对应用程序的健康检查结果的处理效率和准确性。

在上述任一技术方案中，优选地，所述健康检查结果包括：正常、有误、致命错误；以及所述处理模块具体用于：当所述检查模块生成的所述健康检查结果为正常时，控制所述DEA组件对所述应用程序不作处理；当所述检查模块生成的所述健康检查结果为有误时，调用所述DEA组件对所述应用程序的错误提示进行打印操作；当所述检查模块生成的所述健康检查结果为致命错误时，调用所述DEA组件对所述应用程序的错误提示进行打印操作并重新启动所述应用程序。

在该技术方案中，针对处于运行状态的应用程序的健康检查的不同结果对应有不同的处理策略，其中，健康检查结果包括但不限于正常(即Health)、有误(即error)和致命错误(即fatal)，具体地对应的处理策略为：若健康检查结果为正常，则DEA组件对该应用程序可不作任何处理；若健康检测结果为有误，即应用程序无法连接至数据库，则DEA组件打印错误提示；若健康检查结果为致命错误，即应用程序未启动，则DEA组件打印错误提示并重启该应用程序，如此，可以有效地解决当进程未退出但应用程序本身出现异常时无法及时处理的问题，提高健康检查结果的准确性以及处理的及时性。

在上述任一技术方案中，优选地，所述判断模块还用于：在所述获取模块获取CF平台中的与DEA组件关联的应用程序列表之前，判断是否到达进行所述当前健康检查的设定周期，以及所述当前健康检查的前次健康检查是否结束；所述获取模块具体用于：在所述判断模块判定到达所述当前健康检查的所述设定周期且所述前次健康检查已结束时，获取所述应用程序列表。

在该技术方案中，在通过DEA组件发起对应用程序的健康检查，即获取与其关联的应用程序列表之前，首先判断是否到达了进行新的一次健康检查的设定周期以及上一次的健康检查是否已经结束，在判定均为是时，启动新的一次的健康检查，具体时间周期的设定可以根据CF平台中的DEA组件以及每个DEA组件的应用程序的情况而定，如此，通过设定对应用程序进行健康检查的周期可以及时有效地发现问题并进行处理，提高运行效率。

通过以上技术方案，可以有效地实现应用程序健康检查的负载均衡，并缩短检测周期、简化健康检查交互过程以及降低运维工作量，同时有效地避免对应用程序健康状态的误判，从而提升用户体验。

附图说明

图1示出了根据本发明的一个实施例的应用程序的健康检查方法的流程示意图；

图2示出了根据本发明的一个实施例的应用程序的健康检查系统的框图；

图3示出了根据本发明的另一个实施例的应用程序的健康检查方法的流程示意图。

具体实施方式

为了能够更清楚地理解本发明的上述目的、特征和优点，下面结合附图和具体实施方式对本发明进行进一步的详细描述。需要说明的是，在不冲突的情况下，本申请的实施例及实施例中的特征可以相互组合。

在下面的描述中阐述了很多具体细节以便于充分理解本发明，但是，本发明还可以采用其他不同于在此描述的其他方式来实施，因此，本发明的保护范围并不受下面公开的具体实施例的限制。

图1示出了根据本发明的一个实施例的应用程序的健康检查方法的流程示意图。

如图1所示，根据本发明的一个实施例的应用程序的健康检查方法，包括：步骤102，获取CF平台中的与DEA组件关联的应用程序列表；步骤104，判断所述应用程序列表中的应用程序是否处于运行状态；步骤106，当判定所述应用程序处于运行状态时，通过所述DEA组件访问所述应用程序的健康检查接口以启动对所述应用程序的当前健康检查，并生成健康检查结果；步骤108，将所述健康检查结果反馈至所述DEA组件，以供所述DEA组件根据所述健康检查结果对所述应用程序执行相应操作。

在该技术方案中，当对CF平台的应用程序进行健康状态检查时，首先获取CF平台中的不同的DEA组件的关联的应用程序列表，遍历该应用程序列表中的每个应用程序以确定其状态，对于处于运行状态的应用程序，通过CF平台的DEA组件访问其健康检查接口从而启动对该处于运行状态的应用程序的健康检查，并由DEA组件根据健康检查结果进行相应的处理，如此，通过CF平台的DEA组件发起对应用程序的健康检查，可以有效地实现应用程序健康检查的负载均衡，并缩短检测周期、简化健康检查交互过程以及降低运维工作量，同时有效地避免对应用程序健康状态的误判，从而提升用户体验。

在上述技术方案中，优选地，所述DEA组件通过调用转换层访问所述健康检查接口以及获取所述健康检查结果。

在该技术方案中，当通过CF平台的DEA组件访问处于运行状态的应用程序的健康检查接口时，具体地，在DEA组件和处于运行状态的应用程序的健康检查接口之间添加一个可在线更新的转换层，将具体的处理逻辑写在该转换层中，以供DEA组件通过该转换层访问处于运行状态的应用程序的健康检查接口并获取健康检查结果，优选地可以通过Shell(壳，是指“提供使用者使用界面”的软件(命令解析器))脚本实现该可在线更新的转换层的工作，如此，可以有效地避免由于将处理逻辑写在DEA组件中，需要在每次应用程序的健康检查接口更新或者判断应用程序状态的逻辑更新时修改DEA代码并重启DEA组件，从而提高服务重量，进一步提升用户体验。

在上述任一技术方案中，优选地，在所述DEA组件获取到所述健康检查结果之后以及根据所述健康检查结果执行相应操作之前，还包括：再次判断所述应用程序是否处于运行状态；在判断结果为是时，通过所述DEA组件根据所述健康检查结果对所述应用程序执行相应操作。

在该技术方案中，当DEA组件获取到对处于运行状态的应用程序的健康检查结果时，首先再次对其状态进行判断，以避免遍历过程中由于应用程序状态的改变而导致误判进而导致误处理，确保健康检查结果的实时有效性和准确性，然后在再次判定该应用程序依然处于运行状态时，才由DEA组件根据健康检查结果对该应用程序进行进一步的处理，从而提高对应用程序的健康检查结果的处理效率和准确性。

在上述任一技术方案中，优选地，所述健康检查结果包括：正常、有误、致命错误；以及当所述健康检查结果为正常时，所述DEA组件对所述应用程序不作处理；当所述健康检查结果为有误时，所述DEA组件对所述应用程序的错误提示进行打印操作；当所述健康检查结果为致命错误时，所述DEA组件对所述应用程序的错误提示进行打印操作并重新启动所述应用程序。

在该技术方案中，针对处于运行状态的应用程序的健康检查的不同结果对应有不同的处理策略，其中，健康检查结果包括但不限于正常(即Health)、有误(即error)和致命错误(即fatal)，具体地对应的处理策略为：若健康检查结果为正常，则DEA组件对该应用程序可不作任何处理；若健康检测结果为有误，即应用程序无法连接至数据库，则DEA组件打印错误提示；若健康检查结果为致命错误，即应用程序未启动，则DEA组件打印错误提示并重启该应用程序，如此，可以有效地解决当进程未退出但应用程序本身出现异常时无法及时处理的问题，提高健康检查结果的准确性以及处理的及时性。

在上述任一技术方案中，优选地，在所述步骤102之前，还包括：判断是否到达进行所述当前健康检查的设定周期，以及所述当前健康检查的前次健康检查是否结束；在判定到达所述当前健康检查的所述设定周期且所述前次健康检查已结束时，获取所述应用程序列表。

在该技术方案中，在通过DEA组件发起对应用程序的健康检查，即获取与其关联的应用程序列表之前，首先判断是否到达了进行新的一次健康检查的设定周期以及上一次的健康检查是否已经结束，在判定均为是时，启动新的一次的健康检查，具体时间周期的设定可以根据CF平台中的DEA组件以及每个DEA组件的应用程序的情况而定，如此，通过设定对应用程序进行健康检查的周期可以及时有效地发现问题并进行处理，提高运行效率。

图2示出了根据本发明的一个实施例的应用程序的健康检查系统的框图。

如图2所示，根据本发明的一个实施例的应用程序的健康检查系统200，包括：获取模块202、判断模块204、检查模块206和处理模块208。

其中，获取模块202，用于获取CF平台中的与DEA组件关联的应用程序列表；判断模块204，用于判断所述应用程序列表中的应用程序是否处于运行状态；检查模块206，用于当判定所述应用程序处于运行状态时，通过所述DEA组件访问所述应用程序的健康检查接口以启动对所述应用程序的当前健康检查，并生成健康检查结果；处理模块208，用于将所述健康检查结果反馈至所述DEA组件，以供所述DEA组件根据所述健康检查结果对所述应用程序执行相应操作。

在该技术方案中，当对CF平台的应用程序进行健康状态检查时，首先获取CF平台中的不同的DEA组件的关联的应用程序列表，遍历该应用程序列表中的每个应用程序以确定其状态，对于处于运行状态的应用程序，通过CF平台的DEA组件访问其健康检查接口从而启动对该处于运行状态的应用程序的健康检查，并由DEA组件根据健康检查结果进行相应的处理，如此，通过CF平台的DEA组件发起对应用程序的健康检查，可以有效地实现应用程序健康检查的负载均衡，并缩短检测周期、简化健康检查交互过程以及降低运维工作量，同时有效地避免对应用程序健康状态的误判，从而提升用户体验。

在上述技术方案中，优选地，所述DEA组件通过调用转换层访问所述健康检查接口以及获取所述健康检查结果。

在该技术方案中，当通过CF平台的DEA组件访问处于运行状态的应用程序的健康检查接口时，具体地，在DEA组件和处于运行状态的应用程序的健康检查接口之间添加一个可在线更新的转换层，将具体的处理逻辑写在该转换层中，以供DEA组件通过该转换层访问处于运行状态的应用程序的健康检查接口并获取健康检查结果，优选地可以通过Shell(壳，是指“提供使用者使用界面”的软件(命令解析器))脚本实现该可在线更新的转换层的工作，如此，可以有效地避免由于将处理逻辑写在DEA组件中，需要在每次应用程序的健康检查接口更新或者判断应用程序状态的逻辑更新时修改DEA代码并重启DEA组件，从而提高服务重量，进一步提升用户体验。

在上述任一技术方案中，优选地，所述判断模块204还用于：在所述DEA组件获取到所述健康检查结果之后以及根据所述健康检查结果执行相应操作之前，再次判断所述应用程序是否处于运行状态；所述处理模块208具体用于：在判断结果为是时，通过所述DEA组件根据所述检查模块206生成的所述健康检查结果对所述应用程序执行相应操作。

在该技术方案中，当DEA组件获取到对处于运行状态的应用程序的健康检查结果时，首先再次对其状态进行判断，以避免遍历过程中由于应用程序状态的改变而导致误判进而导致误处理，确保健康检查结果的实时有效性和准确性，然后在再次判定该应用程序依然处于运行状态时，才由DEA组件根据健康检查结果对该应用程序进行进一步的处理，从而提高对应用程序的健康检查结果的处理效率和准确性。

在上述任一技术方案中，优选地，所述健康检查结果包括：正常、有误、致命错误；以及所述处理模块208具体用于：当所述检查模块206生成的所述健康检查结果为正常时，控制所述DEA组件对所述应用程序不作处理；当所述检查模块206生成的所述健康检查结果为有误时，调用所述DEA组件对所述应用程序的错误提示进行打印操作；当所述检查模块206生成的所述健康检查结果为致命错误时，调用所述DEA组件对所述应用程序的错误提示进行打印操作并重新启动所述应用程序。

在该技术方案中，针对处于运行状态的应用程序的健康检查的不同结果对应有不同的处理策略，其中，健康检查结果包括但不限于正常(即Health)、有误(即error)和致命错误(即fatal)，具体地对应的处理策略为：若健康检查结果为正常，则DEA组件对该应用程序可不作任何处理；若健康检测结果为有误，即应用程序无法连接至数据库，则DEA组件打印错误提示；若健康检查结果为致命错误，即应用程序未启动，则DEA组件打印错误提示并重启该应用程序，如此，可以有效地解决当进程未退出但应用程序本身出现异常时无法及时处理的问题，提高健康检查结果的准确性以及处理的及时性。

在上述任一技术方案中，优选地，所述判断模块204还用于：在所述获取模块202获取CF平台中的与DEA组件关联的应用程序列表之前，判断是否到达进行所述当前健康检查的设定周期，以及所述当前健康检查的前次健康检查是否结束；所述获取模块202具体用于：在所述判断模块204判定到达所述当前健康检查的所述设定周期且所述前次健康检查已结束时，获取所述应用程序列表。

在该技术方案中，在通过DEA组件发起对应用程序的健康检查，即获取与其关联的应用程序列表之前，首先判断是否到达了进行新的一次健康检查的设定周期以及上一次的健康检查是否已经结束，在判定均为是时，启动新的一次的健康检查，具体时间周期的设定可以根据CF平台中的DEA组件以及每个DEA组件的应用程序的情况而定，如此，通过设定对应用程序进行健康检查的周期可以及时有效地发现问题并进行处理，提高运行效率。

图3示出了根据本发明的另一个实施例的应用程序的健康检查方法的流程示意图。

如图3所示，根据本发明的另一个实施例的应用程序的健康检查方法，具体包括：

步骤302，初始化健康检查定时器，即设置进行健康检查的设定周期；

步骤304，判断定时器是否到期，即判断是否进行当前健康检查的设定周期，若是，则执行步骤306，否则继续判断；

步骤306，判断上次扫描是否已结束，即判断上一次健康检查是否结束，若是，则执行步骤308，否则继续上次扫描；

步骤308，获取dump虚机列表，即获取应用程序列表，其中，dump文件是进程(与应用程序对应)的内存镜像，用于存储应用程序的执行状态，一个CF平台对应多个DEA组件，一个DEA组件对应多个虚机(即进程或应用程序)；

步骤310，进行串行检查，判断获取到的dump虚机列表中是否存在App，若是，则执行步骤312，否则，结束此次健康检查；

步骤312，判断App的当前执行状态是否为running状态，若是，执行步骤314，否则返回步骤310；

步骤314，后台调用应用程序的健康检查接口进行健康检查，得到串行检查结果，即通过DEA组件访问应用程序的健康检查接口发起健康检查；

步骤316，执行主线程中的回调函数，获取健康检查结果；

步骤318，结合每个虚机当前执行状态对健康检查结果进行处理，为避免在遍历过程中instance_registry状态改变导致异常，先dump instance_registry中的元素到snapshot(内存快照)中，然后遍历snapshot，检查前和处理前，需要判断虚机状态是否仍为running，避免误判；

步骤320，若健康检查结果为health，则不作处理结束此次健康检查，若健康检查结果为error，则打印错误日志，若健康检查结果为fatal，则重新App并打印错误日志，其中，health表示所有虚机正常，error表示有应用程序无法连接数据库，fatal表示有应用程序未启动。

需要注意的是，在本发明的技术方案中，为了避免因将具体的处理逻辑写在DEA组件中，使每次健康检查接口更新或判断策略更新都要求修改DEA代码并重启DEA组件，影响服务质量这种问题，在应用程序的健康检查接口和DEA组件之间添加一个可在线更新的转换层，将健康检查接口返回信息翻译成DEA可读的形式，那么，即使健康检查接口或判断策略修改，只需要修改转换层代码即可，无需重启DEA组件，实际中采用一个shell脚本实现转换层的工作，具体地，引入转换层后，DEA组件判断虚机健康状态的流程如下：

(1)调用shell脚本，访问虚机健康检查接口，得到检查结果；

(2)shell脚本对检查结果进行翻译，将翻译结果返回给DEA组件；

(3)DEA组件对shell脚本返回结果进行处理，根据返回状态执行相应的操作。

如此，DEA组件每次健康检查都会重新加载健康检查shell脚本，得到检查结果。在修改shell脚本后，不用重启DEA就能够生效。当接口升级，或检查、判断机制需要修改时，只需修改检查脚本即可，无需重启DEA进程。

综上所述，通过本发明的技术方案，实现了负载均衡，缩短了检测周期，简化了交互过程，避免了误判，同时由于转换层，即健康检查shell脚本，可在线更新，降低了运维工作量，因此，在有效控制CPU消耗的前提下，检查周期大大缩短，并且检查周期是可预测的。

以上结合附图详细说明了本发明的技术方案，可以有效地实现应用程序健康检查的负载均衡，并缩短检测周期、简化健康检查交互过程以及降低运维工作量，同时有效地避免对应用程序健康状态的误判，从而提升用户体验。

以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (8)

1.一种应用程序的健康检查方法，其特征在于，包括：

获取CF平台中的与DEA组件关联的应用程序列表；

判断所述应用程序列表中的应用程序是否处于运行状态；

当判定所述应用程序处于运行状态时，通过所述DEA组件访问所述应用程序的健康检查接口以启动对所述应用程序的当前健康检查，并生成健康检查结果；

将所述健康检查结果反馈至所述DEA组件，以供所述DEA组件根据所述健康检查结果对所述应用程序执行相应操作；

所述DEA组件通过调用转换层访问所述健康检查接口以及获取所述健康检查结果。

2.根据权利要求1所述的应用程序的健康检查方法，其特征在于，在所述DEA组件获取到所述健康检查结果之后以及根据所述健康检查结果执行相应操作之前，还包括：

再次判断所述应用程序是否处于运行状态；

在判断结果为是时，通过所述DEA组件根据所述健康检查结果对所述应用程序执行相应操作。

3.根据权利要求1或2所述应用程序的健康检查方法，其特征在于，所述健康检查结果包括：正常、有误、致命错误；以及

当所述健康检查结果为正常时，所述DEA组件对所述应用程序不作处理；

当所述健康检查结果为有误时，所述DEA组件对所述应用程序的错误提示进行打印操作；

当所述健康检查结果为致命错误时，所述DEA组件对所述应用程序的错误提示进行打印操作并重新启动所述应用程序。

4.根据权利要求1或2所述应用程序的健康检查方法，其特征在于，在所述获取CF平台中的与DEA组件关联的应用程序列表之前，还包括：

判断是否到达进行所述当前健康检查的设定周期，以及所述当前健康检查的前次健康检查是否结束；

在判定到达所述当前健康检查的所述设定周期且所述前次健康检查已结束时，获取所述应用程序列表。

5.一种应用程序的健康检查系统，其特征在于，包括：

获取模块，用于获取CF平台中的与DEA组件关联的应用程序列表；

判断模块，用于判断所述应用程序列表中的应用程序是否处于运行状态；

检查模块，用于当判定所述应用程序处于运行状态时，通过所述DEA组件访问所述应用程序的健康检查接口以启动对所述应用程序的当前健康检查，并生成健康检查结果；

处理模块，用于将所述健康检查结果反馈至所述DEA组件，以供所述DEA组件根据所述健康检查结果对所述应用程序执行相应操作；

所述DEA组件通过调用转换层访问所述健康检查接口以及获取所述健康检查结果。

6.根据权利要求5所述的应用程序的健康检查系统，其特征在于，

所述判断模块还用于：在所述DEA组件获取到所述健康检查结果之后以及根据所述健康检查结果执行相应操作之前，再次判断所述应用程序是否处于运行状态；

所述处理模块具体用于：在判断结果为是时，通过所述DEA组件根据所述检查模块生成的所述健康检查结果对所述应用程序执行相应操作。

7.根据权利要求5或6所述的应用程序的健康检查系统，其特征在于，所述健康检查结果包括：正常、有误、致命错误；以及

所述处理模块具体用于：

当所述检查模块生成的所述健康检查结果为正常时，控制所述DEA组件对所述应用程序不作处理；

当所述检查模块生成的所述健康检查结果为有误时，调用所述DEA组件对所述应用程序的错误提示进行打印操作；

当所述检查模块生成的所述健康检查结果为致命错误时，调用所述DEA组件对所述应用程序的错误提示进行打印操作并重新启动所述应用程序。

8.根据权利要求5或6所述的应用程序的健康检查系统，其特征在于，

所述判断模块还用于：在所述获取模块获取CF平台中的与DEA组件关联的应用程序列表之前，判断是否到达进行所述当前健康检查的设定周期，以及所述当前健康检查的前次健康检查是否结束；

所述获取模块具体用于：在所述判断模块判定到达所述当前健康检查的所述设定周期且所述前次健康检查已结束时，获取所述应用程序列表。