维护网络应用平台运行的方法及维护设备

摘要

本发明公开了一种维护网络应用平台运行的方法及维护设备。在该维护网络应用平台运行的方法中，所述网络应用平台与一个或多个底层服务器通信连接，每个底层服务器提供一个或者多个应用，而且所述网络应用平台包括应用门户，在所述应用门户中呈现所述底层服务器提供的应用，所述方法包括：检测每个底层服务器中提供的应用是否正常；在所述应用门户中加载检测结果为正常的应用；以及不在所述应用门户中加载检测结果为不正常的应用。根据本发明的维护网络应用平台运行的方法及维护设备，在某一底层服务器中的应用出现故障的情况下，应用门户依然可以向用户提供其他底层服务器的应用。

说明书

技术领域

本发明涉及计算机网络领域，具体涉及一种维护网络应用平台运行的方 法及维护设备。

背景技术

目前，随着网络应用的快速发展，网络应用平台能够呈现的应用种类和 数量越来越多。

在常见的网络应用平台系统架构中，网络应用平台与多个底层服务器相 连接，每个底层服务器能够提供一个或多个应用。由于在这种网络应用平台 系统架构中，网络应用平台、各服务器采用标准的多个系统合作模型，即各 部分之间存在着相互依赖的关系，因此，当一个底层服务器出现故障时，会 影响到网络应用平台中的其它底层服务器或者设备无法正常运行，例如，引 起其它底层服务器和其它设备的各种超时，会产生类似雪灾的效应，大面积 影响其它底层服务器和其它设备的正常运行。即使有报警设备进行监测，但 是报警后各应用或底层服务器和其它设备通过手工更新配置，重新上线，效 率较低，线上影响时间较长，从而导致用户无法访问该网络应用平台中的任 一应用，给用户造成了极大的不便。

发明内容

鉴于上述问题，提出了本发明以便提供一种克服上述问题或者至少部分 地解决上述问题的维护网络应用平台运行的方法及维护设备。

依据本发明的一个方面，提供了一种维护网络应用平台运行的方法。网 络应用平台与一个或多个底层服务器通信连接，每个底层服务器提供一个或 者多个应用。网络应用平台包括应用门户，在应用门户中呈现底层服务器提 供的应用。该方法包括：检测每个底层服务器中提供的应用是否正常；在应 用门户中加载检测结果为正常的应用；以及不在应用门户中加载检测结果为 不正常的应用。

可选地，检测每个底层服务器中提供的应用是否正常的步骤包括：每隔 预设的时间间隔，检测每个底层服务器中提供的应用是否正常。

可选地，检测每个底层服务器中提供的应用是否正常的步骤包括：访问 该底层服务器中与所提供的应用相对应的预定URL，如果该底层服务器对该 URL请求没有响应或者产生错误，则确定对应该URL的应用不正常。

可选地，不在应用门户中加载检测结果为不正常的应用的步骤包括：基 于检测结果，利用脚本来发布应用门户的新版本，在新版本中不加载检测结 果为不正常的应用。

可选地，还包括：检测被检测为出现异常的应用是否恢复正常，当检测 到其恢复正常时，在应用门户中加载检测恢复正常的应用。

可选地，当检测到其恢复正常时加载该应用的步骤包括：基于检测结果， 利用脚本来发布应用门户的新版本，在新版本中重新加载恢复正常的应用。

根据本发明的另一方面，提供了一种维护网络应用平台运行的维护设备。 网络应用平台与一个或多个底层服务器通信连接，每个底层服务器提供一个 或者多个应用。网络应用平台包括应用门户，在应用门户中呈现底层服务器 提供的应用。维护设备包括：监控器，被配置为检测底层服务器中的应用是 否正常；以及应用门户控制器，根据监控器的检测结果来控制应用门户，其 中在应用门户中加载检测结果为正常的应用，并且不在应用门户中加载检测 结果为不正常的应用。

可选地，监控器每隔预设的时间间隔来检测每个底层服务器中的应用是 否正常。

可选地，监控器访问该底层服务器中与所提供的应用相对应的预定URL， 如果该底层服务器对该URL请求没有响应或者产生错误，则确定对应该URL 的应用不正常。

