用于应用服务进程守护的系统和方法

1.一种用于应用服务进程守护的系统，其特征在于，所述系统包括第一守护执行模块、第二守护执行模块和守护策略配置模块，其中：
守护策略配置模块，用于使用户设置守护策略；设置所述守护策略包括：确定需要守护的包括哪些所述应用服务器、确定每一所述应用服务器的运行进程发生异常时的判断条件、和/或确定每一所述应用服务器的运行进程发生异常时的解决方式；
所述第一守护执行模块，用于实时监测需要守护应用服务器的状态，当判断所述应用服务器发生异常时，解决所述应用服务器的异常问题；以及用于实时监测所述第二守护执行模块的状态，当判断所述第二守护执行模块的运行发生异常时，重启所述第二守护执行模块；其中所述第一守护执行模块根据预先获取的所述守护策略，判断所述应用服务器是否发生异常以及解决所述应用服务器的异常问题；
第二守护执行模块，用于实时监测所述第一守护执行模块的状态，当判断所述第一守护执行模块的运行发生异常时，重启所述第一守护执行模块。
2.如权利要求1所述的系统，其特征在于，所述系统还包括：
守护策略管理模块，用于读取并保存所述守护策略，并使所述用户能够对所述守护策略进行修改。
3.如权利要求1所述的系统，其特征在于，所述判断条件包括：
所述应用服务器的硬件资源消耗超过一设定阈值的时间达到一预定时间、向所述应用服务器发送心跳连续超过一设定次数，未收到所述应用服务器的应答、或者所述应用服务器正在处理的请求积压超过一设定数量。
4.如权利要求1所述的系统，其特征在于，所述解决方式包括：
重启所述应用服务器或者关闭所述应用服务器的一或多个应用进程。
5.一种用于应用服务进程守护的方法，其特征在于，包括步骤：
守护策略配置模块获取用户预先设置的应用服务器的守护策略；预先设置的所述守护策略包括：确定需要守护的包括哪些所述应用服务器、确定每一所述应用服务器的运行进程发生异常时的判断条件、和/或确定每一所述应用服务器的运行进程发生异常时的解决方式；
第一守护执行模块获取所述应用服务器的守护策略，根据所述守护策略，实时监测需要守护应用服务器的状态，判断所述应用服务器是否发生异常，当判断所述应用服务器发生异常时，解决所述应用服务器的异常问题；
第二守护执行模块实时监测所述第一守护执行模块的状态，当判断所述第一守护执行模块的运行发生异常时，重启所述第一守护执行模块；
所述第一守护执行模块还实时监测所述第二守护执行模块的状态，当判断所述第二守护执行模块的运行发生异常时，重启所述第二守护执行模块。
6.如权利要求5所述的方法，其特征在于，所述第一守护执行模块根据所述守护策略，实时监测需要守护应用服务器的状态，判断所述应用服务器是否发生异常，当判断所述应用服务器发生异常时，解决所述应用服务器的异常问题的步骤具体包括：
所述第一守护执行模块将所述应用服务器的状态与所述守护策略设定的判断条件进行比较，判断所述应用服务器是否发生异常；
所述第一守护执行模块根据所述守护策略设定的方式，解决所述应用服务器的异常问题。
7.如权利要求6所述的方法，其特征在于，所述判断条件包括：
所述应用服务器的硬件资源消耗超过一设定阈值的时间达到一预定时间、向所述应用服务器发送心跳连续超过一设定次数，未收到所述应用服务器的应答、或者所述应用服务器正在处理的请求积压超过一设定数量。

