CN108595333B - PaaS平台中应用进程的健康检查方法及装置 - Google Patents

Abstract

本申请实施例公开了一种PaaS平台中应用进程的健康检查方法及装置，属于PaaS平台领域。所述方法包括：接收管理服务器下发的目标健康检查规则，不同的健康检查规则对应不同的应用进程；检测是否达到目标健康检查规则所指示的检查时机；当达到目标健康检查规则所指示的检查时机时，根据健康检查规则所指示的检查方式，对目标应用进程进行健康检查；若健康检查结果指示目标应用进程存在异常，则根据目标健康检查规则所指示的异常处理方式对目标应用进程进行处理。本申请实施例中，应用服务器基于健康检查规则自动对运行的应用进程进行可用性检查，并及时对不可用的应用进程进行处理，从而提高PaaS平台中各应用进程所提供服务的可用性。

Description

PaaS平台中应用进程的健康检查方法及装置

技术领域

本申请实施例涉及PaaS平台技术领域，特别涉及一种PaaS平台中应用进程的健康检查方法及装置。

背景技术

平台即服务(Platform-as-a-Service，PaaS)是一种将服务器平台或开发环境作为服务提供给应用开发商的服务模式。

PssS平台提供了应用开发到上线过程中所涉及的一系列基础服务支持，降低了应用开发的难度，而如何保证PaaS平台中众多应用进程的高可用性成为有待解决的问题之一。

发明内容

本申请实施例提供了一种PaaS平台中应用进程的健康检查方法及装置，可以用于解决如何提高PaaS平台中众多应用进程可用性的问题。所述技术方案如下：

第一方面，提供了一种PaaS平台中应用进程的健康检查方法，所述方法用于PaaS平台中的应用服务器，所述应用服务器运行有多个应用进程，所述方法包括：

接收管理服务器下发的目标健康检查规则，不同的健康检查规则对应不同的应用进程；

检测是否达到所述目标健康检查规则所指示的检查时机；

当达到所述目标健康检查规则所指示的所述检查时机时，根据所述健康检查规则所指示的检查方式，对所述目标应用进程进行健康检查；

若所述健康检查结果指示所述目标应用进程存在异常，则根据所述目标健康检查规则所指示的异常处理方式对所述目标应用进程进行处理。

第二方面，提供了一种PaaS平台中应用进程的健康检查装置，所述装置用于PaaS平台中的应用服务器，所述应用服务器运行有多个应用进程，所述装置包括：

规则接收模块，用于接收管理服务器下发的目标健康检查规则，不同的健康检查规则对应不同的应用进程；

时机检测模块，用于检测是否达到所述目标健康检查规则所指示的检查时机；

健康检查模块，用于当达到所述目标健康检查规则所指示的所述检查时机时，根据所述健康检查规则所指示的检查方式，对所述目标应用进程进行健康检查；

处理模块，用于当所述健康检查结果指示所述目标应用进程存在异常时，根据所述目标健康检查规则所指示的异常处理方式对所述目标应用进程进行处理。

第三方面，提供了一种服务器，所述服务器包括处理器和存储器；所述存储器存储有至少一条指令，所述至少一条指令用于被所述处理器执行以实现如第一方面所述的健康检查方法。

第四方面，提供了一种计算机可读存储介质，所述存储介质存储有至少一条指令，所述至少一条指令用于被处理器执行以实现如第一方面所述的健康检查方法。

本申请实施例中，应用服务器接收到管理服务器下发的健康检查规则后，根据健康检查规则中指示的检查时机，采用健康检查规则指示的检查方式对应用进程进行健康检查，并在健康检查结果指示存储在异常时，根据健康检查规则指示的异常处理方式，对目标应用进程进行处理；应用服务器基于健康检查规则自动对运行的应用进程进行可用性检查，并能够及时对不可用的应用进程进行处理，从而提高PaaS平台中各应用进程所提供服务的可用性。

附图说明

图1是本申请一个实施例提供的PaaS平台的架构图；

图2是PaaS平台中应用部署过程的实施示意图；

图3是应用服务器中Agent的结构示意图；

图4示出了本申请一个示例性实施例示出的健康检查方法的流程图；

图5示出了本申请另一个示例性实施例示出的健康检查方法的流程图；

图6示出了本申请另一个示例性实施例示出的健康检查方法的流程图；

图7示出了本申请一个实施例提供的健康检查装置的结构框图；

图8示出了本申请一个实施例提供的服务器的结构示意图。

具体实施方式

为使本发明的目的、技术方案和优点更加清楚，下面将结合附图对本发明实施方式作进一步地详细描述。

在本文中提及的“多个”是指两个或两个以上。“和/或”，描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。字符“/”一般表示前后关联对象是一种“或”的关系。

请参考图1，其示出了本申请一个实施例提供的PaaS平台的架构图。该PaaS平台包括若干个机房10，各个机房10设置在不同地理区域，且每个机房10中包含应用服务器11、管理服务器12、注册服务器13和存储服务器14。

在一种可能的配置方式中，每个机房中设置有两台管理服务器12、三台注册服务器13以及三台存储服务器14。本申请实施例并不对机房中各种服务器的配置数量进行限定。