可选地，其中应用门户控制器还包括应用加载模块，适于基于检测结果 来发布应用门户的版本，在应用门户的版本中，在应用门户中加载检测结果 为正常的应用且不加载检测结果为不正常的应用。

根据本发明的维护网络应用平台运行的方法及维护设备，可以检测每个 底层服务器中提供的应用是否正常，并根据检测结果在应用门户中加载正常 的应用，而不加载不正常的应用，由此解决了只要有一个底层服务器中的一 个应用出现故障就会影响整个应用门户运行的问题，取得了能够在某一底层 服务器中的应用出现故障的情况下，应用门户依然可以向用户提供其他底层 服务器的应用的有益效果。

上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技 术手段，而可依照说明书的内容予以实施，并且为了让本发明的上述和其它 目的、特征和优点能够更明显易懂，以下特举本发明的具体实施方式。

附图说明

通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本 领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的， 而并不认为是对本发明的限制。而且在整个附图中，用相同的参考符号表示 相同的部件。在附图中：

图1示出了根据本发明一个实施例的维护网络应用平台运行的方法流程 图；

图2示出了根据本发明一个实施例的维护网络应用平台运行的维护设备 与网络应用平台以及底层服务器之间的结构示意图；

图3示出了本发明实施例中检测到某一应用出现异常之前的界面图；

图4示出了本发明实施例中检测到某一应用出现异常之后的界面图。

具体实施方式

下面将参照附图更详细地描述本公开的示例性实施例。虽然附图中显示 了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不 应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地 理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。

图1示出了根据本发明的一个实施例的维护网络应用平台运行的方法的 流程图。在该实施例中，网络应用平台与一个或多个底层服务器通信连接， 每个底层服务器向网络应用平台提供一个或多个应用。该网络应用平台上包 括应用门户，在该应用门户中呈现所有底层服务器提供的所有应用，供不同 的用户根据自身的需求，对感兴趣的应用进行访问。这里，网络应用平台可 以由一台或多台服务器来实现，应用门户例如可以是设置于网络应用平台中 的应用接口。

如图1所示，根据本发明的一个实施例的维护网络应用平台运行的方法 始于步骤S110，在步骤S110中，检测每个底层服务器中提供的应用是否正 常。

为了避免某一底层服务器出现故障而影响网络应用平台和其它底层服务 器的正常运行，可以对每个底层服务器中提供的应用的状态进行检测。具体 地，可以每隔预设的时间间隔，检测一次各个底层服务器中提供的应用是否 正常，为了及时发现故障，可以将预设的时间间隔设置得尽可能小，以达到 近似实时检测的效果。

其中，用户访问底层服务器提供的应用可以通过与该底层服务器所提供 的该应用相对应的预定URL进行访问。也就是说，每一应用都具有一个与之 相对应的URL，通过访问该URL，即可访问该应用。因此，在检测某一底层 服务器中提供的应用是否正常时，可以通过访问与该底层服务器所提供的应 用相对应的URL来进行检测。如果当访问该底层服务器提供的该应用对应的 URL时，该底层服务器对该URL请求没有响应或者产生错误，则确定与该 URL对应的应用不正常，反之，则确定与该URL对应的应用正常。例如，可 以通过shell脚本（或其它脚本）来访问某一底层服务器所提供的一个应用对 应的URL，如果该底层服务器在预定时间内对该URL请求没有响应，或者产 生了错误信息，例如如果底层服务器返回500或502这样的HTTP错误代码 等，则确定与该URL对应的应用不正常。这里，500表示内部服务器错误信 息，502表示网关错误信息，根据产生的错误信息可以初步确定底层服务器中 的应用存在故障的原因。通过定期访问每个底层服务器中的每个应用对应的 URL，即可确定各个底层服务器中的各应用的状态是否正常。

另外，为了确保底层服务器的及时修复，还可以在确定出某个底层服务 器中的某个应用的状态不正常之后，向技术人员发送短信通知，以便技术人 员能够及时对其进行修复。