用于应用服务进程守护的系统和方法\n技术领域\n[0001] 本发明涉及网络通信的应用服务技术领域，尤其是指一种用于应用服务进程守护的系统和方法。\n背景技术\n[0002] 随着互联网和电信应用技术的高速发展，对应用服务的稳定性要求也日益提高。\n尤其地，对于J2EE应用服务器进程(如：Tomcat、Oracle Weblogic Server、IBM Websphere Server等主流应用服务进程)，为了维护服务器稳定，需要对正在运行的应用服务器进行守护，当应用服务器出现故障的时候，能够及时修正。\n[0003] 现有技术的互联网应用中，通常采用建立服务器集群或双机互连局域网的方式，来达到使应用服务进程稳定的目的，但采用该种方式无疑会造成硬件成本的增加。\n[0004] 此外，业界也有开发通过软件形式对应用服务进程进行维护的方法，但在现有技术的诸多软件实现方法中，均没有考虑到用于应用服务守护系统自身的稳定性问题，一旦守护系统出现运行故障而中断，应用服务器进程运行的稳定性就很难得到保证。\n[0005] 因此，现有技术还缺少用于维护应用服务进程稳定性的最佳方法，能够首先保证守护系统自身的运行稳定性。\n发明内容\n[0006] 本发明技术方案的目的是提供一种用于应用服务进程守护的系统和方法，在对应用服务器的运行进程提供守护的同时，还能保证自身的运行稳定性，以持续对应用服务器提供服务。\n[0007] 为实现上述目的，本发明一方面提供一种用于应用服务进程守护的系统，所述系统包括第一守护执行模块和第二守护执行模块，其中：\n[0008] 所述第一守护执行模块，用于实时监测需要守护应用服务器的状态，当判断所述应用服务器发生异常时，解决所述应用服务器的异常问题；以及用于实时监测所述第二守护执行模块的状态，当判断所述第二守护执行模块的运行发生异常时，重启所述第二守护执行模块；\n[0009] 第二守护执行模块，用于实时监测所述第一守护执行模块的状态，当判断所述第一守护执行模块的运行发生异常时，重启所述第一守护执行模块。\n[0010] 优选地，上述所述的系统，所述第一守护执行模块根据预先获取的守护策略，判断所述应用服务器是否发生异常以及解决所述应用服务器的异常问题。\n[0011] 优选地，上述所述的系统，所述系统还包括：\n[0012] 守护策略配置模块，用于使用户设置所述守护策略。\n[0013] 优选地，上述所述的系统，所述系统还包括：\n[0014] 守护策略管理模块，用于读取并保存所述守护策略，并使所述用户能够对所述守护策略进行修改。\n[0015] 优选地，上述所述的系统，设置所述守护策略包括：\n[0016] 确定需要守护的包括哪些所述应用服务器、确定每一所述应用服务器的运行进程发生异常时的判断条件、和/或确定每一所述应用服务器的运行进程发生异常时的解决方式。\n[0017] 优选地，上述所述的系统，所述判断条件包括：\n[0018] 所述应用服务器的硬件资源消耗超过一设定阈值的时间达到一预定时间、向所述应用服务器发送心跳连续超过一设定次数，未收到所述应用服务器的应答、或者所述应用服务器正在处理的请求积压超过一设定数量。\n[0019] 优选地，上述所述的系统，所述解决方式包括：\n[0020] 重启所述应用服务器或者关闭所述应用服务器的一或多个应用进程。\n[0021] 本发明另一方面提供一种用于应用服务进程守护的方法，括步骤：\n[0022] 第一守护执行模块实时监测需要守护应用服务器的状态，当判断所述应用服务器发生异常时，解决所述应用服务器的异常问题；\n[0023] 第二守护执行模块实时监测所述第一守护执行模块的状态，当判断所述第一守护执行模块的运行发生异常时，重启所述第一守护执行模块；\n[0024] 所述第一守护执行模块还实时监测所述第二守护执行模块的状态，当判断所述第二守护执行模块的运行发生异常时，重启所述第二守护执行模块。\n[0025] 优选地，上述所述的方法，所述第一守护执行模块实时监测需要守护应用服务器的状态，当判断所述应用服务器发生异常时，解决所述应用服务器的异常问题的步骤具体包括：\n[0026] 所述第一守护执行模块获取所述应用服务器的守护策略，其中用户通过守护策略配置模块预先设置所述守护策略；\n[0027] 所述第一守护执行模块实时监测所述应用服务器的状态；\n[0028] 所述第一守护执行模块将所述应用服务器的状态与所述守护策略设定的判断条件进行比较，判断所述应用服务器是否发生异常；\n[0029] 所述第一守护执行模块根据所述守护策略设定的方式，解决所述应用服务器的异常问题。\n[0030] 优选地，上述所述的方法，所述判断条件包括：\n[0031] 所述应用服务器的硬件资源消耗超过一设定阈值的时间达到一预定时间、向所述应用服务器发送心跳连续超过一设定次数，未收到所述应用服务器的应答、或者所述应用服务器正在处理的请求积压超过一设定数量。\n[0032] 本发明具体实施例上述的应用服务进程守护的系统和方法，具有以下有益效果：\n[0033] 1)第一守护执行模块和第二守护执行模块相互守护，确保了用于应用服务进程守护的系统运行稳定性，在操作系统不宕机时，永远有效，保证被守护的应用服务器能够持续对外提供服务；\n[0034] 2)用户能够根据所需要守护的不同应用服务器的进程动态地配置守护策略，有极强的扩展性；\n[0035] 3)应用不限于具体的哪个应用服务或软件，而是可以同时应用于守护多个应用服务器进程或软件；\n附图说明\n[0036] 图1为本发明第一实施例所述系统的应用结构示意图；\n[0037] 图2为本发明第二实施例所述系统的应用结构示意图；\n[0038] 图3为本发明第二实施例所述系统中，第一守护执行模块的结构示意图；\n[0039] 图4为本发明第二实施例所述系统启动时的流程示意图；\n[0040] 图5为本发明具体实施例所述方法的流程示意图；\n[0041] 图6为本发明具体实施例所述方法中，使第一守护执行模块进行应用服务器守护的流程示意图。\n具体实施方式\n[0042] 为使本发明的目的、技术方案和优点更加清楚，下面将结合附图及具体实施例对本发明进行详细描述。\n[0043] 本发明所述用于应用服务进程守护的系统和方法，设置两个守护执行模块，其中利用第一守护执行模块实时守护应用服务器的运行，利用第二守护执行模块与第一守护执行模块相互守护，这样当第一守护执行模块发生运行故障或守护中止时，第二守护执行模块能够实时监测到该状况，及时令第一守护执行模块重启而恢复工作，保证本发明所述系统能够持续稳定地为应用服务器提供守护服务。\n[0044] 图1为本发明第一实施例所述系统的结构示意图。所述系统100包括：\n[0045] 第一守护执行模块110，用于实时监测需要守护应用服务器的状态，当判断应用服务器发生异常时，解决应用服务器的异常问题；以及还用于实时监测第二守护执行模块\n120的状态，当判断第二守护执行模块120的运行发生异常时，重启第二守护执行模块120。\n[0046] 第二守护执行模块120，用于实时监测第一守护执行模块110的状态，当判断第一守护执行模块110的运行发生异常时，重启第一守护执行模块110。\n[0047] 第一实施例所述系统中，第一守护执行模块110和第二守护执行模块120相互守护，确保了用于应用服务进程守护的系统运行稳定性，在操作系统不宕机时，永远有效，保证被守护的应用服务器能够持续对外提供服务。\n[0048] 另外，本发明所述用于应用服务进程守护的系统，第一守护执行模块向应用服务器提供进程守护的方式，可以依据预先设定的守护策略进行，守护策略可以采用向系统导入的形式，也可以采用在系统内设置的形式。用户可以具体根据所需要守护的不同应用服务器进程设定不同守护策略，以使用于应用服务进程守护的系统，可以同时应用于守护多个应用服务器进程或软件。\n[0049] 图2示出了本发明第二实施例所述系统的结构示意图，如图2，第二实施例所述系统200包括：守护策略配置模块210、守护策略管理模块220、第一守护执行模块230和第二守护执行模块240。其中：\n[0050] 守护策略配置模块210，用于使用户设置需要守护应用服务器的守护策略，该守护策略包括：需要守护哪些应用服务器的运行进程、每一应用服务器的运行进程发生异常时的判断条件、以及每一应用服务器的运行进程发生异常时的解决方式等。\n[0051] 对于应用服务器的运行进程发生异常的判断条件可以为：\n[0052] 1)应用服务器的硬件资源消耗，超过一设定阈值达到一预定时间以上，如设定中央处理器CPU或内存消耗都是100％的情况超过十分钟以上时，判定为异常情况；设定中央处理器CPU或内存消耗都是90％的情况超过五分钟以上时，判定为异常情况；不同的应用服务器可以设定不同判断条件；\n[0053] 2)应用服务器的硬件资源消耗，超过一设定阈值达到一预定时间以上，且向应用服务器发送心跳，应用服务器没有回应，以避免根据上述情况1)发生的误判情况；\n[0054] 3)向应用服务器发送心跳连续超过一设定次数，均未收到应答，如连续发送三次心跳无应答；\n[0055] 4)应用服务器正在处理的请求积压超过一设定数量；或者\n[0056] 5)应用服务器的正在运行进程不完全，不是所有进程。\n[0057] 当配置设定上述的判断条件，检测到应用服务器运行中出现上述中的任何一个情况时，均认为应用服务器发生异常。\n[0058] 熟知本领域技术的普通技术人员可以理解，在不同运行环境下的应用服务器或不同的系统要求下，判定异常发生的条件可能不同，因此所配置的守护策略，并不限于上述的几个判断条件。\n[0059] 守护策略管理模块220，用于从守护策略配置模块210读取并保存已经配置的守护策略，使用户能够对所设置守护策略进行管理，另外还提供动态增、减守护策略的通道，使用户能够对守护策略进行修改。\n[0060] 向一系统输入数据资料，通过该系统读取并管理该数据资料，以及利用该数据资料作为某一环境的判断条件，实现该些步骤的具体方式均为本领域技术人员熟知的技术，也即本领域技术人员根据本发明，能够完成本发明所述系统的守护策略配置模块210和守护策略管理模块220所要实现的功能，具体的实现方式在此就不再赘述。\n[0061] 第一守护执行模块230，用于从守护策略管理模块220获取守护策略，根据该守护策略，实时监测所述应用服务器的运行进程状态，并当所述应用服务器发生异常时，根据所述守护策略设定的方式，解决所述应用服务器的异常问题。\n[0062] 为实现上述功能，如图3，该第一守护执行模块230可以包括获取单元231、监测单元232、判断单元233和执行单元234，各单元实现的功能为：\n[0063] 获取单元231，用于从守护策略管理模块220获取需要守护应用服务器的守护策略；\n[0064] 监测单元232，用于实时监测所述应用服务器的状态；\n[0065] 判断单元233，用于将所述应用服务器的状态与所述守护策略设定的判断条件进行比较，判断所述应用服务器是否发生异常；\n[0066] 执行单元234，用于根据所述守护策略设定的方式，解决所述应用服务器的异常问题。\n[0067] 该第一守护执行模块230解决应用服务器的异常问题的具体方式可以为：\n[0068] 例如，当设定应用服务器的CPU和内存占有率在十分钟以上都是100％，同时向应用服务器发送心跳信息，应用服务器没有回应时，守护策略设定的解决方式是重启应用服务器，第一守护执行模块230根据该配置的守护策略，检测到应用服务器出现上述情况时，则认为应用服务器不具备服务能力，通过重启应用服务器使应用服务器恢复正常；\n[0069] 另外，该种异常问题发生时，也可以采用查找服务器中正在运行可以关闭，但不影响服务器运行业务的无关应用进程，将其关闭的形式，或者其他可以降低负载，但不影响服务器业务处理的方式，使应用服务器恢复正常。具体根据守护策略设定的方式执行。\n[0070] 当向应用服务器发送心跳信息，连续超过三次无应答，守护策略设定的解决方式是重启应用服务器，第一守护执行模块230根据该配置的守护策略，检测到应用服务器出现上述情况时，则认为应用服务器异常，通过重启应用服务器使应用服务器恢复正常；\n[0071] 当探测应用服务器的所有进程，有一或多个运行进程不存在，守护策略设定的解决方式是启动该进程时，第一守护执行模块230根据该配置的守护策略，检测到应用服务器出现上述情况时，启动未运行的进程。\n[0072] 上述的守护策略可以设置为默认形式。\n[0073] 另外，第一守护执行模块230能够与应用服务器进行接口连接，以使第一守护执行模块230能够实时检测应用服务器的运行进程状态，该具体的实现方式应该为本领域技术人员的常用技术手段，如利用现有技术的JMX技术(JavaManagement Extensions，即Java管理扩展技术)，为应用服务器植入管理功能，并从应用服务器获取信息；或者采用C语言建立JAVA接口的技术，用C语言实现底层的读取应用服务器的信息，然后将其封转成动态链接库，Java利用JNI接口调用C语言的动态库，即可获取服务器信息。上述的技术方式均能够实现第一守护执行模块230的功能，在此不再赘述。\n[0074] 第二守护执行模块240，用于实时监测第一守护执行模块230的运行状态，当第一守护执行模块230的运行发生异常时，重启第一守护执行模块230。第二守护执行模块240实现该功能，具体也可以分别由监测单元、判断单元和执行单元完成。\n[0075] 此外，第一守护执行模块230还用于实时监测第二守护执行模块240的运行状态，当第二守护执行模块240的运行发生异常时，重启第二守护执行模块240。\n[0076] 第一守护执行模块230由获取单元、监测单元、判断单元和执行单元构成时，也即监测单元232还用于实时监测第二守护执行模块240的运行状态；判断单元233，还用于判断第二守护执行模块240的运行是否发生异常；执行单元234，还用于当第二守护执行模块\n240发生异常时，重启第二守护执行模块240。\n[0077] 本发明所述系统通过第一守护执行模块230和第二守护执行模块240相互监测守护，确保了本发明所述系统的运行稳定性，在操作系统不宕机时，永远有效，保证被守护的应用服务器能够持续对外提供服务；同时，用户能够根据所需要守护的不同应用服务器的进程动态地配置守护策略，应用不限于具体的哪个应用服务或软件，而是可以同时应用于守护多个应用服务器进程或软件。\n[0078] 本发明具体实施例所述系统与应用服务器可以安装在同一计算机上，对该计算机上的多个应用服务器的运行进程进行守护。所述系统也可以与应用服务器分别安装在不同计算机，通过远程传输命令的方式守护设置在远端的多个应用服务器。另外，本发明具体实施例所述系统可以设置为操作系统的默认启动项，当操作系统启动时，自动运行启动本发明所述系统。\n[0079] 图4显示了本发明第二实施例所述系统在计算机上启动的流程示意图。参阅图4，该启动过程从步骤S401开始，包括：\n[0080] 步骤S402，操作系统启动；\n[0081] 步骤S403，启动第一守护执行模块230；\n[0082] 步骤S404，守护策略管理模块220读取守护策略；\n[0083] 步骤S405，启动第二守护执行模块240；\n[0084] 步骤S406，第一守护执行模块230检测应用服务器的运行进程；\n[0085] 步骤S407，判定应用服务器的运行进程是否已启动，若判断结果为是，则运行步骤S408，若判断结果为否，则运行步骤S409；\n[0086] 步骤S408，第一守护执行模块230实时检测应用服务器的运行进程的状态，以及与第二守护执行模块240相互守护；\n[0087] 步骤S409，启动应用服务器的运行进程；\n[0088] 步骤S410，结束。\n[0089] 通过本发明具体实施例所述系统的上述启动过程，第一守护执行模块230和第二守护执行模块240相互看护，双发探测彼此是否存活，如果发现对方未存活，启动之。第一守护执行模块230实时检测应用服务器的运行进程是否存活，如果未存活，启动应用服务器的进程；同时第一守护执行模块230实时检测应用服务器的进程运行是否正常，如果出现异常，则根据守护策略，解决该异常问题。\n[0090] 所述系统能够对所设定的多个应用服务器的进程进行实时守护，且确保应用服务器的各运行进程不间断提供服务。\n[0091] 本发明具体实施例另一方面还提供了一种用于应用服务进程守护的方法，图5示出了本发明第一实施例所述方法的流程图，包括步骤：\n[0092] S501，第一守护执行模块实时监测需要守护应用服务器的状态，当判断所述应用服务器发生异常时，解决所述应用服务器的异常问题；\n[0093] S502，第二守护执行模块实时监测所述第一守护执行模块的状态，当判断所述第一守护执行模块的运行发生异常时，重启所述第一守护执行模块。\n[0094] S503，所述第一守护执行模块还实时监测所述第二守护执行模块的状态，当判断所述第二守护执行模块的运行发生异常时，重启所述第二守护执行模块。\n[0095] 所述方法中，通过第一守护执行模块和第二守护执行模块相互守护，确保了用于应用服务进程守护的系统运行稳定性，在操作系统不宕机时，永远有效，保证被守护的应用服务器能够持续对外提供服务。\n[0096] 本发明所述用于应用服务进程守护的方法，第一守护执行模块向应用服务器提供进程守护的方式，可以依据预先设定的守护策略进行，图6示出了第一守护执行模块进行应用服务器进程守护过程的流程图，包括步骤：\n[0097] S601，用户通过守护策略配置模块设置所述守护策略；\n[0098] S602，用户通过守护策略管理模块读取已经配置的守护策略，对守护策略进行修改；\n[0099] S603，第一守护执行模块获取需要守护应用服务器的守护策略；\n[0100] S604，第一守护执行模块实时监测应用服务器的状态；\n[0101] S605，第一守护执行模块将应用服务器的状态与守护策略进行比较，判断应用服务器是否发生异常；\n[0102] S606，第一守护执行模块根据所述守护策略设定的方式，解决应用服务器的异常问题。\n[0103] 本发明具体实施例所述方法中，所需要配置的守护策略包括：需要守护应用服务器的哪些运行进程、应用服务器的运行进程发生异常时的判断条件、和/或应用服务器的运行进程发生异常时的解决方式等。\n[0104] 对于应用服务器的运行进程发生异常的判断条件可以为：\n[0105] 1)应用服务器的硬件资源消耗，超过一设定阈值的时间达到一预定时间，如设定中央处理器CPU或内存的消耗都是100％达到十分钟以上时判定为异常情况；\n[0106] 2)应用服务器的硬件资源消耗，超过一设定阈值的时间达到一预定时间，且向应用服务器发送心跳，应用服务器没有回应；\n[0107] 3)向应用服务器发送心跳连续超过一设定次数，均未收到应答，如连续发送三次心跳无应答；\n[0108] 4)应用服务器正在处理的请求积压超过一设定数量；或者\n[0109] 5)应用服务器的正在运行进程不完全，不是所有进程。\n[0110] 当配置设定上述的判断条件，第一守护执行模块检测到应用服务器运行中出现上述中的任何一个情况时，均认为应用服务器发生异常，可以采用重启应用服务器或关闭应用服务器的一或多个运行进程的形式解决上述异常问题。\n[0111] 本发明具体实施例所述方法，通过上述图6的步骤，使用户具体根据所需要守护的不同应用服务器进程设定不同守护策略，其应用不限于具体的哪个应用服务或软件，而是可以同时应用于守护多个应用服务器进程或软件。\n[0112] 以上所述仅是本发明的优选实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本发明原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本发明的保护范围。