应用服务器11是运行有应用进程的服务器。其中，不同的应用进程用于提供不同的服务，且应用进程直接运行在应用服务器11的操作系统上，或，应用进程运行在应用服务器11内部的容器中，以便进行资源(包括硬件资源和网络资源)和访问权限隔离，减少应用进程间的相互影响。

为了实现对应用进程的管理，本申请实施例中，应用服务器11中设置有代理(Agent)，该Agent即用于对运行的各个应用进程进行管理。可选的，该Agent为应用服务器11中的独立进程，用于控制应用进程的启动和停止，并对应用进程健康检查，从而保证应用进程所提供服务的可用性。本申请各个实施例提供的健康检查方法即由应用服务器(Agent)执行。

管理服务器12用于管理机房中各台服务器。可选的，管理服务器12负责应用部署、系统管理、消息队列管理、数据库管理、告警服务、搜索管理、分布式系统可靠协调管理等等。

在一种可能的实施方式中，消息队列管理包括RabbitMQ管理，数据库管理包括Redis和MongoDB管理，搜索管理包括ElasticSearch管理，分布式系统可靠协调管理包括Zookeeper管理。

为了保证管理的一致性，如图1所示，不同机房中的管理服务器12之间进行双向同步，并保持完全对等。比如，当机房A中管理服务器12的管理配置信息发生变更时，机房A中的管理服务器12即与机房B中的管理服务器12进行一次同步，以便机房B中的管理服务器12更新自身的管理配置信息。

注册服务器13是用于为应用进程注册服务端口的服务器，后续终端即通过该服务端口访问相应的应用进程，从而获取应用提供的相应服务。可选的，注册服务器13为全局命名(Global Naming Services，GNS)服务器，且注册的服务端口为传输控制协议(Transmission Control Protocol，TCP)端口。

为了保证同一应用进程在不同机房中命名注册的一致性，如图1所示，不同机房中的注册服务器13之间进行双向同步，并保持完全对等。比如，当机房A的注册服务器13为新增应用进程注册了服务端口后，该注册服务器13即与机房B中的注册服务器13进行一次同步，确保新增应用进程在机房B中的注册服务器13完成注册，并注册相同的服务端口。

存储服务器14是用于进行数据存储的服务器，可选的，该存储服务器14是分布式环境下高可用的键值(key-value)存储服务器，比如，存储服务器14为ETCD服务器或MySQL服务器。可选的，存储服务器14与注册服务器13相连，用于存储并维护应用进程与服务端口之间的对应关系；可选的，存储服务器14与管理服务器12相连，用于存储并维护不同应用进程对应的应用信息。

在一种可能的应用场景下，如图2所示，当需要部署新的应用进程时，管理员登陆管理服务器12后，通过管理服务器12向应用服务器11下发应用部署指令，管理服务器12根据该指令部署应用进程，并通过注册服务器13为应用进程注册服务端口。完成应用进程部署后，管理服务器12中的Agent启动应用进程，并在完成启动后，对应用进程进行健康检查，从而确保应用进程的可用性。并且，管理服务器12和注册服务器13通过数据更新的方式，分别将新增应用进程的应用信息及其服务端口更新至存储服务器14中，并与其它机房中的管理服务器12以及注册服务器13进行双向同步。

可选的，管理服务器12下发应用部署指令中包含应用规格、部署信息、环境变量、应用配置等信息。其中，应用规格包括中央处理(Central Procession Unit，CPU)规格、内存规格、存储容量规格以及网络上下行带宽规格中的至少一种；部署信息包括分配应用服务器标识、配置实例数量、文件目录、日志目录、部署脚本和回滚脚本中的至少一种；环境变量包括Java堆内存参数、垃圾回收(Garbage Collection，GC)参数、域名系统(Domain NameSystem，DNS)服务器信息、DNS生存周期(Time-To-Live，TTL)中的至少一种；应用配置包括应用进程标识、配置版本号等等。

可选的，应用服务器11中的Agent采用插件管理模式，利用插件实现对应用进程的管理，该Agent中包含若干实现不同功能的插件以及统一的插件管理模块，并支持插件的动态安装和卸载。

如图3所示，Agent中包括消息队列插件、数据库插件、应用部署插件、日志查看插件和健康检查插件。在实现插件动态安装时，插件通过管理服务器12调用应用程序编程接口(Application Programming Interface，API)进行插件注册，完成注册后，Agent的插件管理模块通过下载、编译、加载、校验等一系列操作，完成插件安装。当接收到管理服务器12下发的指令时，Agent中的插件管理模块即将指令分发至相应的插件来执行。比如，当接收到应用部署指令时，插件管理单元即将指令分发至应用部署插件，由应用部署插件完成应用部署；在应用完成部署并启动后，插件管理模块通过健康检查插件对应用进程进行健康检查，保证应用进程的可用性。

为了保证Agent的可靠性，避免因Agent宕机导致无法服务的问题，可选的，Agent在应用服务器11启动后，启动自检程序，从而通过自检程序定期检查Agent是否启动，并在检测到未启动的情况下实现重启，避免宕机。

可选的，如图3所示，Agent中还包括升级管理模块，用于根据管理服务器12下发的升级指令，完成Agent自升级。为了保证升级安全性，Agent接收到升级指令后，对拉取到的升级包进行合法性检测，并在检测到升级包合法时，对当前Agent程序进行备份后进行升级。若自检程序检测到升级失败，则使用备份对Agent进行恢复重启。