在上述步骤S110中获得对每个底层服务器提供的应用的检测结果之后， 在步骤S120中，在应用门户中加载检测结果为正常的应用，而不加载检测结 果为不正常的应用。也就是说，在步骤S120中，根据在步骤S110中所获得 的检测结果来确定在应用门户中应该加载哪些应用。

具体地，在步骤S120中，在应用门户中加载哪些应用可以由该应用门户 的脚本来实现。该应用门户的脚本的一种实现方式为：只包含要被加载的应 用对应的参数信息，不包含不被加载的应用对应的参数信息。这样，用户通 过应用门户只能看到正常的应用并能调用它们，而根本看不到不正常的应用， 因此也不会出现因为调用不正常的应用而产生的故障。另外，由于根据检测 结果来确定的被加载的应用和不被加载的应用可能会有变化，所以需要发布 该应用门户的脚本的新版本，在该新版本中只包含检测结果为正常的应用对 应的参数信息，而不包含检测结果为不正常的应用对应的参数信息，从而通 过运行应用门户的脚本的新版本，在网络应用平台上显示给用户的都将是能 够正常运行的应用。

该应用门户的脚本的另一种实现方式为：包含全部应用对应的参数信息， 但是，针对每一应用，还包含一个用来决定该应用是否呈现的参数，当该参 数的参数值为1时，表示该应用能够向用户呈现，这样，当运行应用门户脚 本的新版本时，该应用被加载；当该参数的参数值为0时，表示该应用不向 用户呈现，当运行应用门户脚本的新版本时，该应用不被加载。从而，应用 门户根据其脚本中决定应用是否呈现的参数的参数值来决定是否加载对应的 应用。在这种实现方式下，为了呈现根据检测结果而被加载的应用，需要发 布该应用门户的脚本的新版本，在该新版本中，对于检测结果为正常的应用， 将其对应的决定是否呈现的参数的参数值设置为1，则在运行应用门户的脚本 的新版本时该应用被加载，因而会被呈现给用户；对于检测结果为不正常的 应用，将其对应的决定是否呈现的参数的参数值设置为0，则运行应用门户的 脚本的新版本时该应用不被加载，因而不会被呈现给用户。由此可知，当运 行应用门户脚本的新版本时，呈现给用户的都是状态正常的底层服务器提供 的应用，而状态不正常的底层服务器提供的应用则不会呈现给用户。

根据本发明的一个示例，上述应用门户采用的脚本可以是shell脚本，也 可以是其它脚本。

通过采用本发明提供的上述维护网络应用平台运行的方法，即使在某个 底层服务器中存在状态异常的应用时，用户也可以通过应用门户访问状态正 常的应用，从而可以保障网络应用平台的正常运行，使得网络应用平台不会 因为一个或几个底层服务器中提供的一个或数个应用出现故障而不能正常运 行。

可选地，为了确保在出现异常的应用恢复正常时能够被及时地加载到应 用门户中，本发明的维护网络应用平台运行的方法还可以包括步骤S130，在 步骤S130中，检测上述被检测为不正常的应用是否已恢复正常，当检测到其 已恢复正常时，在所述应用门户中加载该恢复正常的应用，从而可以保障为 用户提供尽可能多的应用。

一方面，所述步骤S130可以在步骤S120之后执行，即，仅对在步骤S110 中检测为不正常的应用进行进一步的检测，检测其是否已恢复正常，当检测 其已恢复正常时，再次发布应用门户脚本的新版本，在该新版本中将已经恢 复正常的应用重新加载到应用门户中。另一方面，所述步骤S130也可以在步 骤S110之后执行，即，在步骤S110中在每隔预设的时间间隔检测每个底层 服务器提供的应用是否正常的步骤之后，还进一步执行步骤S130，以检测之 前被检测为不正常的应用是否已恢复正常，这样，在执行步骤S120发布应用 门户脚本的新版本时，不仅在新版本中加载被检测为正常的应用，而且重新 加载已恢复正常的应用，从而使用户能够尽快地访问已恢复正常的应用，降 低对用户的影响。

采用步骤S130可以避免在一应用被检测为不正常之后而被长时间搁置一 边，使用户长时间不能访问该应用的问题。

