一种基于安腾Linux应用容器的J2EE应用虚拟化管理方法

1.一种基于安腾Linux应用容器的J2EE应用虚拟化管理方法，其特征在于：采用C/S架构，资源节点为客户端，管理节点为服务端，通过以太网实现客户端与服务端相互通信；利用通信算法、动态部署算法、故障迁移算法实现对多个资源节点的统一管理，将资源节点划分为多个应用容器，动态部署J2EE应用，实现J2EE应用的虚拟化管理；对基于安腾Linux应用容器中的J2EE应用进行动态部署、统一实时监控和故障迁移；该方法包括虚拟资源分布式管理架构（1）、通信算法（2）、动态部署算法（3）和故障迁移算法（4）；
通过虚拟资源分布式管理架构可以统一管理多个虚拟资源池，一个资源节点对应一个虚拟资源池，J2EE应用动态部署在虚拟资源池，不但能监控虚拟资源池中J2EE应用的健康状况，还能迁移到另一个虚拟资源池，提供故障迁移功能；
所述通信算法包含以下步骤：
1）服务端检测所有拟监控客户端心跳信号；
1.1）有拟监控客户端心跳信号未被检测到，结束算法并返回信息；
1.2）所有拟监控客户端心跳信号均被检测到，执行步骤2）；
2）服务端向客户端发送监控策略文件；
3）客户端向服务端反馈是否成功收到监控策略文件；
3.1）客户端未成功收到监控策略文件，执行步骤2）；
3.2）客户端3次未成功收到监控策略文件，结束算法并返回信息；
3.3）客户端成功接收监控策略文件，执行步骤4）；
4）客户端按照监控策略文件检查是否所有拟监控的应用容器、中间件和J2EE应用全部运行正常；
4.1）有拟监控的应用容器、中间件或J2EE应用运行异常或未运行，结束算法并返回信息；
4.2）所有拟监控的应用容器、中间件和J2EE应用全部正常运行，执行步骤5）；
5）客户端向服务端反馈就绪信号；
6）服务端启动连续监控模式，同时指示客户端启动连续监控模式；
7）客户端每隔固定时间间隔收集所有被监控的应用容器、中间件和J2EE应用的运行状态，在客户端形成运行状态日志，并根据监控策略向服务端发送需要的运行状态信息，收集运行状态的时间间隔亦由监控策略决定；
8）服务端持续监控由客户端发送的所有被监控的应用容器、中间件和J2EE应用的运行状态信息；
9）服务端监控到有应用容器、中间件或J2EE应用运行异常或丢失客户端心跳N次，N由监控策略决定；
10）服务端根据监控策略决定是否启动故障恢复；
10.1）监控策略为启动故障恢复，服务端启动故障恢复，同时保证对正常运行的应用容器、中间件和J2EE应用的持续监控；
10.2）监控策略为不启动故障恢复，服务端以固定时间间隔向用户反馈故障信息，同时保证对正常运行的应用容器、中间件和J2EE应用的持续监控；
11）服务端收到用户手动下达的停止统一实时监控指令，则结束服务端和客户端的持续监控，仅保留客户端的心跳信号；
12）算法结束；
所述动态部署算法包含以下步骤：
1）服务端收到用户下达的J2EE动态部署指令；
2）服务端收集动态部署策略、J2EE应用安装包路径，生成J2EE应用安装包校验文件；
3）服务端检测所有拟部署客户端的心跳信号；
3.1）有拟部署客户端心跳信号未被检测到，结束算法并返回信息；
3.2）所有拟部署客户端心跳信号均被检测到，执行步骤4）；
4）服务端指示客户端收集应用容器、中间件和J2EE应用安装信息，并反馈至服务端；
5）服务端将客户端收集并反馈的应用容器、中间件安装信息与动态部署策略进行对比；
5.1）二者不一致，结束动态部署并反馈信息；
5.2）二者一致，执行步骤6）；
6）服务端将客户端反馈的J2EE应用安装信息与动态部署策略进行对比；
7）服务端根据对比结果创建应用部署列表及部署配置文件；
8）服务端根据应用部署列表将部署配置文件、J2EE应用安装包和J2EE应用安装包校验文件发送至客户端；
9）客户端根据J2EE应用安装包校验文件校验J2EE应用安装包；
9.1）校验失败，客户端要求服务端重新发送校验失败的J2EE应用安装包及其校验文件；
9.2）同一文件校验失败3次，结束部署并返回信息；
9.3）全部校验成功，执行步骤10）；
10）客户端根据部署配置文件动态部署J2EE应用并反馈部署进度信息；
11）客户端完成部署后向服务端反馈信息；
12）服务端向用户显示部署完成信息，等待用户结束动态部署任务；
所述故障迁移算法包含以下步骤：
1）启动故障迁移算法；
2）根据故障类型启动不同的流程；
2.1）故障类型为应用故障，中间件、应用容器运行正常，执行步骤3）；
2.2）故障类型为中间件故障，应用容器运行正常，执行步骤4）；
2.3）故障类型为应用容器故障，执行步骤5）；
3）启动应用故障恢复流程；
3.1）尝试重启应用；
3.11）重启成功，返回信息并结束故障迁移算法；
3.12）重启不成功，执行步骤3.2）；
3.2）服务端根据客户端定时反馈的信息，筛选出所有安装有相同中间件的应用容器，该应用容器可以与故障应用所在应用容器位于同一操作系统或主机，也可以位于其他的操作系统或主机；
3.21）不存在安装有相同中间件的应用容器，结束故障恢复流程并返回信息；
3.22）存在安装有相同中间件的应用容器，执行步骤3.3）；
3.3）服务端在筛选出的应用容器选择系统资源余量最大的应用容器；
3.4）服务端发送故障应用安装包至被步骤3.3）选择的应用容器所在操作系统的客户端；
3.5）步骤3.4）所述客户端将接收到的故障应用安装包安装在步骤3.3）所述的应用容器；
3.6）步骤3.4）所述客户端启动应用；
3.7）步骤3.4）所述客户端反馈部署信息与启动信息；
3.8）服务端接收到部署信息与启动信息后结束故障迁移算法；
4）启动中间件故障恢复流程；
4.1）服务端根据客户端定时反馈的信息，筛选出所有安装有相同中间件的应用容器，该应用容器可以与故障中间件所在应用容器位于同一操作系统或主机，也可以位于其他的操作系统或主机；
4.11）不存在安装有相同中间件的应用容器，结束故障恢复流程并返回信息；
4.12）存在安装有相同中间件的应用容器，执行步骤4.2）；
4.2）服务端比较筛选出的应用容器的系统资源余量；
4.3）服务端根据负载均衡原则，将因中间件故障导致的故障应用的安装包批量分发至步骤4.1筛选出的应用容器所在操作系统的客户端；
4.4）步骤4.3）所述客户端将接收到的故障应用安装包安装在对应的应用容器中；
4.5）步骤4.3）所述客户端启动应用；
4.6）步骤4.3）所述客户端反馈部署信息与启动信息；
4.7）服务端接收到部署信息与启动信息后结束故障迁移算法；
5）启动应用容器故障恢复流程；
5.1）服务端确定安装于故障应用容器上的中间件与应用；
5.2）服务端判断故障应用容器上的中间件是否有一些安装在其他正常运行的应用容器上；
5.21）否，结束故障恢复流程并返回信息；
5.22）是，执行步骤5.3）；
5.3）服务端将目前正常运行的应用容器中已安装步骤5.1）所述中间件的进行汇总，统计步骤5.1）所述应用中能够部署在其他应用容器的部分，根据负载均衡原则创建部署列表；
5.4）服务端将步骤5.3）所述应用的安装包分发至步骤5.3所述的应用容器所在操作系统的客户端；
5.5）步骤5.4）所述客户端将接收到的故障应用安装包安装在对应的应用容器中；
5.6）步骤5.4）所述客户端启动应用；
5.7）步骤5.4）所述客户端反馈部署信息与启动信息；
5.8）服务端接收到部署信息与启动信息后结束故障迁移算法，并返回故障应用、已恢复应用、未恢复应用的信息。
2.根据权利要求1所述的一种基于安腾Linux应用容器的J2EE应用虚拟化管理方法，其特征在于：服务端由交互模块、管理模块、分发模块、故障恢复模块、通信模块组成，其中交互模块第一输入/输出端与管理模块第一输入/输出端连接，分发模块第一输入/输出端与交互模块第二输入/输出端连接，故障恢复模块的第一输入/输出端与管理模块第二输入/输出端连接，通信模块第一输入/输出端与管理模块第三输入/输出端连接，分发模块第二输入/输出端与通信模块第二输入/输出端连接，故障恢复模块的第二输入/输出端与通信模块第三输入/输出端连接。
3.根据权利要求2所述的一种基于安腾Linux应用容器的J2EE应用虚拟化管理方法，其特征在于：所述分发模块执行所述的动态部署算法。
4.根据权利要求2所述的一种基于安腾Linux应用容器的J2EE应用虚拟化管理方法，其特征在于：所述故障恢复模块执行所述的故障迁移算法。
5.根据权利要求2所述的一种基于安腾Linux应用容器的J2EE应用虚拟化管理方法，其特征在于：所述管理模块执行所述的通信算法。
6.根据权利要求2所述的一种基于安腾Linux应用容器的J2EE应用虚拟化管理方法，其特征在于：客户端由通信模块、管理模块、监视模块、部署模块构成，其中通信模块第一输入/输出端与管理模块第一输入/输出端连接，监视模块第一输入/输出端与管理模块第二输入/输出端连接，部署模块第一输入端与管理模块第三输出端连接，部署模块第二输出端口与通信模块第三输入端口连接，监视模块第二输出端口与通信模块第二输入端口连接。
7.根据权利要求6所述的一种基于安腾Linux应用容器的J2EE应用虚拟化管理方法，其特征在于：服务端通信模块的第四输入/输出端与客户端通信模块的第四输入/输出端通过以太网连接。