出于安全性考虑，管理服务器12向应用服务器11发送的指令使用私钥加密，应用服务器11接收到指令后，使用相应的公钥对指令进行解密，并在解密成功后执行指令并返回执行结果。可选的，针对不同类型的指令，管理服务器12加密时使用的私钥不同，相应的，应用服务器11进行解密时使用的公钥不同。其中，对于Agent操作指令，管理服务器12使用第一私钥对其进行加密，应用服务器11使用第一公钥对其进行解密，第一私钥和第一公钥分别存储在管理服务器12和应用服务器11本地；对于Agent升级指令，管理服务器12使用第二私钥对其进行加密，应用服务器11使用第二公钥对其进行解密，由于Agent操作指令会影响到Agent运行，因此，第二私钥由管理员保管，且不存储在管理服务器12中，而第二公钥则存储在应用服务器11本地。

需要说明的是，每个机房还可以包含其它必要组件，比如用于实现服务发现、请求分流以及负载均衡的接入网关，本申请实施例并不对此构成限定。

请参考图4，其示出了本申请一个示例性实施例示出的健康检查方法的流程图。本实施例以该方法应用于图1所示的应用服务器11来举例说明。该方法包括：

步骤401，接收管理服务器下发的目标健康检查规则，不同的健康检查规则对应不同的应用进程。

可选的，健康检查规则由管理人员预先配置，并在登陆管理服务器后，通过管理服务器下发给应用服务器。其中，不同的健康检查规则对应不同的应用进程，而不同的应用进程可以对应相同的健康检查规则。

可选的，该健康检查规则用于指示检查时机、检查方式以及存在异常时的异常处理方式。

为了对不用机房中的目标应用进程进行健康检查，管理服务器接收到目标健康检查规则后，将目标健康检查规则下发至目标应用进程对应的各台应用服务器(位于不同机房中)。可选的，不同机房中的管理服务器之间通过双向同步的方式获取目标健康检查规则，从而将健康检查规则下发至所在机房的应用服务器中。

针对下发目标健康检查规则的下发时机，在一种可能的实施方式中，管理服务器向应用服务器发送应用部署指令(指示应用服务器部署目标应用进程)之前或之后，将目标健康检查规则下发至应用服务器，以便应用服务器对其进行存储。

步骤402，检测是否达到目标健康检查规则所指示的检查时机。

可选的，检查时机的检测由应用服务器中的Agent执行。

可选的，该检查时机包括首次检查时机，和/或，定期检查时机，其中，首次检查时机为目标应用进程启动后，首次进行健康检查的时机；定期检查时机为目标应用进行完成首次健康检查后，后续进行健康检查的时机。

可选的，该检查时机可以是预设检查周期，也可以是预设的若干检查时间点。比如，当检查时机为预设检查周期时，该预设检查周期可以为60s，当检查时机为预设检查时间点时，该预设检查时间点可以为每天的0点和12点。

步骤403，当达到目标健康检查规则所指示的检查时机时，根据健康检查规则所指示的检查方式，对目标应用进程进行健康检查。

由于不同应用进程所需要检查的内容不同，因此管理人员配置的健康检查规则中包含的检查方式，相应的，应用服务器中的Agent即根据该检查方式对目标应用进程进行健康检查，确保健康检查结果的准确性。

在一种可能的实施方式中，该检查方式中包含健康检查类型以及健康检查预期结果。若根据健康检查类型进行健康检查后所得到的结果与健康检查预期结果一致，则确定该目标应用进程正常；若根据健康检查类型进行健康检查后所得到的结果与健康检查预期结果不一致，则确定该目标应用进程存在异常。

步骤404，若健康检查结果指示目标应用进程存在异常，则根据目标健康检查规则所指示的异常处理方式对目标应用进程进行处理。

由于不同应用进程对应的异常处理方式可能不同，因此管理人员配置的健康检查规则中还包含异常处理方式，相应的，应用服务器中的Agent即根据该异常处理方式对目标应用进程进行处理。

可选的，异常处理方式包括重启应用进程或关闭进程。

可选的，应用服务器的还设置有告警机制，若根据异常处理方式对目标应用进程进行处理后，目标应用进程仍存在异常，应用服务器的Agent即进行告警，以便管理员对目标应用进程进行手动处理。

综上所述，本实施例中，应用服务器接收到管理服务器下发的健康检查规则后，根据健康检查规则中指示的检查时机，采用健康检查规则指示的检查方式对应用进程进行健康检查，并在健康检查结果指示存储在异常时，根据健康检查规则指示的异常处理方式，对目标应用进程进行处理；应用服务器基于健康检查规则自动对运行的应用进程进行可用性检查，并能够及时对不可用的应用进程进行处理，从而提高PaaS平台中各应用进程所提供服务的可用性。

在一种可能的应用场景下，当需要在应用服务器中新增应用进程时，管理服务器向应用服务器发送应用部署指令后，向应用服务器下发目标健康检查规则，目标应用进程完成部署后，应用服务器即基于目标健康检查规则对目标应用进程进行健康检查，确保目标应用进程所提供服务的可用性，下面采用示意性实施例对不同时段内健康检查的具体方式进行说明。

