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示出了本申请另一个示例性实施例示出的应用部署方法的流程图；

图6a和图6b是应用部署到应用服务过程的实施示意图；

图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为全局命名(globalnamingservices，gns)服务器，且注册的服务端口为传输控制协议(transmissioncontrolprotocol，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下发应用部署指令中包含应用规格、部署信息、环境变量、应用配置等信息。其中，应用规格包括中央处理(centralprocessionunit，cpu)规格、内存规格、存储容量规格以及网络上下行带宽规格中的至少一种；部署信息包括分配应用服务器标识、配置实例数量、文件目录、日志目录、部署脚本和回滚脚本中的至少一种；环境变量包括java堆内存参数、垃圾回收(garbagecollection，gc)参数、域名系统(domainnamesystem，dns)服务器信息、dns生存周期(time-to-live，ttl)中的至少一种；应用配置包括应用进程标识、配置版本号等等。

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

如图3所示，agent中包括消息队列插件、数据库插件、应用部署插件、日志查看插件和健康检查插件。在实现插件动态安装时，插件通过管理服务器12调用应用程序编程接口(applicationprogramminginterface，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中的应用部署插件执行。

完成目标应用部署后，应用服务器即启动目标应用。

步骤403，根据目标应用对应的目标健康检查规则，对目标应用进行健康检查，不同的应用对应不同的健康检查规则。

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

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

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

可选的，该健康检查规则用于指示检查时机、检查方式以及存在异常时的异常处理方式。相应的，应用服务器即根据目标健康检查规则指示的检查时机，采用目标健康检查规则指示的检查方法对目标应用进行检查。其中，对目标应用进行健康检查的步骤可以由agent中的健康检查插件执行。

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

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

当健康检查结果指示目标应用正常时，应用服务器即执行步骤404；当健康检查结果指示目标应用异常时，应用服务器即根据目标健康检查规则所指示的异常处理方式，对目标应用进行处理。

步骤404，若健康检查结果指示目标应用正常，则通过注册中心注册目标应用，注册中心用于提供注册和发现服务。

当健康检查结果指示目标应用正常时，表明目标应用所提供的服务可用，此时，应用服务器则注册中心注册目标应用。注册成功后，后续接收到客户端发送的服务调用请求时，注册中心即可通过服务发现功能，调用目标应用提供相应服务。

而对于存在异常的目标应用，应用服务器则不会对其进行注册，避免注册异常应用导致服务调用失败，影响应用可用性的问题。

综上所述，本申请实施例中，当接收到管理服务器下发的应用部署指令，并根据应用部署指令部署目标应用后，应用服务器首先根据目标健康检查规则对目标应用进行健康检查，并在目标应用正常时，通过注册中心注册所述目标应用；采用上述先健康检查后注册机制，应用服务器能够保证注册应用的可用性，从而避免注册异常应用导致服务调用失败的问题，提高了paas平台中应用的可用性。

在一种可能的实施方式中，paas平台的注册中心设置有不同类型的注册服务器，且不同类型的注册服务器中注册有提供不同类型服务的应用。下面采用示意性的实施例对应用注册的具体过程进行说明。

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

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

步骤502，根据应用部署指令部署目标应用。

步骤501至502的实施方式与步骤401至402相似，本实施例在此不再赘述。

步骤503，检查目标应用的启动时长是否达到目标健康检查规则所指示的启动延迟。

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

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

表一

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

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

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

在其他可能的实施方式中，当完成首次健康检查后，应用服务器根据目标健康检查规则中的检查周期，对目标应用进行定期检查。其中，该检查周期可以是固定周期，也可以是若干检查时间点。比如，当采用固定周期检查时，该检查周期可以为60s，当固定时间点检查时，该检查周期可以为每天的0点和12点。

步骤504，当目标应用的启动时长达到启动延迟时，根据目标健康检查规则所指示的检查方式，对目标应用进行健康检查。

针对提供不同类型服务的应用，应用服务器对其进行健康检查的方式可能不同，因此，对目标应用进行健康检查前，应用服务器首先需要确定目标应用对应的健康检查类型，进而根据健康检查类型确定采用何种健康检查方式。在一种可能的实施方式中，本步骤可以包括如下步骤。

一、获取目标健康检查规则中包含的健康检查类型

可选的，健康检查类型包括传输控制协议(transmissioncontrolprotocol，tcp)健康检查和超文本传输协议(hypertexttransferprotocol，http)健康检查。

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

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

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

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

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

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

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

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

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

agent访问目标应用后，接收目标应用反馈的http状态码，该http状态码即用于表征目标应用的响应状态。

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

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

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

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

步骤505，若健康检查结果指示目标应用正常，则根据应用部署指令中包含的服务类型，确定目标应用对应的目标注册服务器，服务类型为目标应用所提供服务的类型。

本实施例中，针对提供不同类型服务的应用，注册中心中设置有不同类型注册服务器，当目标应用通过健康检查，并需要进行注册时，agent首先根据应用部署指令中包含的服务类型，确定目标应用对应的目标注册服务器。

在一种可能的实施方式中，当服务类型为http服务时，应用服务器确定目标应用对应的目标注册服务器为全局命名服务(globalnamingservice)gns服务器；当服务类型为dubbo服务时，确定目标注册服务器为zookeeper服务器(zookeeper服务器是dubbo服务推荐的命名注册服务器)。

在其他可能的实施方式中，注册中心中还可以包含consul服务器或其他自研的命名注册服务器，本申请并不对注册中心包含的具体服务器类型进行限定。

步骤506，通过目标注册服务器注册目标应用。

确定出目标注册服务器后，agent通过目标注册服务器注册目标应用。

在一种可能的实施方式中，agent向目标注册服务器发送包含目标应用对应应用包名、ip地址以及端口号的注册请求，以便目标注册服务器根据注册请求中的内容完成应用注册。

通过上述步骤501至506，目标应用完成整个注册过程，由于目标应用在注册前即完成了健康检查，因此保证了完成注册的目标应用可用。后续客户端请求调用目标应用提供的服务时，即执行下述步骤。

步骤507，接收接入网关发送的服务调用请求，服务调用请求是接入网关根据客户端请求服务的目标服务类型，从目标服务类型对应的注册服务器处发现服务后发送的。

在一种可能的实施方式中，客户端需要调用相应服务时，即向paas平台的接入网关发送服务调用请求，接入网关接收到服务调用请求后，即根据请求调用服务的服务类型，从相应的注册服务器处发现提供服务的应用。

可选的，客户端发送的服务调用请求中包含请求服务的目标服务类型以及应用包名，而接入网关中存储有服务类型与注册服务器之间的对应关系，接入网关即基于该对应关系，确定目标服务类型对应的注册服务器，并根据应用包名从该注册服务器处获取提供应用的ip地址和端口号，从而根据ip地址和端口号将服务调用请求转发至应用服务器内相应的应用。

步骤508，调用相应的应用响应服务请求。

应用服务器即调用相应的应用响应服务请求，为客户端提供相应的服务。

在一个示意性的例子中，如图6a所示，从应用部署到应用服务包括如下步骤：1、管理服务器向应用服务器发送应用部署指令；2、应用服务器的agent根据应用部署指令部署并启动应用；3、agent对应用进行健康检查；4、当应用通过健康检查时，agent根据应用对应的服务类型，通过注册中心中的注册服务器完成注册；5、客户端向接入网关发送服务调用请求；6、接入网关从注册中心发现服务；7、接入网关将服务调用请求转发至应用服务器，由应用服务器中相应的应用提供服务。

在其他可能的实施方式中，如图6b所示，在步骤5中，客户端可以通过内嵌sdk直接从注册中心处发现服务，而在步骤6中，客户端则直接从应用服务器处调用服务，无需借助接入网关。

本实施例中，应用注册统一由应用服务器的agent执行，减小注册过程对应用代码的侵入；同时，通过为不同服务类型的应用设置不同的注册服务器，实现注册服务分离，并提高后续服务发现的速度，提高服务的响应速率。

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

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

可选的，上述步骤504之后，当健康检查结果指示目标应用异常时，还包括如下步骤。

一、若健康检查结果指示目标应用异常，agent检测健康检查重试次数是否达到重试次数阈值。

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

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

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

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

当重新健康检查后得到的检查结果指示不存在异常时，agent即停止重试健康检查；若检查结果指示仍旧存在异常，agent即对当前重试次数进行加一操作，并执行步骤一。

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

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

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

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

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

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

第一接收模块710，用于接收管理服务器下发的应用部署指令，所述应用部署指令用于指示所述应用服务器部署目标应用；

部署模块720，用于根据所述应用部署指令部署所述目标应用；

健康检查模块730，根据所述目标应用对应的目标健康检查规则，对所述目标应用进行健康检查，不同的应用对应不同的健康检查规则；

注册模块740，用于当健康检查结果指示所述目标应用正常时，通过注册中心注册所述目标应用，所述注册中心用于提供注册和发现服务。

可选的，所述注册中心包含至少两种类型的注册服务器，不同类型的所述注册服务器对应提供不同类型服务的应用；

所述注册模块740，包括：

确定单元，用于根据所述应用部署指令中包含的服务类型，确定所述目标应用对应的目标注册服务器，所述服务类型为所述目标应用所提供服务的类型；

注册单元，用于通过所述目标注册服务器注册所述目标应用。

可选的，所述确定单元，用于：

当所述服务类型为超文本传输协议http服务时，确定所述目标注册服务器为全局命名服务gns服务器；

当所述服务类型为dubbo服务时，确定所述目标注册服务器为zookeeper服务器。

可选的，所述装置还包括：

第二接收模块，用于接收接入网关发送的服务调用请求，所述服务调用请求是所述接入网关根据客户端请求服务的目标服务类型，从所述目标服务类型对应的注册服务器处发现服务后发送的；

响应模块，用于调用相应的应用响应所述服务请求。

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

所述健康检查模块730，用于：

当达到所述目标应用的启动时长达到所述启动延迟时，根据所述健康检查规则所指示的检查方式，对所述目标应用进行健康检查。

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

获取单元，用于获取所述目标健康检查规则中包含的健康检查类型，所述健康检查类型包括传输控制协议tcp健康检查和http健康检查；

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

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

可选的，所述健康检查规则中包含重试次数阈值和告警联系人；

所述装置还包括：

检测模块，用于当健康检查结果指示所述目标应用异常时，检测健康检查重试次数是否达到所述重试次数阈值；

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

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

综上所述，本申请实施例中，当接收到管理服务器下发的应用部署指令，并根据应用部署指令部署目标应用后，应用服务器首先根据目标健康检查规则对目标应用进行健康检查，并在目标应用正常时，通过注册中心注册所述目标应用；采用上述先健康检查后注册机制，应用服务器能够保证注册应用的可用性，从而避免注册异常应用导致服务调用失败的问题，提高了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来连接到其他类型的网络或远程计算机系统。

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

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

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

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

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