另外，本发明还可以采用另一方式：在步骤S110中每次得到所有底层服 务器的检测结果之后，都将本次的检测结果与上一次的检测结果进行比较， 如果本次的检测结果与上一次的检测结果不同，则发布应用门户脚本的新版 本，在该新版本中加载检测结果正常的应用，不加载检测结果不正常的应用； 如果本次的检测结果与上一次的检测结果相同，则无需再发布应用门户脚本 的新版本。这样，可以减少网络应用平台的更新次数，提高运行速度。

图2示出了根据本发明一个实施例的维护网络应用平台运行的维护设备 与网络应用平台以及底层服务器之间的结构示意图。如图2所示，该维护设 备200包括：监控器210以及应用门户控制器220。监控器210与各个底层服 务器分别通信连接，且被配置为检测各底层服务器中的应用是否正常。应用 门户控制器220根据监控器210的检测结果来控制应用门户加载检测结果为 正常的应用，不加载检测结果为不正常的应用。为了清楚地图示出该维护设 备200与网络应用平台以及各底层服务器之间的连接关系，在图2中不仅示 出了本发明的维护设备200，而且示出了与本发明的维护设备200相连接的网 络应用平台320以及底层服务器310。如图2所示，包括应用门户321的网络 应用平台320分别与各个底层服务器310相连，其中应用门户321加载底层 服务器310中提供的正常的应用并将其呈现给用户，其例如可以是带有界面 的应用接口。应用门户控制器220分别与网络应用平台320的应用门户321 和监控器210相连。监控器210分别与各个底层服务器310相连，以检测各 底层服务器310中提供的应用是否正常，并将检测结果传送给应用门户控制 器220，其中监控器210可以每隔预设的时间间隔检测每个底层服务器310 中提供的应用是否正常，具体的检测方式可以通过访问与待检测的底层服务 器中的应用相对应的URL，如果对该应用对应的URL的请求没有响应或者返 回错误信息，则确定与该URL对应的应用不正常，例如返回的错误信息可能 为http500（表示内部服务器错误信息）或http502（表示网关错误信息）等。 应用门户控制器220基于监控器210的检测结果来控制应用门户321加载被 检测为正常的应用，而不加载被检测为不正常的应用。

监控器210获取到检测结果之后，将检测结果发送给应用门户控制器 220。应用门户控制器220加载检测结果为正常的应用，而不加载检测结果为 不正常的应用。

具体地，应用门户控制器220控制应用门户中加载哪些应用可以由该应 用门户的脚本来实现。该应用门户的脚本的一种实现方式为：只包含要被加 载的应用对应的参数信息，不包含不被加载的应用对应的参数信息。这样， 用户通过应用门户只能看到正常的应用并能调用它们，而根本看不到不正常 的应用，因此也不会出现因为调用不正常的应用而产生的故障。另外，由于 根据检测结果来确定的被加载的应用和不被加载的应用可能会有变化，所以 需要由应用门户控制器220发布该应用门户的脚本的新版本，在该新版本中 只包含检测结果为正常的应用对应的参数信息，而不包含检测结果为不正常 的应用对应的参数信息。

可选地，该应用门户的脚本的另一种实现方式为：包含全部应用对应的 参数信息，但是，针对每一应用，还包含一个用来决定该应用是否呈现的参 数，当该参数的参数值为1时，表示该应用能够向用户呈现，这样，当运行 应用门户脚本的新版本时，加载该应用；当该参数的参数值为0时，表示该 应用不向用户呈现，当运行应用门户脚本的新版本时，不加载该应用。从而， 应用门户根据其脚本中决定应用是否呈现的参数的参数值来决定是否加载对 应的应用。在这种实现方式下，为了呈现根据检测结果而被加载的应用，需 要由应用门户控制器220发布该应用门户的脚本的新版本，在该新版本中， 对于检测结果正常的应用，将其对应的决定是否呈现的参数的参数值设置为 1，则在运行应用门户的脚本的新版本时该应用被加载，因而会被呈现给用户； 对于检测结果不正常的应用，将其对应的决定是否呈现的参数的参数值设置 为0，则运行应用门户的脚本的新版本时该应用不被加载，因而不会被呈现给 用户。由此可知，当运行应用门户脚本的新版本时，呈现给用户的都是状态 正常的底层服务器提供的应用，而状态不正常的底层服务器提供的应用则不 会呈现给用户。