请参考图5，其示出了本申请另一个示例性实施例示出的健康检查方法的流程图。本实施例以该方法应用于图1所示的应用服务器11来举例说明。该方法包括：

步骤501，接收管理服务器下发的应用部署指令，该应用部署指令用于指示应用服务器部署目标应用进程。

示意性的，如图2所示，当需要在应用服务器12中部署目标应用进程时，管理服务器即向应用服务器11下发应用部署指令。相应的，应用服务器接收该应用部署指令，进而根据该应用部署指令中包含的应用部署信息，从配置中心中下载相应的配置，从而根据下载的配置完成应用进程部署。

步骤502，接收管理服务器下发的目标健康检查规则，不同的健康检查规则对应不同的应用进程。

为了使应用服务器能够对部署的目标应用进程进行健康检查，管理服务器下发应用部署指令后，向应用服务器下发目标健康检查规则。本步骤的实施方式可参见步骤401，本实施例在此不再赘。

可选的，为了保证规则下发的安全性，管理服务器使用本地私钥对目标健康检查规则进行加密，应用服务器接收到目标健康检查规则，即使用本地公钥对其进行解密，若解密成功，则确定目标健康检查规则安全，并将其进行存储；若解密失败，则确定目标健康检查规则存在风险，并对其进行丢弃。

可选的，该健康检查规则中包含预设配置项及其对应的值，且采用预设格式进行存储。比如，该健康检查规则采用json存储，本申请实施例并对健康检查规则的具体存储方式进行限定。

在一种可能的实施方式中，健康检查规则中包含的预设配置项如表一所示。

表一

配置项	值
		健康检查类型	TCP检查或HTTP检查
端口号	TCP检查时填写
		进程路径	HTTP检查时填写
预设状态码	HTTP检查时填写
		启动延迟	应用进程启动后开始健康检查的延迟时间
检查周期	定期健康检查的周期
		超时时间	健康检查的超时时间
重试次数阈值	存在异常时重试的最大次数
		自动重启	是或否
告警联系人	告警信息接收人的信息
		健康检查开启状态	是或否

获取到目标健康检查规则后，应用服务器的Agent即基于该规则确定健康检查时机，下述步骤503至504即对首次健康检查的检查时机进行说明，步骤506至506即对非首次健康检查的检查时机进行说明。

步骤503，检测目标应用进程的启动时长是否达到启动延迟。

对于新部署的目标应用进程，由于目标应用进程完全启动需要花费一定时长，若在目标应用进程启动后立即执行健康检查，可能会造成健康检查结果不准确，因此，为了提高健康检查结果的准确性，目标健康检查规则中包含启动延迟。相应的，应用服务器的Agent对目标应用进程进行首次启动后，检测目标应用进程的启动时长是否达到了启动延迟。若达到，Agent即执行步骤504；若未达到，Agent则不会进行健康检查，直至启动时长达到该启动延迟。

其中，该启动延迟有管理员设置，且为不同应用进程设置的启动延迟可以相同，也可以不同。

比如，目标健康检查规则中包含的启动延迟为10s。

步骤504，若目标应用进程的启动时长达到启动延迟，则确定达到检查时机。

当启动时长达到了启动延迟，应用服务器的Agent即确定目标应用进程已完全启动，已达到了检查时机，并执行下述步骤507。

步骤505，检测与上一次健康检查的时间间隔是否达到检查周期。

对于已完全启动的应用进程，其启动时长已达到启动延迟，因此Agent无需对其启动时长进行检测。

为了实现对应用进程的定期检查，在一种可能的实施方式中，目标健康检查规则中还包含检查周期，当检测到距离上一次健康检查的时间间隔达到该检查周期时，Agent确定达到检查时机；当距离上一次健康检查的时间间隔未达到该检查周期时，Agent则不会进行健康检查。比如，该检查周期为10min。

可选的，每次进行健康检查时，Agent记录健康检查时刻，并在健康检查完成后，启动定时器(该定时器的时长即为检查周期)，当达到定时器时长时，Agent即确定达到检查周期。

由于应用服务器中运行有大量应用进程，为了降低Agent对高稳定性应用进程的健康检查次数，在一种可能的实施方式中，Agent在检查周期的基础上，根据最近n次的健康检查结果对该检查周期进行调整，其中，最近n次健康检查结果中正常次数与检查周期的下调比例呈正相关关系，最近n次健康检查结果中异常次数与检查周期的上调比例呈正相关关系。

步骤506，若时间间隔达到检查周期，则确定达到检查时机。

步骤507，获取目标健康检查规则中包含的健康检查类型。

对于不同类型的应用进程，其对应的健康检查方式也不同，因此，Agent根据健康检查规则中包含的健康检查类型，确定目标应用进程对应的健康检查方式。

可选的，健康检查类型包括传输控制协议(Transmission Control Protocol，TCP)健康检查和超文本传输协议(HyperText Transfer Protocol，HTTP)健康检查。

示意性的，Agent读取目标健康检查规则中健康检查类型这一配置项对应的值，从而确定目标应用进程的健康检查类型。当读取到的值为TCP时，确定健康检查类型为TCP健康检查；当读取到的值为HTTP时，确定健康检查类型为HTTP健康检查。