一种基于安腾Linux应用容器的J2EE应用虚拟化管理方法\n技术领域\n[0001] 本发明涉及IT基础设施上具体应用的统一集中管理，特别涉及基于安腾Linux应用容器的J2EE应用虚拟化的统一集中管理。\n[0002] 技术背景\n[0003] 近年来，各行各业的信息化程度不断提高，IT基础设施的规模和承载的业务量也急剧增大，同时，IT技术飞速发展，使平台性能越来越高，同时升级换代频率也越来越快，因此，各方面对IT基础设施成本、平台使用效率以及应用可移植性的重视程度越来越高。与UNIX平台相比，Linux平台成本更低，致使在小型机领域，安腾Linux平台已占有一定的市场份额；虚拟化技术能够有效提升平台使用效率，对于Linux平台来说，应用容器在运行效能和成本方面均有优势，特别是基于安腾（Itanium）处理器的Linux平台，应用容器的效率和成熟度很高，被广泛使用；而得益于JAVA的跨平台特性，J2EE应用具备非常高的可移植性，大量的应用均基于JAVA开发。所以，基于安腾Linux平台“J2EE应用-中间件-Linux应用容器”虚拟化框架构建的应用服务器越来越多，若用户业务量很大，这种应用服务器数量将会非常可观。\n[0004] 基于Linux应用容器的J2EE应用是分散的，当应用服务器数量较大时，大量的、分散的J2EE应用给监控、部署、故障迁移等方面带来了难题。首先，Linux应用容器缺乏集中的、统一的监控手段，在安腾Linux平台上尤为突出，目前基于安腾Linux应用容器的J2EE应用多为人工管理，需要大量的人工成本；其次，在J2EE应用和应用服务器数量较少时，可以使用人工部署，但当数量较多时，人工部署非常的耗时，因此需要一种智能的、自动的动态部署技术；最后，用户希望其业务具备连续性，对于核心应用和数据库，可采用价格昂贵的高可用方案，然而对于一些非核心应用，高可用方案势必造成浪费。目前尚无在安腾Linux平台上较好的解决上述问题的方法或技术。\n发明内容\n[0005] 本发明的目的在于提供一种基于安腾Linux应用容器的J2EE应用虚拟化管理方法，该系统能够实现对分布在不同应用服务器、不同安腾Linux应用容器的大量J2EE应用的集中、统一监控；实现对不同应用服务器、不同安腾Linux应用容器的大量J2EE应用的动态部署；根据对不同应用服务器、不同安腾Linux应用容器的大量J2EE应用集中、统一监控所得的故障信息，实现故障迁移。\n[0006] 本发明的目的通过以下技术方案实现：\n[0007] 一种基于安腾Linux应用容器的J2EE应用虚拟化管理方法，采用C/S架构，资源节点为客户端，管理节点为服务端，通过以太网实现客户端与服务端相互通信；利用通信算法、动态部署算法、故障迁移算法实现对多个资源节点的统一管理，将资源节点划分为多个应用容器，动态部署J2EE应用，实现J2EE应用的虚拟化管理；对基于安腾Linux应用容器中的J2EE应用进行动态部署、统一实时监控和故障迁移；该方法包括虚拟资源分布式管理架构（1）、通信算法（2）、动态部署算法（3）和故障迁移算法（4）。\n[0008] 通过虚拟资源分布式管理架构可以统一管理多个虚拟资源池，一个资源节点对应一个虚拟资源池，J2EE应用动态部署在虚拟资源池，不但能监控虚拟资源池中J2EE应用的健康状况，还能迁移到另一个虚拟资源池，提供故障恢复功能。\n[0009] 服务端由交互模块、管理模块、分发模块、故障恢复模块、通信模块组成，其中交互模块第一输入/输出端与管理模块第一输入/输出端连接，分发模块第一输入/输出端与交互模块第二输入/输出端连接，故障恢复模块的第一输入/输出端与管理模块第二输入/输出端连接，通信模块第一输入/输出端与管理模块第三输入/输出端连接，分发模块第二输入/输出端与通信模块第二输入/输出端连接，故障恢复模块的第二输入/输出端与通信模块第三输入/输出端连接。\n[0010] 所述的一种基于安腾Linux应用容器的J2EE应用虚拟化管理方法，其所述分发模块执行所述的动态部署算法。\n[0011] 所述的一种基于安腾Linux应用容器的J2EE应用虚拟化管理方法，其所述故障恢复模块执行所述的故障迁移算法。\n[0012] 所述的一种基于安腾Linux应用容器的J2EE应用虚拟化管理方法，其所述管理模块执行所述的通信算法。\n[0013] 所述的一种基于安腾Linux应用容器的J2EE应用虚拟化管理方法，其客户端由通信模块、管理模块、监视模块、部署模块构成，其中通信模块第一输入/输出端与管理模块第一输入/输出端连接，监视模块第一输入/输出端与管理模块第二输入/输出端连接，部署模块第一输入端与管理模块第三输出端连接，部署模块第二输出端口与通信模块第三输入端口连接，监视模块第二输出端口与通信模块第二输入端口连接。\n[0014] 所述的一种基于安腾Linux应用容器的J2EE应用虚拟化管理方法，其服务端通信模块的第四输入/输出端与客户端通信模块的第四输入/输出端通过以太网连接。\n[0015] 所述通信算法包含以下步骤：\n[0016] 1）服务端检测所有拟监控客户端心跳信号；\n[0017] 1.1）有拟监控客户端心跳信号未被检测到，结束算法并返回信息；\n[0018] 1.2）所有拟监控客户端心跳信号均被检测到，执行步骤2）；\n[0019] 2）服务端向客户端发送监控策略文件；\n[0020] 3）客户端向服务端反馈是否成功收到监控策略文件；\n[0021] 3.1）客户端未成功收到监控策略文件，执行步骤2）；\n[0022] 3.2）客户端3次未成功收到监控策略文件，结束算法并返回信息；\n[0023] 3.3）客户端成功接收监控策略文件，执行步骤4）；\n[0024] 4）客户端按照监控策略文件检查是否所有拟监控的应用容器、中间件和J2EE应用全部运行正常；\n[0025] 4.1）有拟监控的应用容器、中间件或J2EE应用运行异常或未运行，结束算法并返回信息；\n[0026] 4.2）所有拟监控的应用容器、中间件和J2EE应用全部正常运行，执行步骤5）；\n[0027] 5）客户端向服务端反馈就绪信号；\n[0028] 6）服务端启动连续监控模式，同时指示客户端启动连续监控模式；\n[0029] 7）客户端每隔固定时间间隔收集所有被监控的应用容器、中间件和J2EE应用的运行状态，在客户端形成运行状态日志，并根据监控策略向服务端发送需要的运行状态信息，收集运行状态的时间间隔亦由监控策略决定；\n[0030] 8）服务端持续监控由客户端发送的所有被监控的应用容器、中间件和J2EE应用的运行状态信息；\n[0031] 9）服务端监控到有应用容器、中间件或J2EE应用运行异常或丢失客户端心跳N次，N由监控策略决定；\n[0032] 10）服务端根据监控策略决定是否启动故障恢复；\n[0033] 10.1）监控策略为启动故障恢复，服务端启动故障恢复，同时保证对正常运行的应用容器、中间件和J2EE应用的持续监控；\n[0034] 10.2）监控策略为不启动故障恢复，服务端以固定时间间隔向用户反馈故障信息，同时保证对正常运行的应用容器、中间件和J2EE应用的持续监控；\n[0035] 11）服务端收到用户手动下达的停止统一实时监控指令，则结束服务端和客户端的持续监控，仅保留客户端的心跳信号；\n[0036] 12）算法结束；\n[0037] 所述动态部署算法包含以下步骤：\n[0038] 1）服务端收到用户下达的J2EE动态部署指令；\n[0039] 2）服务端收集动态部署策略、J2EE应用安装包路径，生成J2EE应用安装包校验文件；\n[0040] 3）服务端检测所有拟部署客户端的心跳信号；\n[0041] 3.1）有拟部署客户端心跳信号未被检测到，结束算法并返回信息；\n[0042] 3.2）所有拟部署客户端心跳信号均被检测到，执行步骤4）；\n[0043] 4）服务端指示客户端收集应用容器、中间件、J2EE应用安装信息，并反馈至服务端；\n[0044] 5）服务端将客户端并反馈的收集的应用容器、中间件安装信息与动态部署策略进行对比；\n[0045] 5.1）二者不一致，结束动态部署并反馈信息；\n[0046] 5.2）二者一致，执行步骤6）；\n[0047] 6）服务端将客户端反馈的J2EE应用安装信息与动态部署策略进行对比；\n[0048] 7）服务端根据对比结果创建应用部署列表及部署配置文件；\n[0049] 8）服务端根据应用部署列表将部署配置文件、J2EE应用安装包、J2EE应用安装包校验文件发送至客户端；\n[0050] 9）客户端根据J2EE应用安装包校验文件校验J2EE应用安装包；\n[0051] 9.1）校验失败，客户端要求服务端重新发送校验失败的J2EE应用安装包及其校验文件；\n[0052] 9.2）统一文件校验失败3次，结束部署并返回信息；\n[0053] 9.3）全部校验成功，执行步骤10）；\n[0054] 10）客户端根据部署配置文件动态部署J2EE应用并反馈部署进度信息；\n[0055] 11）客户端完成部署后向服务端反馈信息；\n[0056] 12）服务端向用户显示部署完成信息，等待用户结束动态部署任务。\n[0057] 述故障迁移算法包含以下步骤：\n[0058] 1）启动故障迁移算法；\n[0059] 2）根据故障类型启动不同的流程；\n[0060] 2.1）故障类型为应用故障，中间件、应用容器运行正常，执行步骤3）；\n[0061] 2.2）故障类型为中间件故障，应用容器运行正常，执行步骤4）；\n[0062] 2.3）故障类型为应用容器故障，执行步骤5）；\n[0063] 3）启动应用故障恢复流程；\n[0064] 3.1）尝试重启应用；\n[0065] 3.11）重启成功，返回信息并结束故障迁移算法；\n[0066] 3.12）重启不成功，执行步骤3.2）\n[0067] 3.2）服务端根据客户端定时反馈的信息，筛选出所有安装有相同中间件的应用容器，该应用容器可以与故障应用所在应用容器位于同一操作系统或主机，也可以位于其他的操作系统或主机；\n[0068] 3.21）不存在安装有相同中间件的应用容器，结束故障恢复流程并返回信息；\n[0069] 3.22）存在安装有相同中间件的应用容器，执行步骤3.3）\n[0070] 3.3）服务端在筛选出的应用容器选择系统资源余量最大的应用容器；\n[0071] 3.4）服务端发送故障应用安装包至被步骤3.3）选择的应用容器所在操作系统的客户端；\n[0072] 3.5）步骤3.4）所述客户端将接收到的故障应用安装包安装在步骤3.3）所述的应用容器；\n[0073] 3.6）步骤3.4）所述客户端启动应用；\n[0074] 3.7）步骤3.4）所述客户端反馈部署信息与启动信息；\n[0075] 3.8）服务端接收到部署信息与启动信息后结束故障迁移算法；\n[0076] 4）启动中间件故障恢复流程；\n[0077] 4.1）服务端根据客户端定时反馈的信息，筛选出所有安装有相同中间件的应用容器，该应用容器可以与故障中间件所在应用容器位于同一操作系统或主机，也可以位于其他的操作系统或主机；\n[0078] 4.11）不存在安装有相同中间件的应用容器，结束故障恢复流程并返回信息；\n[0079] 4.12）存在安装有相同中间件的应用容器，执行步骤4.2）；\n[0080] 4.2）服务端比较筛选出的应用容器的系统资源余量；\n[0081] 4.3）服务端根据负载均衡原则，将因中间件故障导致的故障应用的安装包批量分发至步骤4.1筛选出的应用容器所在操作系统的客户端；\n[0082] 4.4）步骤4.3）所述客户端将接收到的故障应用安装包安装在对应的应用容器中；\n[0083] 4.5）步骤4.3）所述客户端启动应用；\n[0084] 4.6）步骤4.3）所述客户端反馈部署信息与启动信息；\n[0085] 4.7）服务端接收到部署信息与启动信息后结束故障迁移算法；\n[0086] 5）启动应用容器故障恢复流程；\n[0087] 5.1）服务端确定安装于故障应用容器上的中间件与应用；\n[0088] 5.2）服务端判断故障应用容器上的中间件是否有一些安装在其他正常运行的应用容器上;\n[0089] 5.21）否，结束故障恢复流程并返回信息；\n[0090] 5.22）是，执行步骤5.3）；\n[0091] 5.3）服务端将目前正常运行的应用容器中已安装步骤5.1）所述中间件的进行汇总，统计步骤5.1）所述应用中能够部署在其他应用容器的部分，根据负载均衡原则创建部署列表；\n[0092] 5.4）服务端将步骤5.3）所述应用的安装包分发至步骤5.3）所述的应用容器所在操作系统的客户端；\n[0093] 5.5）步骤5.4）所述客户端将接收到的故障应用安装包安装在对应的应用容器中；\n[0094] 5.6）步骤5.4）所述客户端启动应用；\n[0095] 5.7）步骤5.4）所述客户端反馈部署信息与启动信息；\n[0096] 5.8）服务端接收到部署信息与启动信息后结束故障迁移算法，并返回故障应用、已恢复应用、未恢复应用的信息。\n[0097] 实现对分布在不同应用服务器、不同安腾Linux应用容器的大量J2EE应用的集中、统一监控；实现对不同应用服务器、不同安腾Linux应用容器的大量J2EE应用的动态部署；\n根据对不同应用服务器、不同安腾Linux应用容器的大量J2EE应用集中、统一监控所得的故障信息，实现故障迁移。该发明能够填补目前市场上安腾Linux应用容器的J2EE应用虚拟化统一自动管理的空白。\n[0098] 该发明为一套IT基础设施管理系统，用于管理基于安腾Linux平台的J2EE应用，一定程度上填补了业界空白，是公司现有K1管理系统的有力补充，能够有效增加K1平台及基于K1平台项目的竞争力，能够提升应用能力。\n[0099] 、附图说明\n[0100] 附图1为权利要求1所述的Linux应用容器中J2EE应用的统一管理系统架构图；\n[0101] 附图2为监控流程图；\n[0102] 附图3为动态部署流程图；\n[0103] 附图4为故障恢复流程图。\n[0104] 、实施方式\n[0105] 结合一下实例对本发明做进一步说明。\n[0106] 实施例1\n[0107] 本实例的Linux应用容器中J2EE应用的统一管理系统，可结合附图1、附图2理解本实例，本实例包括以下步骤：\n[0108] 1）用户通过交互模块（1）中输入监控策略后下达“开始监控”指令；\n[0109] 2)交互模块（1）根据用户输入的监控策略，形成监控策略文件，并发给管理模块（2），同时向管理模块发送“开始监控”指令；\n[0110] 3）管理模块（2）启动监控算法； 4）管理模块（2）根据监控策略文件，通过通信模块（5）检测拟监控的客户端心跳；\n[0111] 4.1）有拟监控客户端心跳未能检测到，结束监控流程并通过交互模块（1）返回信息给用户；\n[0112] 4.2）所有拟监控客户端心跳均成功检测到，执行步骤5）；\n[0113] 5）管理模块（2）通过通信模块（5）向客户端发送监控策略文件；\n[0114] 6）管理模块（7）检查通信模块（6）是否收到监控策略文件；\n[0115] 6.1）通信模块（5）未成功收到监控策略文件，执行步骤5）；\n[0116] 6.2）通信模块（5）3次未成功收到监控策略文件，结束算法并返回信息；\n[0117] 6.3）通信模块（5）成功接收监控策略文件，执行步骤7）；\n[0118] 7）管理模块（7）按照监控策略文件检查是否所有拟监控的应用容器、中间件和J2EE应用全部运行正常；\n[0119] 7.1）有拟监控的应用容器、中间件或J2EE应用运行异常或未运行，结束算法并返回信息；\n[0120] 7.2）所有拟监控的应用容器、中间件和J2EE应用全部正常运行，执行步骤8）；\n[0121] 8）管理模块（7）通过通信模块（6）向服务端反馈就绪信号；\n[0122] 9）管理模块（2）通过通信模块（5）收到管理模块（7）反馈的就绪信号后，启动连续监控模式，同时通过通信模块（5）指示客户端启动连续监控模式；\n[0123] 10）管理模块（7）通信模块（6）收到启动连续监控模式指令后，指示监听模块（8）每隔固定时间间隔收集所有被监控的应用容器、中间件和J2EE应用的运行状态，并将运行状态信息发送给管理模块（7），管理模块（7）在客户端形成运行状态日志，并根据监控策略通过通信模块（6）向服务端发送需要的运行状态信息，收集运行状态的时间间隔亦由监控策略决定；\n[0124] 11）管理模块（2）通过通信模块（5）接收管理模块（7）发送的运行状态，并对运行状态进行持续监听；\n[0125] 12）管理模块（2）监听到有应用容器、中间件或J2EE应用运行异常或丢失客户端心跳N次，N由监控策略决定；\n[0126] 13）管理模块（2）根据监控策略决定是否启动故障恢复；\n[0127] 13.1）监控策略为启动故障恢复，管理模块（2）指示故障恢复模块（4）启动故障恢复，同时保证对正常运行的的应用容器、中间件和J2EE应用的持续监控；\n[0128] 13.2）监控策略为不启动故障恢复，管理模块（2）以固定时间间隔通过交互模块（1）向用户反馈故障信息，同时保证对正常运行的的应用容器、中间件和J2EE应用的持续监控；\n[0129] 14）管理模块（2）收到由交互模块（1）送来的用户手动下达停止统一实时监控指令，结束服务端和客户端的持续监控，仅保留客户端的心跳信号；\n[0130] 15）统一实施监控结束。\n[0131] 实施例2\n[0132] 本实例的Linux应用容器中J2EE应用的统一管理系统，可结合附图1、附图3理解本实例，本实例包括以下步骤：\n[0133] 1）用户通过交互模块（1）输入动态部署策略，并下达动态部署指令；\n[0134] 2）交互模块（1）根据用户输入的动态部署策略形成动态部署策略文件，并发送至分发模块，同时向分发模块（3）发送启动动态部署指令；\n[0135] 3）分发模块（3）执行动态部署算法；\n[0136] 4）分发模块（3）根据动态部署策略文件，收集J2EE应用安装包路径，同时生成J2EE安装包校验文件；\n[0137] 5）分发模块（3）检测所有拟部署客户端的心跳信号；\n[0138] 5.1）有拟部署客户端心跳信号未被检测到，结束算法并返回信息；\n[0139] 5.2）所有拟部署客户端心跳信号均被检测到，执行步骤6）；\n[0140] 6）分发模块（3）通过通信模块（5）指示客户端收集应用容器、中间件、J2EE应用安装信息，并反馈至服务端；\n[0141] 7）管理模块（7）通过通信模块（6）接收分发模块（3）指示后，指示监听模块（8）收集应用容器、中间件安装信息，管理模块（7）通过通信模块（6）将安装信息发送至服务端；\n[0142] 8）分发模块（3）通过通信模块（5）接收客户端发送的应用容器、中间件安装信息，并与动态部署策略文件对比；\n[0143] 8.1）若客户端发送的应用容器、中间件安装信息与动态部署策略文件要求的应用容器、中间件安装信息不一致，则接收动态部署并反馈信息；\n[0144] 8.2）若客户端发送的应用容器、中间件安装信息与动态部署策略文件要求的应用容器、中间件安装信息一致，执行步骤9）；\n[0145] 9）分发模块（3）将客户端反馈的J2EE应用安装信息与动态部署策略文件进行对比；\n[0146] 10）分发模块（3）根据对比结果创建应用部署列表及部署配置文件；\n[0147] 11）分发模块（3）根据应用部署列表将部署配置文件、J2EE应用安装包、J2EE应用安装包校验文件通过通信模块（5）发送至客户端；\n[0148] 12）管理模块（7）将通过通信模块（6）接受的部署配置文件、J2EE应用安装包、J2EE应用安装包校验文件发送至部署模块（9）；\n[0149] 13）部署模块（9）根据J2EE应用安装包校验文件校验J2EE应用安装包；\n[0150] 13.1）校验失败，部署模块（9）通过通讯模块（6）要求服务端重新发送校验失败的J2EE应用安装包及其校验文件；\n[0151] 13.2）同一文件校验失败3次，结束部署并返回信息；\n[0152] 13.3）全部校验成功，执行步骤14）；\n[0153] 14）部署模块（9）根据部署配置文件动态部署J2EE应用并反馈部署进度信息；\n[0154] 15）部署模块（9）完成部署后通过通信模块（6）向服务端反馈信息；\n[0155] 16）分发模块（3）通过通信模块（5）接收到步骤15）所述的反馈信息后，通过交互模块（1）向用户显示部署完成信息，等待用户结束动态部署任务。\n[0156] 实施例3\n[0157] 本实例的Linux应用容器中J2EE应用的统一管理系统，可结合附图1、附图2、附图4理解本实例，本实例包括以下步骤：\n[0158] 1）用户通过交互模块（1）中输入监控策略后下达“开始监控”指令；\n[0159] 2)交互模块（1）根据用户输入的监控策略，形成监控策略文件，并发给管理模块（2），同时向管理模块发送“开始监控”指令；\n[0160] 3）管理模块（2）启动监控算法； 4）管理模块（2）根据监控策略文件，通过通信模块（5）检测拟监控的客户端心跳；\n[0161] 4.1）有拟监控客户端心跳未能检测到，结束监控流程并通过交互模块（1）返回信息给用户；\n[0162] 4.2）所有拟监控客户端心跳均成功检测到，执行步骤5）；\n[0163] 5）管理模块（2）通过通信模块（5）向客户端发送监控策略文件；\n[0164] 6）管理模块（7）检查通信模块（6）是否收到监控策略文件；\n[0165] 6.1）通信模块（5）未成功收到监控策略文件，执行步骤5）；\n[0166] 6.2）通信模块（5）3次未成功收到监控策略文件，结束算法并返回信息；\n[0167] 6.3）通信模块（5）成功接收监控策略文件，执行步骤7）；\n[0168] 7）管理模块（7）按照监控策略文件检查是否所有拟监控的应用容器、中间件和J2EE应用全部运行正常；\n[0169] 7.1）有拟监控的应用容器、中间件或J2EE应用运行异常或未运行，结束算法并返回信息；\n[0170] 7.2）所有拟监控的应用容器、中间件和J2EE应用全部正常运行，执行步骤8）；\n[0171] 8）管理模块（7）通过通信模块（6）向服务端反馈就绪信号；\n[0172] 9）管理模块（2）通过通信模块（5）收到管理模块（7）反馈的就绪信号后，启动连续监控模式，同时通过通信模块（5）指示客户端启动连续监控模式；\n[0173] 10）管理模块（7）通信模块（6）收到启动连续监控模式指令后，指示监听模块（8）每隔固定时间间隔收集所有被监控的应用容器、中间件和J2EE应用的运行状态，并将运行状态信息发送给管理模块（7），管理模块（7）在客户端形成运行状态日志，并根据监控策略通过通信模块（6）向服务端发送需要的运行状态信息，收集运行状态的时间间隔亦由监控策略决定；\n[0174] 11）管理模块（2）通过通信模块（5）接收管理模块（7）发送的运行状态，并对运行状态进行持续监听；\n[0175] 12）管理模块（2）监听到有应用容器、中间件或J2EE应用运行异常或丢失客户端心跳N次，N由监控策略决定；\n[0176] 13）由于监控策略为启动故障恢复，管理模块（2）指示故障恢复模块（4）启动故障恢复，同时保证对正常运行的的应用容器、中间件和J2EE应用的持续监控；\n[0177] 14）故障恢复模块（4）判断故障类型为应用故障；\n[0178] 15）故障恢复模块（4）启动应用故障恢复流程；\n[0179] 15.1）故障恢复模块（4）通过通信模块（5）指示客户端尝试重启故障应用；\n[0180] 15.2）管理模块（7）将通过通信模块（6）接收到的重启指令发送给部署模块（9）；\n[0181] 15.3）部署模块（9）尝试重启故障应用；\n[0182] 15.31）重启成功，部署模块（9）通过通信模块（6）向服务端发送重启成功信息，故障恢复模块（4）通过通信模块（5）接收到部署模块（9）发送的重启成功信息后，结束故障恢复流程，并向管理模块（2）发送信息，管理模块（2）记录信息至日志文件，并通过交互模块（1）向用户发送信息；\n[0183] 15.32）重启不成功，部署模块（9）通过通信模块（6）向服务端发送重启失败信息，执行步骤15.4）；\n[0184] 15.4）故障恢复模块（4）通过通信模块（5）接收到部署模块（9）发送的重启失败信息后，分析故障应用依赖的中间件，筛选出所有安装有相同中间件的应用容器，该应用容器可以与故障应用所在应用容器位于同一操作系统或主机，也可以位于其他的操作系统或主机；\n[0185] 15.41）不存在安装有相同中间件的应用容器，结束故障恢复流程并返回信息；\n[0186] 15.42）存在安装有相同中间件的应用容器，执行步骤15.5）；\n[0187] 15.5）故障恢复模块（4）筛选出的应用容器选择系统资源余量最大的应用容器；\n[0188] 15.6）故障恢复模块（4）通过通信模块（5）发送故障应用安装包至被步骤15.5）选择的应用容器所在操作系统的客户端；\n[0189] 15.7）管理模块（7）将通过通信模块（6）接收到的故障应用安装包发送给部署模块（9）；\n[0190] 15.8）部署模块（9）安装应用之相应的容器，并通过通信模块（6）想服务端反馈安装进度；\n[0191] 15.9）故障恢复模块（4）通过通信模块（5）接收到）部署模块（9）发送的安装进度信息后，通过交互模块（1）向用户反馈该信息；\n[0192] 15.10）部署模块（9）启动安装完成后的应用，并通过通信模块（6）想服务端反馈启动成功信息；\n[0193] 15.11）故障恢复模块（4）通过通信模块（5）接收到）部署模块（9）发送的启动成功信息后，结束故障迁移算法，并通过交互模块（1）向用户反馈该信息。