其中，应用门户控制器220还可以进一步包括应用加载模块，其采用上 述两种应用门户的脚本的实现方式之一，基于检测结果发布应用门户的新版 本。

通过采用本发明提供的上述维护网络应用平台运行的维护设备，即使在 某个底层服务器中存在状态异常的应用时，用户也可以通过应用门户访问状 态正常的应用，从而可以保障网络应用平台的正常运行，使得网络应用平台 不会因为一个或几个底层服务器或其提供的一个或数个应用出现故障而不能 正常运行。

可选地，为了确保在出现异常的应用恢复正常时能够被及时地加载到应 用门户中，在本发明的维护网络应用平台运行的维护设备中，监控器210还 可以用于检测上述被检测为不正常的应用是否已恢复正常，当检测到其已恢 复正常时，通知应用门户控制器220在应用门户中加载该恢复正常的应用， 从而可以保障为用户提供尽可能多的应用。

具体地，为了实现对恢复正常的应用的加载，监控器210可以对上述被 检测为不正常的应用进行进一步的检测，检测其是否已恢复正常，当检测其 已恢复正常时，通知应用门户控制器220再次发布应用门户脚本的新版本， 在该新版本中将已经恢复正常的应用重新加载到应用门户中。

或者，也可以由应用门户控制器220在每次获取到监控器210的检测结 果后，将本次检测结果与上一次的检测结果进行比较，如果本次的检测结果 与上一次的检测结果不同，则发布应用门户脚本的新版本，在该新版本中加 载检测结果正常的应用，不加载检测结果不正常的应用。如果本次的检测结 果与上一次的检测结果相同，则无需再发布应用门户脚本的新版本。这样， 可以减少网络应用平台的更新次数，提高运行速度。

在上述过程中，监控器210和应用门户控制器220之间可以通过专门的 应用程序接口API进行通讯。例如，在应用门户控制器220上可以设置一个 API专门用来接收来自监控器210的检测结果，监控器210通过该API向应 用门户控制器220发送检测结果。通过API通讯方式，可以提高通讯效率。

图3和图4分别示出了本发明实施例中检测到某一底层服务器出现异常 之前以及之后网络应用平台分别呈现给用户的界面图。这里，图3和图4是 以提供游戏的网络游戏平台为例进行描述的。如图3所示，正常状态下，该 游戏界面呈现四个底层服务器所提供的应用的状态，即，用户登录部分：其 呈现用户的用户名或目前所在位置，而且在此部分，用户可以“修改密码” 或者“更换帐号”；“新区开放”部分：其向用户呈现网站新开放的游戏的 区域服务器名称，例如图3中示出“360卫士07区”是一个新开放的游戏区 服；“所有服务器”部分：其向用户呈现目前可以正常使用的提供游戏服务 的所有区域服务器名称，例如图3中示出了目前可以正常提供服务的7个区 服“360卫士01区”~““360卫士07区”，用户可以点击任何一个区服而 调用其提供的游戏；“登录过的服务器”部分：其向用户呈现该用户曾经登 录过的所有区域服务器名称，例如图3示出了用户名为“部落老大”的用户 曾经登录过“360卫士04区”、“360卫士05区”、“360卫士03区”，其 中位于最上面的是最近登录过的区服。

当检测到用于管理“登录过的服务器”这一功能的底层服务器出现异常 时，则网络游戏平台的应用门户会发布新版本，在新版本中不加载用于管理 “登录过的服务器”这一功能的底层服务器所提供的应用，这时，网络游戏 平台呈现给用户的界面中的“登录过的服务器”部分不呈现任何内容，如图4 所示，而对于其它正常运行的底层服务器，则仍然能够正常地显示在图4的 网络游戏平台呈现给用户的界面中，从而使得网络游戏平台不会因某一底层 服务器出现异常而不能正常工作，其它底层服务器也不会因该出现异常的底 层服务器而不能正常运行，因而能够保障网络游戏平台向用户提供服务的连 续性。