本实施例仅以上述两种健康检查类型为例进行示意性说明，在其他可能的实施方式中，健康检查类型还可以包括用户数据协议(User Datagram Protocol，UDP)、HTTPS等等，本申请并不对此进行限定。

下面通过步骤508至509对TCP健康检查的具体方式进行说明，通过步骤510至512对HTTP健康检查的具体方式进行说明。

步骤508，当健康检查类型为TCP健康检查时，根据健康检查规则中包含的端口号，与目标应用进程建立TCP连接。

当健康检查类型为TCP健康检查时，为了确保终端访问目标应用进程对应的端口时，能够获取到相应的服务，对目标应用进程进行TCP健康检查时，Agent即检测目标应用进程的TCP端口是否连通。

可选的，当需要对目标应用进程进行TCP健康检查时，该目标健康检查规则中包含目标应用进程的端口号，Agent即读取该端口号，并根据该端口号，请求与目标应用进程建立TCP连接，其中，该TCP连接可以为套接字(Socket)连接。

步骤509，若TCP连接不通，或，在预设时长内未建立TCP连接，则确定目标应用进程存在TCP连接异常。

当应用进程对应的端口出现异常时，其通常表现为无法与端口建立TCP连接，或者TCP连接建立超时，因此，当接收到TCP连接失败指示，或在预设时长内TCP连接未建立完成时，Agent确定目标应用进程存在TCP连接异常。

可选的，管理员通过在目标健康检查规则中配置超时时间来指示该预设时长。比如，该预设时长可以为3s。

步骤510，当健康检查类型为HTTP健康检查时，根据目标健康检查规则中包含的进程路径，访问目标应用进程。

当健康检查类型为HTTP健康检查时，目标健康检查规则的配置项中包含目标应用进程的进程路径，为了检测目标应用进程能够提供相应的服务，Agent即根据该目标应用进程，访问目标应用进程。比如，Agent向目标应用进程发送HTTP访问请求。

步骤511，接收目标应用进程反馈的HTTP状态码。

Agent访问目标应用进程后，接收目标应用进程反馈的HTTP状态码，该HTTP状态码即用于表征目标应用进程的响应状态。

步骤512，若HTTP状态码不属于目标健康检查规则中包含的预设状态码，或，在预设时长内未接收到HTTP状态码，则确定目标应用进程存在HTTP连接异常。

在一种可能的实施方式中，管理服务器下发的目标健康检查规则中包含预设状态码，该预设状态码为目标应用进程正常运行情况下所反馈的HTTP状态码。其中，该预设状态码为若干个独立的HTTP状态码，比如预设状态码为200；或者，该预设状态码为HTTP状态码区间，比如预设状态码为200-500。

Agent接收到HTTP状态码后，即检测该HTTP状态码是否属于预设状态码，若属于，则确定目标应用进程正常；若不属于，则确定目标应用进程存在HTTP连接异常。

在另一种可能的实施方式中，目标健康检查规则中还包含预设时长(即表一中的超时时间)，当在预设时长内未接收到目标应用进程反馈的HTTP状态码时，Agent确定存在HTTP连接异常。比如，该预设时长为3s。

通过上述步骤检测到目标应用进程存在异常后，Agent进一步采用下述步骤对目标应用进程进行处理，从而尽快恢复目标应用进程所提供服务的可用性。

步骤513，检测健康检查重试次数是否达到重试次数阈值。

由于单次健康检查结果可能并非完全准确(应用进程也可能自己排除异常)，因此Agent在检测到目标应用进程存在异常后，再次对其进行健康检查，从而根据多次健康检查结果确定目标应用进程是否存在异常情况。

在一种可能的实施方式中，目标健康检查规则中还包含有重试次数阈值这一配置项，当目标应用进程存在异常时，Agent即检测当前重试次数是否达到重试次数阈值，若未达到，则执行步骤514，若已达到，则确定目标应用进程存在无法消除的异常，并执行步骤515至516。

比如，该重试次数阈值为5次。

步骤514，若健康检查重试次数未达到重试次数阈值，则重新对目标应用进程进行健康检查。

当重新健康检查后得到的检查结果指示不存在异常时，Agent即停止重试健康检查；若检查结果指示仍旧存在异常，Agent即对当前重试次数进行加一操作，并执行步骤513。其中重新健康检查的步骤参考上述步骤508至512，本实施例不再赘述。

步骤515，若健康检查重试次数达到重试次数阈值，则根据目标应用进程对应的重启脚本重启目标应用进程。

在一种可能的实施方式中，当健康检查重试次数达到重试次数阈值时，Agent读取目标健康检查规则中自动重启这一配置项对应的值，若值为是(或者1)，则读取目标应用进程对应的重启脚本，并通过运行重启脚本的方式重启该目标应用进程；若值为否(或者0)，Agent则直接进行告警。

可选的，该重启脚本是应用部署阶段由管理服务器提供，用于控制目标应用进程进行重启。

步骤516，向告警联系人发送告警信息。

