应用程序的健康检查方法及健康检查系统的制作方法
【技术领域】
[0001]本发明涉及计算机技术领域，具体而言，涉及一种应用程序的健康检查方法和一种应用程序的健康检查系统。
【背景技术】
[0002]目前，CloudFoundry(CF，云平台)提供了Link(连接)机制对App(Applicat1n，应用程序)进程进行监控，当进程退出，则Link中断，此时CF的DEA(Droplet Execut1nAgent，App的运行环境)组件发送crashed(崩溃)消息，CF平台的另一个组件HM(HealthManager，健康管理)负责将该进程重启。然而上述机制只是进程级的监控，当进程没有退出，但应用程序本身出现异常时，DEA无法感知，也就无法及时进行处理，影响了用户体验。
[0003]而针对上述问题，X3运行平台(eXtract1n + eXtens1n + eXtreme，基于CloudFoundry平台构建，并对CloudFoundry进行了大量改造而实现的，负责整个平台的底层计算资源的管理)提供了一种应用级健康检查机制，具体地，X3运行平台上的每个应用程序都提供了健康检查接口，HM组件周期性从xif (X3Interface，X3接口)组件中获取虚机状态，遍历所有处于running(运行)状态的虚机接口，获取应用程序本身的状态信息，进而根据返回结果，判断虚机是否健康。比如:如果应用程序返回的状态码为200，则表明应用程序本身是健康的；如果返回的状态码为40X或无法访问，则报警，但不处理;如果返回的状态码为50X，则判断应用程序本身出现错误，重启虚机。该相关技术，虽然能够及时发现应用的异常并处理，当仍存在以下不足之处:
[0004](I)检查时对DEA组件的压力不均衡。HM组件按xif组件返回的虚机记录发送请求，xif组件并没有记录某个虚机其属于哪一个DEA组件进行组织，因此HM组件发送请求时无法基于DEA组件平均分配请求，存在同时将大量请求发往同一个DEA组件的风险。当接口调用消耗DEA组件资源较多时，存在一定的风险。
[0005](2)遍历时间长，实时性不够。为了避免压力多大影响DEA组件的正常运行，HM组件通常将所有处于running状态的虚机分成很多组，每次只对一组虚机进行检查，检查周期与处于running状态的虚机总数成正比。虚机数据越来越多，遍历时间也会越来越长，降低了实时性。
[0006](3)交互过程复杂。在整个过程中，组件HM、xif和DEA都要参与，其中一个组件失效，则无法执行对应用程序的健康检查。
[0007](4)数据有延迟，可能造成误判。HM组件从xif组件取到某个虚机的数据，到该虚机的接口调用成功，有一定的时间间隔，如果该段时间虚机状态发生变化，则HM组件可能造成误判。例如，HM组件获取虚机信息时，虚机状态为running，在遍历过程中，虚机状态变为suspended(暂停)，则HM组件检查到该虚机时，判断虚机无法访问，触发错误报警。
[0008]综上可知，面临的主要问题包括:
[0009](I)健康检查接口响应时间长，2s左右，其风险在于:(a)导致主线程长期阻塞，Heartbeat(虚机心跳消息)中断，而heartbeat中断的后果是HM组件判断虚机丢失，在其他的DEA组件上重启虚机；(b)所有虚机信息存储在instance_registry(存储DEA组件中的所有虚机信息)中，对该数组遍历期间，其他线程无法访问，造成DEA工作异常。
[0010](2)处理请求时CPU利用率高，举例来说，对一个DEA组件上10个处于running状态的App同时做健康检查时的CPU(Central Processing Unit，中央处理器)利用率，平均一个App的CPU利用率有30%左右，持续时间2到4秒，而处于running状态的App数量越多，健康检查操作所占用的CHJ负载越高，可能会影响到其他操作，比如，整体CHJ利用率可以按处于running状态的App数量乘以30 %来算，当App数量上线达到40时，CPU利用率达到1200 %，远高于平均值。
[0011]因此，如何实现应用程序健康检查的负载均衡，并缩短检测周期、简化健康检查交互过程以及降低运维工作量，同时有效地避免对应用程序健康状态的误判，从而提升用户体验成为亟待解决的技术问题。
【发明内容】
[0012]本发明正是基于上述技术问题，提出了一种新的技术方案，可以有效地实现应用程序健康检查的负载均衡，并缩短检测周期、简化健康检查交互过程以及降低运维工作量，同时有效地避免对应用程序健康状态的误判，从而提升用户体验。
[0013]有鉴于此，本发明的第一方面，提出了一种应用程序的健康检查方法，包括:获取CF平台中的与DEA组件关联的应用程序列表;判断所述应用程序列表中的应用程序是否处于运行状态；当判定所述应用程序处于运行状态时，通过所述DEA组件访问所述应用程序的健康检查接口以启动对所述应用程序的当前健康检查，并生成健康检查结果;将所述健康检查结果反馈至所述DEA组件，以供所述DEA组件根据所述健康检查结果对所述应用程序执行相应操作。
[0014]在该技术方案中，当对CF平台的应用程序进行健康状态检查时，首先获取CF平台中的不同的DEA组件的关联的应用程序列表，遍历该应用程序列表中的每个应用程序以确定其状态，对于处于运行状态的应用程序，通过CF平台的DEA组件访问其健康检查接口从而启动对该处于运行状态的应用程序的健康检查，并由DEA组件根据健康检查结果进行相应的处理，如此，通过CF平台的DEA组件发起对应用程序的健康检查，可以有效地实现应用程序健康检查的负载均衡，并缩短检测周期、简化健康检查交互过程以及降低运维工作量，同时有效地避免对应用程序健康状态的误判，从而提升用户体验。
[0015]在上述技术方案中，优选地，所述DEA组件通过调用转换层访问所述健康检查接口以及获取所述健康检查结果。
[0016]在该技术方案中，当通过CF平台的DEA组件访问处于运行状态的应用程序的健康检查接口时，具体地，在DEA组件和处于运行状态的应用程序的健康检查接口之间添加一个可在线更新的转换层，将具体的处理逻辑写在该转换层中，以供DEA组件通过该转换层访问处于运行状态的应用程序的健康检查接口并获取健康检查结果，优选地可以通过Shell(壳，是指“提供使用者使用界面”的软件(命令解析器))脚本实现该可在线更新的转换层的工作，如此，可以有效地避免由于将处理逻辑写在DEA组件中，需要在每次应用程序的健康检查接口更新或者判断应用程序状态的逻辑更新时修改DEA代码并重启DEA组件，从而提高服务重量，进一步提升用户体验。
[0017]在上述任一技术方案中，优选地，在所述DEA组件获取到所述健康检查结果之后以及根据所述健康检查结果执行相应操作之前，还包括:再次判断所述应用程序是否处于运行状态;在判断结果为是时，通过所述DEA组件根据所述健康检查结果对所述应用程序执行相应操作。
[0018]在该技术方案中，当DEA组件获取到对处于运行状态的应用程序的健康检查结果时，首先再次对其状态进行判断，以避免遍历过程中由于应用程序状态的改变而导致误判进而导致误处理，确保健康检查结果的实时有效性和准确性，然后在再次判定该应用程序依然处于运行状态时，才由DEA组件根据健康检查结果对该应用程序进行进一步的处理，从而提高对应用程序的健康检查结果的处理效率和准确性。
[0019]在上述任一技术方案中，优选地，所述健康检查结果包括:正常、有误、致命错误；以及当所述健康检查结果为正常时，所述DEA组件对所述应用程序不作处理；当所述健康检查结果为有误时，所述DEA组件对所述应用程序的错误提示进行打印操作；当所述健康检查结果为致命错误时，所述DEA组件对所述应用程序的错误提示进行打印操作并重新启动所述应用程序。
[0020]在该技术方案中，针对处于运行状态的应用程序的健康检查的不同结果对应有不同的处理策略，其中，健康检查结果包括但不限于正常(即Health)、有误(S卩error)和致命错误(即fatal)，具体地对应的处理策略为:若健康检查结果为正常，则DEA组件对该应用程序可不作任何处理;若健康检测结果为有误，即应用程序无法连接至数据库，则DEA组件打印错误提示;若健康检查结果为致命错误，即应用程序未启动，则DEA组件打印错误提示并重启该应用程序，如此，可以有效地解决当进程未退出但应用程序本身出现异常时无法及时处理的问题，提高健康检查结果的准确性以及处理的及时性。
[0021]在上述任一技术方案中，优选地，在所述获取CF平台中的与DEA组件关联的应用程序列表之前，还包括:判断是否到达进行所