通过本发明的维护网络应用平台运行的方法及维护设备，可以检测每个 底层服务器中提供的应用是否正常，并根据检测结果在应用门户中加载正常 的应用，而不加载不正常的应用，由此解决了只要有一个底层服务器中的一 个应用出现故障就会影响整个应用门户运行的问题，在某一底层服务器中的 应用出现故障的情况下，应用门户依然可以向用户提供其他底层服务器的应 用。

在此提供的算法和显示不与任何特定计算机、虚拟系统或者其它设备固 有相关。各种通用系统也可以与基于在此的示教一起使用。根据上面的描述， 构造这类系统所要求的结构是显而易见的。此外，本发明也不针对任何特定 编程语言。应当明白，可以利用各种编程语言实现在此描述的本发明的内容， 并且上面对特定语言所做的描述是为了披露本发明的最佳实施方式。

在此处所提供的说明书中，说明了大量具体细节。然而，能够理解，本 发明的实施例可以在没有这些具体细节的情况下实践。在一些实例中，并未 详细示出公知的方法、结构和技术，以便不模糊对本说明书的理解。 类似地，应当理解，为了精简本公开并帮助理解各个发明方面中的一个或多 个，在上面对本发明的示例性实施例的描述中，本发明的各个特征有时被一 起分组到单个实施例、图、或者对其的描述中。然而，并不应将该公开的方 法解释成反映如下意图：即所要求保护的本发明要求比在每个权利要求中所 明确记载的特征更多的特征。更确切地说，如下面的权利要求书所反映的那 样，发明方面在于少于前面公开的单个实施例的所有特征。因此，遵循具体 实施方式的权利要求书由此明确地并入该具体实施方式，其中每个权利要求 本身都作为本发明的单独实施例。

本领域那些技术人员可以理解，可以对实施例中的设备中的模块进行自 适应性地改变并且把它们设置在与该实施例不同的一个或多个设备中。可以 把实施例中的模块或单元或组件组合成一个模块或单元或组件，以及此外可 以把它们分成多个子模块或子单元或子组件。除了这样的特征和/或过程或者 单元中的至少一些是相互排斥之外，可以采用任何组合对本说明书（包括伴 随的权利要求、摘要和附图）中公开的所有特征以及如此公开的任何方法或 者设备的所有过程或单元进行组合。除非另外明确陈述，本说明书（包括伴 随的权利要求、摘要和附图）中公开的每个特征可以由提供相同、等同或相 似目的的替代特征来代替。

此外，本领域的技术人员能够理解，尽管在此所述的一些实施例包括其 它实施例中所包括的某些特征而不是其它特征，但是不同实施例的特征的组 合意味着处于本发明的范围之内并且形成不同的实施例。例如，在下面的权 利要求书中，所要求保护的实施例的任意之一都可以以任意的组合方式来使 用。

本发明的各个部件实施例可以以硬件实现，或者以在一个或者多个处理 器上运行的软件模块实现，或者以它们的组合实现。本领域的技术人员应当 理解，可以在实践中使用微处理器或者数字信号处理器（DSP）来实现根据 本发明实施例的维护设备中的一些或者全部部件的一些或者全部功能。本发 明还可以实现为用于执行这里所描述的方法的一部分或者全部的设备或者装 置程序（例如，计算机程序和计算机程序产品）。这样的实现本发明的程序 可以存储在计算机可读介质上，或者可以具有一个或者多个信号的形式。这 样的信号可以从因特网网站上下载得到，或者在载体信号上提供，或者以任 何其他形式提供。

应该注意的是上述实施例对本发明进行说明而不是对本发明进行限制， 并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实 施例。在权利要求中，不应将位于括号之间的任何参考符号构造成对权利要 求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于 元件之前的单词“一”或“一个”不排除存在多个这样的元件。本发明可以 借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在 列举了若干装置的单元权利要求中，这些装置中的若干个可以是通过同一个 硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。 可将这些单词解释为名称。