为了提醒相应人员对存在异常的应用进程进行修复，使其提供的服务可用，目标健康检查规则中还包含告警联系人这一配置项。当健康检查重试次数达到重试次数阈值时，不论目标应用进程是否支持重启，Agent均启用告警机制向告警联系人发送告警信息。可选的，告警联系人这一配置项的值可以为邮箱、电话号码或即时通信账号等等，该告警信息中包含目标应用进程的进程标识以及异常描述信息。

本实施例中，通过在健康检查规则中设置启动延迟，并在应用进程的启动时长达到启动延迟后，对应用进程进行健康检查，避免因应用进程启动不完全导致健康检查结果不准确的问题，提高了健康检查结果的准确性。

另外，通过在健康检查规则中配置端口号，应用服务器实现了对应用进程进行TCP健康检查；通过在健康检查规则中配置进程路径和预设状态码，应用服务器实现了对应用进程进行HTTP健康检查，提高了应用进程健康检查的多样性。

另外，本实施例中，应用服务器通过执行重启脚本对存在异常的应用进程进行重启，并向相应的告警联系人发送告警信息，以便告警联系人尽快进行异常处理，提高了应用进程的可用性。

除了对应用进程进行TCP或HTTP健康检查外，为了避免因恶意访问造成应用进程的资源占用量过大，从而影响应用服务器上其他应用进程运行质量的问题，在图5的基础上，如图6所示，步骤508至步骤512可以被替换为如下步骤。

步骤517，获取目标应用进程的当前资源占用量。

在一种可能的实施方式中，目标健康检查规则中还包含资源占用量阈值，该资源占用量阈值包括CPU占用量阈值、存储空间占用量阈值和网络带宽占用量阈值中的至少一种。相应的，在进行健康检查时，Agent获取目标应用进程的当前资源占用量，该当前资源占用量包括当前CPU占用量、当前存储空间占用量和当前网络带宽占用量阈值中的至少一种。

比如，资源占用量阈值包括：CPU占用量阈值10％、存储空间占用量阈值1TB和网络带宽占用量阈值100Mbps。

步骤518，检测当前资源占用量是否达到资源占用量阈值。

进一步的，Agent检测当前资源占用量是否达到资源占用量阈值，若达到，则确定目标应用进程占用资源过多，可能存在恶意访问情况，执行步骤519；若未达到，则确定目标应用进程资源占用正常。

步骤519，若当前资源占用量达到资源占用量阈值，则确定目标应用进程存在资源占用异常。

可选的，当目标应用进程存在资源占用异常时，Agent向告警联系人发送相应的告警信息，提示存在恶意访问的风险。

需要说明的是，上述步骤517至519也可以与步骤508至512同时执行，本申请实施例在此不再赘述。

请参考图7，其示出了本申请一个实施例提供的健康检查装置的结构框图。该健康检查装置可以通过软件、硬件或者两者的结合实现成为图1中应用服务器11的全部或一部分。该装置包括：规则接收模块710、时机检测模块720、健康检查模块730和处理模块740。

规则接收模块710，用于接收管理服务器下发的目标健康检查规则，不同的健康检查规则对应不同的应用进程；

时机检测模块720，用于检测是否达到所述目标健康检查规则所指示的检查时机；

健康检查模块730，用于当达到所述目标健康检查规则所指示的所述检查时机时，根据所述健康检查规则所指示的检查方式，对所述目标应用进程进行健康检查；

处理模块740，用于当所述健康检查结果指示所述目标应用进程存在异常时，根据所述目标健康检查规则所指示的异常处理方式对所述目标应用进程进行处理。

可选的，所述目标健康检查规则中包含启动延迟，且不同的健康检查规则中包含不同的所述启动延迟；

所述时机检测模块720，包括：

第一检测单元，用于当接收到所述目标应用进程对应的应用部署指令时，检测所述目标应用进程的启动时长是否达到所述启动延迟；

第一确定单元，用于当所述目标应用进程的启动时长达到所述启动延迟时，确定达到所述检查时机。

可选的，所述目标健康检查规则中还包含检查周期；

所述时机检测模块720，还包括：

第二检测单元，用于检测与上一次健康检查的时间间隔是否达到所述检查周期；

第一确定单元，用于当所述时间间隔达到所述检查周期时，确定达到所述检查时机。

可选的，所述健康检查模块730，包括：

第一获取单元，用于获取所述目标健康检查规则中包含的健康检查类型，所述健康检查类型包括传输控制协议TCP健康检查和超文本传输协议HTTP健康检查；

第一健康检查单元，用于当所述健康检查类型为所述TCP健康检查时，根据所述目标健康检查规则中包含的端口号，与所述目标应用进程建立TCP连接；若所述TCP连接不通，或，在预设时长内未建立所述TCP连接，则确定所述目标应用进程存在TCP连接异常；

第二健康检查单元，用于当所述目标健康检查类型为所述HTTP健康检查时，根据所述目标健康检查规则中包含的进程路径，访问所述目标应用进程；接收所述目标应用进程反馈的HTTP状态码；若所述HTTP状态码不属于所述目标健康检查规则中包含的预设状态码，或，在预设时长内未接收到所述HTTP状态码，则确定所述目标应用进程存在HTTP连接异常。

可选的，所述健康检查规则中还包含资源占用量阈值，所述资源占用量阈值包括CPU占用量阈值、存储空间占用量阈值和网络带宽占用量阈值中的至少一种；

