专利名称：维护网络应用平台运行的方法及维护设备的制作方法
技术领域：
本发明涉及计算机网络领域，具体涉及ー种维护网络应用平台运行的方法及维护设备。
背景技术：
目前，随着网络应用的快速发展，网络应用平台能够呈现的应用种类和数量越来越多。在常见的网络应用平台系统架构中，网络应用平台与多个底层服务器相连接，每
个底层服务器能够提供ー个或多个应用。由于在这种网络应用平台系统架构中，网络应用平台、各服务器采用标准的多个系统合作模型，即各部分之间存在着相互依赖的关系，因此，当ー个底层服务器出现故障时，会影响到网络应用平台中的其它底层服务器或者设备无法正常运行，例如，引起其它底层服务器和其它设备的各种超时，会产生类似雪灾的效应，大面积影响其它底层服务器和其它设备的正常运行。即使有报警设备进行监测，但是报警后各应用或底层服务器和其它设备通过手工更新配置，重新上线，效率较低，线上影响时间较长，从而导致用户无法访问该网络应用平台中的任ー应用，给用户造成了极大的不便。
发明内容
鉴于上述问题，提出了本发明以便提供ー种克服上述问题或者至少部分地解决上述问题的维护网络应用平台运行的方法及维护设备。依据本发明的ー个方面，提供了一种维护网络应用平台运行的方法。网络应用平台与一个或多个底层服务器通信连接，每个底层服务器提供一个或者多个应用。网络应用平台包括应用门户，在应用门户中呈现底层服务器提供的应用。该方法包括检测每个底层服务器中提供的应用是否正常；在应用门户中加载检测结果为正常的应用；以及不在应用门户中加载检测结果为不正常的应用。可选地，检测每个底层服务器中提供的应用是否正常的步骤包括每隔预设的时间间隔，检测每个底层服务器中提供的应用是否正常。可选地，检测每个底层服务器中提供的应用是否正常的步骤包括访问该底层服务器中与所提供的应用相对应的预定URL，如果该底层服务器对该URL请求没有响应或者产生错误，则确定对应该URL的应用不正常。可选地，不在应用门户中加载检测结果为不正常的应用的步骤包括基于检测结果，利用脚本来发布应用门户的新版本，在新版本中不加载检测结果为不正常的应用。可选地，还包括检测被检测为出现异常的应用是否恢复正常，当检测到其恢复正常时，在应用门户中加载检测恢复正常的应用。可选地，当检测到其恢复正常时加载该应用的步骤包括基于检测结果，利用脚本来发布应用门户的新版本，在新版本中重新加载恢复正常的应用。根据本发明的另一方面，提供了一种维护网络应用平台运行的维护设备。网络应用平台与一个或多个底层服务器通信连接，每个底层服务器提供一个或者多个应用。网络应用平台包括应用门户，在应用门户中呈现底层服务器提供的应用。维护设备包括监控器，被配置为检测底层服务器中的应用是否正常；以及应用门户控制器，根据监控器的检测结果来控制应用门户，其中在应用门户中加载检测结果为正常的应用，并且不在应用门户中加载检测结果为不正常的应用。可选地，监控器每隔预设的时间间隔来检测每个底层服务器中的应用是否正常。可选地，监控器访问该底层服务器中与所提供的应用相对应的预定URL，如果该底层服务器对该URL请求没有响应或者产生错误，则确定对应该URL的应用不正常。可选地，其中应用门户控制器还包括应用加载模块，适于基于检测结果来发布应用门户的版本，在应用门户的版本中，在应用门户中加载检测结果为正常的应用且不加载检测结果为不正常的应用。根据本发明的维护网络应用平台运行的方法及维护设备，可以检测每个底层服务 器中提供的应用是否正常，并根据检测结果在应用门户中加载正常的应用，而不加载不正常的应用，由此解决了只要有一个底层服务器中的ー个应用出现故障就会影响整个应用门户运行的问题，取得了能够在某一底层服务器中的应用出现故障的情况下，应用门户依然可以向用户提供其他底层服务器的应用的有益效果。上述说明仅是本发明技术方案的概述，为了能够更清楚了解本发明的技术手段，而可依照说明书的内容予以实施，并且为了让本发明的上述和其它目的、特征和优点能够更明显易懂，以下特举本发明的具体实施方式
。
通过阅读下文优选实施方式的详细描述，各种其他的优点和益处对于本领域普通技术人员将变得清楚明了。附图仅用于示出优选实施方式的目的，而并不认为是对本发明的限制。而且在整个附图中，用相同的參考符号表示相同的部件。在附图中图I示出了根据本发明一个实施例的维护网络应用平台运行的方法流程图；图2示出了根据本发明一个实施例的维护网络应用平台运行的维护设备与网络应用平台以及底层服务器之间的结构示意图；图3示出了本发明实施例中检测到某一应用出现异常之前的界面图；图4示出了本发明实施例中检测到某一应用出现异常之后的界面图。
具体实施例方式下面将參照附图更详细地描述本公开的示例性实施例。虽然附图中显示了本公开的示例性实施例，然而应当理解，可以以各种形式实现本公开而不应被这里阐述的实施例所限制。相反，提供这些实施例是为了能够更透彻地理解本公开，并且能够将本公开的范围完整的传达给本领域的技术人员。图I示出了根据本发明的一个实施例的维护网络应用平台运行的方法的流程图。在该实施例中，网络应用平台与一个或多个底层服务器通信连接，每个底层服务器向网络应用平台提供一个或多个应用。该网络应用平台上包括应用门户，在该应用门户中呈现所有底层服务器提供的所有应用，供不同的用户根据自身的需求，对感兴趣的应用进行访问。这里，网络应用平台可以由一台或多台服务器来实现，应用门户例如可以是设置于网络应用平台中的应用接ロ。如图I所示，根据本发明的一个实施例的维护网络应用平台运行的方法始于步骤S110，在步骤SllO中，检测每个底层服务器中提供的应用是否正常。为了避免某一底层服务器出现故障而影响网络应用平台和其它底层服务器的正常运行，可以对每个底层服务器中提供的应用的状态进行检测。具体地，可以每隔预设的时间间隔，检测一次各个底层服务器中提供的应用是否正常，为了及时发现故障，可以将预设的时间间隔设置得尽可能小，以达到近似实时检测的效果。其中，用户访问底层服务器提供的应用可以通过与该底层服务器所提供的该应用相对应的预定URL进行访问。也就是说，每ー应用都具有一个与之相对应的URL，通过访问该URL，即可访问该应用。因此，在检测某一底层服务器中提供的应用是否正常时，可以通过访问与该底层服务器所提供的应用相对应的URL来进行检測。如果当访问该底层服务器提 供的该应用对应的URL吋，该底层服务器对该URL请求没有响应或者产生错误，则确定与该URL对应的应用不正常，反之，则确定与该URL对应的应用正常。例如，可以通过she 11脚本(或其它脚本)来访问某一底层服务器所提供的一个应用对应的URL，如果该底层服务器在预定时间内对该URL请求没有响应，或者产生了错误信息，例如如果底层服务器返回500或502这样的HTTP错误代码等，则确定与该URL对应的应用不正常。这里，500表示内部服务器错误信息，502表示网关错误信息，根据产生的错误信息可以初步确定底层服务器中的应用存在故障的原因。通过定期访问每个底层服务器中的每个应用对应的URL，即可确定各个底层服务器中的各应用的状态是否正常。另外，为了确保底层服务器的及时修复，还可以在确定出某个底层服务器中的某个应用的状态不正常之后，向技术人员发送短信通知，以便技术人员能够及时对其进行修复。在上述步骤SllO中获得对每个底层服务器提供的应用的检测结果之后，在步骤S120中，在应用门户中加载检测结果为正常的应用，而不加载检测结果为不正常的应用。也就是说，在步骤S120中，根据在步骤SllO中所获得的检测结果来确定在应用门户中应该加载哪些应用。具体地，在步骤S120中，在应用门户中加载哪些应用可以由该应用门户的脚本来实现。该应用门户的脚本的一种实现方式为只包含要被加载的应用对应的參数信息，不包含不被加载的应用对应的參数信息。这样，用户通过应用门户只能看到正常的应用并能调用它们，而根本看不到不正常的应用，因此也不会出现因为调用不正常的应用而产生的故障。另外，由于根据检测结果来确定的被加载的应用和不被加载的应用可能会有变化，所以需要发布该应用门户的脚本的新版本，在该新版本中只包含检测结果为正常的应用对应的參数信息，而不包含检测结果为不正常的应用对应的參数信息，从而通过运行应用门户的脚本的新版本，在网络应用平台上显示给用户的都将是能够正常运行的应用。该应用门户的脚本的另ー种实现方式为包含全部应用对应的參数信息，但是，针对每ー应用，还包含一个用来决定该应用是否呈现的參数，当该參数的參数值为I时，表示该应用能够向用户呈现，这样，当运行应用门户脚本的新版本时，该应用被加载；当该參数的參数值为0时，表示该应用不向用户呈现，当运行应用门户脚本的新版本时，该应用不被加载。从而，应用门户根据其脚本中决定应用是否呈现的參数的參数值来决定是否加载对应的应用。在这种实现方式下，为了呈现根据检测结果而被加载的应用，需要发布该应用门户的脚本的新版本，在该新版本中，对于检测结果为正常的应用，将其对应的决定是否呈现的參数的參数值设置为I，则在运行应用门户的脚本的新版本时该应用被加载，因而会被呈现给用户；对于检测结果为不正常的应用，将其对应的决定是否呈现的參数的參数值设置为O，则运行应用门户的脚本的新版本时该应用不被加载，因而不会被呈现给用户。由此可知，当运行应用门户脚本的新版本吋，呈现给用户的都是状态正常的底层服务器提供的应用，而状态不正常的底层服务器提供的应用则不会呈现给用户。根据本发明的ー个示例，上述应用门户采用的脚本可以是shell脚本，也可以是其它脚本。
通过采用本发明提供的上述维护网络应用平台运行的方法，即使在某个底层服务器中存在状态异常的应用时，用户也可以通过应用门户访问状态正常的应用，从而可以保障网络应用平台的正常运行，使得网络应用平台不会因为ー个或几个底层服务器中提供的ー个或数个应用出现故障而不能正常运行。可选地，为了确保在出现异常的应用恢复正常时能够被及时地加载到应用门户中，本发明的维护网络应用平台运行的方法还可以包括步骤S130，在步骤S130中，检测上述被检测为不正常的应用是否已恢复正常，当检测到其已恢复正常时，在所述应用门户中加载该恢复正常的应用，从而可以保障为用户提供尽可能多的应用。一方面，所述步骤S130可以在步骤S120之后执行，即，仅对在步骤SllO中检测为不正常的应用进行进ー步的检测，检测其是否已恢复正常，当检测其已恢复正常时，再次发布应用门户脚本的新版本，在该新版本中将已经恢复正常的应用重新加载到应用门户中。另ー方面，所述步骤S130也可以在步骤SllO之后执行，即，在步骤SllO中在每隔预设的时间间隔检测每个底层服务器提供的应用是否正常的步骤之后，还进ー步执行步骤S130，以检测之前被检测为不正常的应用是否已恢复正常，这样，在执行步骤S120发布应用门户脚本的新版本时，不仅在新版本中加载被检测为正常的应用，而且重新加载已恢复正常的应用，从而使用户能够尽快地访问已恢复正常的应用，降低对用户的影响。采用步骤S130可以避免在一应用被检测为不正常之后而被长时间搁置ー边,使用户长时间不能访问该应用的问题。另外，本发明还可以采用另一方式在步骤SllO中毎次得到所有底层服务器的检测结果之后，都将本次的检测结果与上一次的检测结果进行比较，如果本次的检测结果与上一次的检测结果不同，则发布应用门户脚本的新版本，在该新版本中加载检测结果正常的应用，不加载检测结果不正常的应用；如果本次的检测结果与上一次的检测结果相同，则无需再发布应用门户脚本的新版本。这样，可以减少网络应用平台的更新次数，提高运行速度。图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发布该应用门户的脚本的新版本，在该新版本中只包含检测结果为正常的应用对应的參数信息，而不包含检测结果为不正常的应用对应的參数信息。可选地，该应用门户的脚本的另ー种实现方式为包含全部应用对应的參数信息，但是，针对每ー应用，还包含一个用来决定该应用是否呈现的參数，当该參数的參数值为I时，表示该应用能够向用户呈现，这样，当运行应用门户脚本的新版本时，加载该应用；当该參数的參数值为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)来实现根据本发明实施例的维护设备中的一些或者全部部件的一些或者全部功能。本发明还可以实现为用于执行这里所描述的方法的一部分或者全部的设备或者装置程序(例如，计算机程序和计算机程序产品)。这样的实现本发明的程序可以存储在计算机可读介质上，或者可以具有ー个或者多个信号的形式。这样的信号可以从因特网网站上下载得到，或者在载体信号上提供，或者以任何其他形式提供。应该注意的是上述实施例对本发明进行说明而不是对本发明进行限制，并且本领域技术人员在不脱离所附权利要求的范围的情况下可设计出替换实施例。在权利要求中，不应将位于括号之间的任何參考符号构造成对权利要求的限制。单词“包含”不排除存在未列在权利要求中的元件或步骤。位于元件之前的单词“一”或“ー个”不排除存在多个这样的元件。本发明可以借助于包括有若干不同元件的硬件以及借助于适当编程的计算机来实现。在列举了若干装置的单元权利要求中，这些装置中的若干个可以是通过同一个硬件项来具体体现。单词第一、第二、以及第三等的使用不表示任何顺序。可将这些单词解释为名称。
权利要求
1.一种维护网络应用平台运行的方法，所述网络应用平台与一个或多个底层服务器通信连接，每个底层服务器提供一个或者多个应用，而且所述网络应用平台包括应用门户，在所述应用门户中呈现所述底层服务器提供的应用，所述方法包括 检测每个底层服务器中提供的应用是否正常； 在所述应用门户中加载检测结果为正常的应用；以及 不在所述应用门户中加载检测结果为不正常的应用。
2.如权利要求I所述的方法，所述检测每个底层服务器中提供的应用是否正常的步骤包括 每隔预设的时间间隔，检测每个底层服务器中提供的应用是否正常。
3.如权利要求I或者2所述的方法，所述检测每个底层服务器中提供的应用是否正常的步骤包括 访问该底层服务器中与所提供的应用相对应的预定URL，如果该底层服务器对该URL请求没有响应或者产生错误，则确定与该URL对应的应用不正常。
4.如权利要求1-3中任一个所述的方法，所述不在所述应用门户中加载检测结果为不正常的应用的步骤包括 基于检测结果，利用脚本来发布所述应用门户的新版本，在所述新版本中不加载检测结果为不正常的应用。
5.如权利要求1-4中任一个所述的方法,还包括 检测所述被检测为不正常的应用是否恢复正常，当检测到其恢复正常时，在所述应用门户中加载该恢复正常的应用。
6.如权利要求5所述的方法，所述当检测到所述应用恢复正常时加载该恢复正常的应用的步骤包括 基于检测结果，利用脚本来发布所述应用门户的新版本，在所述新版本中重新加载恢复正常的应用。
7.一种维护网络应用平台运行的维护设备，所述网络应用平台与一个或多个底层服务器通信连接，每个底层服务器提供一个或者多个应用，而且所述网络应用平台包括应用门户，在所述应用门户中呈现所述底层服务器提供的应用，所述维护设备包括 监控器，被配置为检测所述底层服务器中的应用是否正常；以及 应用门户控制器，根据所述监控器的检测结果来控制所述应用门户，其中在所述应用门户中加载检测结果为正常的应用，并且不在所述应用门户中加载检测结果为不正常的应用。
8.如权利要求7所述的维护设备，其中所述监控器每隔预设的时间间隔来检测每个底层服务器中的应用是否正常。
9.如权利要求7或者8所述的维护设备，所述监控器访问该底层服务器中与所提供的应用相对应的预定URL，如果该底层服务器对该URL请求没有响应或者产生错误，则确定对应该URL的应用不正常。
10.如权利要求7-9中任一个所述的维护设备，其中所述应用门户控制器还包括应用加载模块，适于基于检测结果来发布所述应用门户的版本，在所述应用门户的版本中，在所述应用门户中加载检测结果为正常的应用且不加载检测结果为不正常的应用。
全文摘要
本发明公开了一种维护网络应用平台运行的方法及维护设备。在该维护网络应用平台运行的方法中，所述网络应用平台与一个或多个底层服务器通信连接，每个底层服务器提供一个或者多个应用，而且所述网络应用平台包括应用门户，在所述应用门户中呈现所述底层服务器提供的应用，所述方法包括检测每个底层服务器中提供的应用是否正常；在所述应用门户中加载检测结果为正常的应用；以及不在所述应用门户中加载检测结果为不正常的应用。根据本发明的维护网络应用平台运行的方法及维护设备，在某一底层服务器中的应用出现故障的情况下，应用门户依然可以向用户提供其他底层服务器的应用。
文档编号H04L12/24GK102868562SQ201210370968
公开日2013年1月9日 申请日期2012年9月28日 优先权日2012年9月28日
发明者赵宏威, 黄会娟 申请人:北京奇虎科技有限公司, 奇智软件(北京)有限公司