所述健康检查模块730，还包括：

第二获取单元，用于获取所述目标应用进程的当前资源占用量；

第三检测单元，用于检测所述当前资源占用量是否达到所述资源占用量阈值；

第三确定单元，用于当所述当前资源占用量达到所述资源占用量阈值时，确定所述目标应用进程存在资源占用异常。

可选的，所述目标健康检查规则中包含重试次数阈值、进程重启标识位和告警联系人，所述进程重启标识位用于指示是否重启所述目标应用进程；

所述处理模块740，包括：

重试次数检测单元，用于检测健康检查重试次数是否达到所述重试次数阈值；

重试单元，用于当所述健康检查重试次数未达到所述重试次数阈值时，重新对所述目标应用进程进行健康检查；

重启单元，用于当所述健康检查重试次数达到所述重试次数阈值时，根据所述目标应用进程对应的重启脚本重启所述目标应用进程；向所述告警联系人发送告警信息。

综上所述，本实施例中，应用服务器接收到管理服务器下发的健康检查规则后，根据健康检查规则中指示的检查时机，采用健康检查规则指示的检查方式对应用进程进行健康检查，并在健康检查结果指示存储在异常时，根据健康检查规则指示的异常处理方式，对目标应用进程进行处理；应用服务器基于健康检查规则自动对运行的应用进程进行可用性检查，并能够及时对不可用的应用进程进行处理，从而提高PaaS平台中各应用进程所提供服务的可用性。

请参考图8，其示出了本申请一个实施例提供的服务器的结构示意图。该服务器用于实施上述实施例提供的健康检查方法。具体来讲：

所述服务器800包括中央处理单元(CPU)801、包括随机存取存储器(RAM)802和只读存储器(ROM)803的系统存储器804，以及连接系统存储器804和中央处理单元801的系统总线805。所述服务器800还包括帮助计算机内的各个器件之间传输信息的基本输入/输出系统(I/O系统)806，和用于存储操作系统813、应用程序814和其他程序模块815的大容量存储设备807。

所述基本输入/输出系统806包括有用于显示信息的显示器808和用于用户输入信息的诸如鼠标、键盘之类的输入设备809。其中所述显示器808和输入设备809都通过连接到系统总线805的输入输出控制器810连接到中央处理单元801。所述基本输入/输出系统806还可以包括输入输出控制器810以用于接收和处理来自键盘、鼠标、或电子触控笔等多个其他设备的输入。类似地，输入输出控制器810还提供输出到显示屏、打印机或其他类型的输出设备。

所述大容量存储设备807通过连接到系统总线805的大容量存储控制器(未示出)连接到中央处理单元801。所述大容量存储设备807及其相关联的计算机可读介质为服务器800提供非易失性存储。也就是说，所述大容量存储设备807可以包括诸如硬盘或者CD-ROM驱动器之类的计算机可读介质(未示出)。

不失一般性，所述计算机可读介质可以包括计算机存储介质和通信介质。计算机存储介质包括以用于存储诸如计算机可读指令、数据结构、程序模块或其他数据等信息的任何方法或技术实现的易失性和非易失性、可移动和不可移动介质。计算机存储介质包括RAM、ROM、EPROM、EEPROM、闪存或其他固态存储其技术，CD-ROM、DVD或其他光学存储、磁带盒、磁带、磁盘存储或其他磁性存储设备。当然，本领域技术人员可知所述计算机存储介质不局限于上述几种。上述的系统存储器804和大容量存储设备807可以统称为存储器。

根据本发明的各种实施例，所述服务器800还可以通过诸如因特网等网络连接到网络上的远程计算机运行。也即服务器800可以通过连接在所述系统总线805上的网络接口单元811连接到网络812，或者说，也可以使用网络接口单元811来连接到其他类型的网络或远程计算机系统。

所述存储器中存储有至少一条指令、至少一段程序、代码集或指令集，所述至少一条指令、至少一段程序、代码集或指令集经配置以由一个或者一个以上处理器执行，以实现上述实施例中各个步骤的功能。

本申请实施例还提供了一种计算机可读介质，该计算机可读介质存储有至少一条指令，所述至少一条指令由所述处理器加载并执行以实现如上各个实施例所述的健康检查方法。

本申请实施例还提供了一种计算机程序产品，该计算机程序产品存储有至少一条指令，所述至少一条指令由所述处理器加载并执行以实现如上各个实施例所述的健康检查方法。

本领域技术人员应该可以意识到，在上述一个或多个示例中，本申请实施例所描述的功能可以用硬件、软件、固件或它们的任意组合来实现。当使用软件实现时，可以将这些功能存储在计算机可读介质中或者作为计算机可读介质上的一个或多个指令或代码进行传输。计算机可读介质包括计算机存储介质和通信介质，其中通信介质包括便于从一个地方向另一个地方传送计算机程序的任何介质。存储介质可以是通用或专用计算机能够存取的任何可用介质。

以上所述仅为本申请的较佳实施例，并不用以限制本申请，凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

Claims (8)

1.一种PaaS平台中应用进程的健康检查方法，其特征在于，所述方法用于PaaS平台中的应用服务器，所述应用服务器运行有多个应用进程，所述方法包括：

接收管理服务器下发的目标健康检查规则，不同的健康检查规则对应不同的应用进程；

基于所述目标健康检查规则中包含的启动延迟和检查周期，当接收到目标应用进程对应的应用部署指令时，检测所述目标应用进程的启动时长是否达到所述启动延迟；

若所述目标应用进程的启动时长达到所述启动延迟，则确定达到检查时机，其中，不同的健康检查规则中包含不同的所述启动延迟，所述检查周期基于最近n次健康检查结果调整得到，所述最近n次健康检查结果中的异常次数与所述检查周期的上调比例呈正相关关系，或所述最近n次健康检查结果中的正常次数与所述检查周期的下调比例呈正相关关系，n为正整数；

当达到所述目标健康检查规则所指示的所述检查时机时，根据所述健康检查规则所指示的检查方式，对所述目标应用进程进行健康检查，所述健康检查用于检查终端能否访问所述目标应用进程；

若所述健康检查结果指示所述目标应用进程存在异常，则根据所述目标健康检查规则所指示的异常处理方式对所述目标应用进程进行处理。

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

检测与上一次健康检查的时间间隔是否达到所述检查周期；

若所述时间间隔达到所述检查周期，则确定达到所述检查时机。

3.根据权利要求1或2所述的方法，其特征在于，所述根据所述目标健康检查规则所指示的检查方式，对所述目标应用进程进行健康检查，包括：

获取所述目标健康检查规则中包含的健康检查类型，所述健康检查类型包括传输控制协议TCP健康检查和超文本传输协议HTTP健康检查；

当所述健康检查类型为所述TCP健康检查时，根据所述健康检查规则中包含的端口号，与所述目标应用进程建立TCP连接；若所述TCP连接不通，或，在预设时长内未建立所述TCP连接，则确定所述目标应用进程存在TCP连接异常；

当所述健康检查类型为所述HTTP健康检查时，根据所述健康检查规则中包含的进程路径，访问所述目标应用进程；接收所述目标应用进程反馈的HTTP状态码；若所述HTTP状态码不属于所述健康检查规则中包含的预设状态码，或，在预设时长内未接收到所述HTTP状态码，则确定所述目标应用进程存在HTTP连接异常。

4.根据权利要求3所述的方法，其特征在于，所述目标健康检查规则中还包含资源占用量阈值，所述资源占用量阈值包括中央处理器CPU占用量阈值、存储空间占用量阈值和网络带宽占用量阈值中的至少一种；

所述根据所述目标健康检查规则所指示的检查方式，对所述目标应用进程进行健康检查，还包括：

获取所述目标应用进程的当前资源占用量；

检测所述当前资源占用量是否达到所述资源占用量阈值；

若所述当前资源占用量达到所述资源占用量阈值，则确定所述目标应用进程存在资源占用异常。

5.根据权利要求1或2所述的方法，其特征在于，所述健康检查规则中包含重试次数阈值、进程重启标识位和告警联系人，所述进程重启标识位用于指示是否重启所述目标应用进程；

所述根据所述目标健康检查规则所指示的异常处理方式对所述目标应用进程进行处理，包括：

检测健康检查重试次数是否达到所述重试次数阈值；

若所述健康检查重试次数未达到所述重试次数阈值，则重新对所述目标应用进程进行健康检查；

若所述健康检查重试次数达到所述重试次数阈值，则根据所述目标应用进程对应的重启脚本重启所述目标应用进程；向所述告警联系人发送告警信息。

6.一种PaaS平台中应用进程的健康检查装置，其特征在于，所述装置用于PaaS平台中的应用服务器，所述应用服务器运行有多个应用进程，所述装置包括：

规则接收模块，用于接收管理服务器下发的目标健康检查规则，不同的健康检查规则对应不同的应用进程；

时机检测模块，用于基于所述目标健康检查规则中包含的启动延迟和检查周期，当接收到目标应用进程对应的应用部署指令时，检测所述目标应用进程的启动时长是否达到所述启动延迟；若所述目标应用进程的启动时长达到所述启动延迟，则确定达到检查时机，其中，不同的健康检查规则中包含不同的所述启动延迟，所述检查周期基于最近n次健康检查结果调整得到，所述最近n次健康检查结果中的异常次数与所述检查周期的上调比例呈正相关关系，或所述最近n次健康检查结果中的正常次数与所述检查周期的下调比例呈正相关关系，n为正整数；

健康检查模块，用于当达到所述目标健康检查规则所指示的所述检查时机时，根据所述健康检查规则所指示的检查方式，对所述目标应用进程进行健康检查，所述健康检查用于检查终端能否访问所述目标应用进程；

处理模块，用于当所述健康检查结果指示所述目标应用进程存在异常时，根据所述目标健康检查规则所指示的异常处理方式对所述目标应用进程进行处理。

7.一种服务器，其特征在于，所述服务器包括处理器和存储器；所述存储器存储有至少一条指令，所述至少一条指令用于被所述处理器执行以实现如权利要求1至5任一所述的PaaS平台中应用进程的健康检查方法。

8.一种计算机可读存储介质，其特征在于，所述存储介质存储有至少一条指令，所述至少一条指令用于被处理器执行以实现如权利要求1至5任一所述的PaaS平台中应用进程的健康检查方法。

Images