CN101968747B - 一种机群应用管理系统及其应用管理方法 - Google Patents

Abstract

本发明涉及一种机群应用管理系统，该系统包括执行引擎模块和数据库模块，数据库模块用于实时地存储各应用的处理结果，并建立监控表，所述监控表中记录多个应用的所有关联应用的处理结果的改变信息；执行引擎模块用于执行机群系统中的各个应用，并将各应用的处理结果实时地写入数据库模块，还用于按照所设定的周期定期读取数据库模块中的所述监控表，每次读取所述监控表后根据所读取的多个应用的处理结果的改变信息，分别判断各应用的触发条件是否已满足，并在触发条件满足时触发相应的应用。本发明还提供了相应的机群应用管理方法。本发明能够减少数据库访问连接数，降低开销；能够处理应用间各种复杂逻辑关系；更加便于管理和操作。

Description

一种机群应用管理系统及其应用管理方法

技术领域

本发明涉及机群计算技术领域，具体地说，本发明涉及一种机群应用管理系统及其应用管理方法。

背景技术

机群是一类并行/分布式处理系统，它由一组高速互联的独立运行的计算机系统组成，这些计算机系统共同工作，表现为统一的、集成的计算资源环境。机群系统自问世以来，以其良好的可扩展性和富有竞争力的性能/价格比，迅速成为高性能计算的主流体系结构，同时机群也在因特网服务、数据库服务等商业领域得到广泛应用，具体包括：联机事务处理(OLTP)、联机分析处理(OLAP)、电子商务、企业信息化管理平台(包括ERP、CRM)、数字图书馆，大型电子邮件系统、综合门户网站和搜索引擎、大型BBS、网络游戏平台、流媒体服务等等。

随着需求的不断增加，机群节点服务器数目和机群系统上所运行的机群应用程序(下文中简称应用)也大幅增加。例如：目前世界最大的搜索引擎Google在世界范围内安装的机群节点服务器已扩展至200,000；而在数据中心中，一个机群系统上可能会部署和运行成千上万个应用。各应用之间往往存在相互依赖的关联关系(如A应用的处理结果可能将作为B应用运行的原始数据)，形成错综复杂的关联关系网络。因此，需要一种高性能大规模的机群应用管理系统作为这千上万个应用的运行的平台，使得各机群应用的运行能够获得良好的组织。

现有的机群应用管理系统主要是通过机群的全局数据库来实现各应用之间的关联关系的。具体地，在机群的全局数据库中为每个应用建立工作表和数据变化监控表，工作表用于写入该应用的处理结果，数据变化监控表用于监视并记录该应用所关联的其它应用的工作表的变化。这样，每个应用定期读取其所对应的数据变化监控表，即可实时地获得所需的其它应用的处理结果，从而实现应用之间的相互关联。举例说明，应用B对于应用A的运行结果感兴趣，应用B就需要实时地获得应用A的工作表TJa的改变情况。应用A的工作表TJa的改变的形式包括：新纪录插入、原有纪录发生更新或是原有记录被删除。现有技术中，为使应用B能够实时地使用应用A的运算结果，通常需要编写工作表TJa的数据库触发器，使应用A的工作表TJa改变时，工作表TJa的数据库触发器将这一改变即时写入应用B的数据变化监控表TMb中，而应用B则定期读取其所对应的监控表TMb，如果发现监控表TMb出现改变的信息，可以触发应用B按改变后的信息进行进一步处理。应用B读取其监控表TMb的读取周期一般为1秒到1分钟，可以看出，应用B的读取周期越短，其处理结果的实时性就越强。

上述传统的机群应用管理系统能够使一个应用能够及时地获得它感兴趣的另一个应用的处理结果，从而实现应用之间的实时关联。然而，当机群系统规模较大时，这种传统的机群应用管理系统暴露出较大的缺陷。首先，大规模的机群往往需要同时运行成百上千个应用，而这些应用之间的依赖关系错综复杂。上述传统的机群应用管理系统中，为实现各应用按其依赖关系的实时关联，需要为每个应用分别建立监控表，并且每个应用都需要不断地去读取数据库相应区块(即存储对应监控表的区块)，这给机群系统带来极大的开销。为了减小开销，往往不得不延长各应用的读取周期，导致数据处理的实时性和准确性降低。

其次，传统的机群应用管理系统只能处理应用间的简单逻辑关系，如先后顺序关系，并发关系等，难以描述错综复杂的应用之间的关联关系，管理员需要分别对每个应用的运行状况进行监控，因此非常不便于大规模的机群系统的应用管理。

综上所述，当前迫切需要一种在保证各应用按其依赖关系实时关联的前提下，减小系统开销，并且能够处理各种复杂逻辑关系、便于管理的机群应用管理系统及其应用管理方法。

发明内容

本发明的目的是提供一种在保证各应用按其依赖关系实时关联的前提下，减小系统开销，并且能够处理各种复杂逻辑关系且便于管理的机群应用管理系统及其应用管理方法。

为实现上述发明目的，本发明一种机群应用管理系统，包括执行引擎模块和数据库模块，

所述数据库模块用于实时地存储各应用的处理结果，并建立监控表，所述监控表中记录多个应用的所有关联应用的处理结果的改变信息；

所述执行引擎模块用于执行机群系统中的各个应用，并将各应用的处理结果实时地写入数据库模块；还用于按照所设定的周期定期读取数据库模块中的监控表，每次读取监控表后根据所读取的多个应用的处理结果的改变信息，分别判断各应用的触发条件是否已满足，并在触发条件满足时触发相应的应用。

其中，所述执行引擎模块还用于以工作流为单位执行机群系统的各个应用；每个所述工作流由相互关联的多个应用所构成。

其中，所述监控表是全局监控表，所述数据库模块还用于在所述全局监控表记录所有工作流内的应用的处理结果的改变信息；

所述执行引擎模块还用于在执行所述工作流时，以所设定的周期定期读取数据库模块中的全局监控表，并根据全局监控表内记录的应用的处理结果的改变信息，分别判断该工作流内各应用的触发条件是否已满足，当触发条件满足时触发相应的应用。

其中，所述监控表是工作流监控表，所述数据库模块还用于为每个工作流建立一个工作流监控表，该工作流监控表中记录所定应的工作流内各应用的处理结果的改变信息；

所述执行引擎模块还用于在执行每个所述工作流时，以所设定的周期定期读取数据库模块中的对应于该工作流的工作流监控表，并根据该工作流监控表内记录的应用的处理结果的改变信息，分别判断该工作流内各应用的触发条件是否已满足，当触发条件满足时触发相应的应用。

其中，所述机群应用管理系统还包括：执行支撑模块，用于为用户提供工作流图形化编辑和图形化管理的界面，并将用户的操作命令传输给所述执行引擎模块；还用于在各节点自动安装和卸载应用的软件包、自动报告节点的运行状态和负载情况以及在各节点上执行所述执行引擎模块发出的操作命令。

本发明还提供了基于上述机群应用管理系统的机群应用管理方法，其特征在于，包括下列步骤：

步骤1：执行引擎模块执行机群系统中的各个应用，并将各应用的处理结果实时地写入数据库模块；

步骤2：数据库模块实时地存储各应用的处理结果，并建立监控表，所述监控表中记录多个应用的所有关联应用的处理结果的改变信息；

步骤3：执行引擎模块按照所设定的周期定期读取数据库模块中的监控表，每次读取监控表后根据所读取的多个应用的处理结果的改变信息，分别判断各应用的触发条件是否已满足，并在触发条件满足时触发相应的应用。

其中，所述步骤1中，所述执行引擎模块执行各个工作流，在执行每个工作流的过程中依次触发并执行该工作流中的各个应用，每个所述工作流由相互关联的多个应用所构成。

其中，所述步骤2中，所述监控表是全局监控表，所述数据库模块在所述全局监控表记录所有工作流内的应用的处理结果的改变信息；

所述步骤3还包括：所述执行引擎模块在执行所述工作流时，以所设定的周期定期读取数据库模块中的全局监控表，并根据全局监控表内记录的应用的处理结果的改变信息，分别判断该工作流内各应用的触发条件是否已满足，当触发条件满足时触发相应的应用。

其中，所述步骤2中，所述监控表是工作流监控表，所述数据库模块为每个工作流建立一个工作流监控表，该工作流监控表中记录所定应的工作流内各应用的处理结果的改变信息；

所述步骤3还包括：所述执行引擎模块在执行每个所述工作流时，以所设定的周期定期读取数据库模块中的对应于该工作流的工作流监控表，并根据该工作流监控表内记录的应用的处理结果的改变信息，分别判断该工作流内各应用的触发条件是否已满足，当触发条件满足时触发相应的应用。

其中，所述工作流内各应用之间的关联关系包括：“等待”关系、“会聚”关系、“部分会聚”关系、“选择”关系；

对于“等待”关系，其触发条件定义为单个关联应用结果表的改变，

对于“会聚”关系，其触发条件定义为多个关联应用结果表的改变，

对于“部分会聚”关系，其触发条件定义为多个关联应用结果表中任意一个的改变，

对于“选择”关系，其触发条件定义为一个或多个关联应用结果表中的修改内容是否满足选择条件。

与现有技术相比，本发明具有下列技术效果：

1、本发明能够在保证各应用按其依赖关系实时关联的前提下，减少数据库访问连接数，提高性能，降低开销，提高了系统利用率。

2、本发明能够处理应用间各种复杂逻辑关系。

3、本发明更加便于管理和操作。

附图说明

图1是本发明的工作流描述模型的基本模型描述图；

图2是本发明的工作流描述模型的扩展模型描述图；

图3是本发明中一个含有“等待”关系的工作流示意图；

图4是本发明中一个含有“等待”关系的工作流对象分解示意图；

图5是本发明中一个含有“会聚”关系的工作流示意图；

图6是本发明中一个含有“会聚”关系的工作流对象分解示意图；

图7是本发明中一个含有“部分会聚”关系的工作流示意图；

图8是本发明中一个含有“部分会聚”关系的工作流对象分解示意图；

图9是本发明中一个含有“选择”关系的工作流示意图；

图10是本发明中一个含有“选择”关系的工作流对象分解示意图；

图11是本发明一个实施例的系统结构示意图；

图12是本发明一个实施例中的智能代理模块的工作机制示意图；

图13是本发明一个实施例中的事件服务模块的工作机制示意图；

图14是本发明一个实施例中的执行引擎模块的工作机制示意图；

图15是本发明一个实施例中的执行引擎模块的初始化流程图；

图16是本发明一个实施例中的应用创建流程图；

图17是本发明一个实施例中的应用状态转移关系示意图；

图18是本发明一个实施例中的工作流创建流程图；

图19是本发明一个实施例中的工作流状态转移关系示意图；

图20是本发明一个实施例中的工作流与工作流实例关系示意图；

图21是本发明一个实施例中的工作流触发流程图；

图22是本发明一个实施例中的工作流挂起流程图；

图23是本发明一个实施例中的工作流恢复流程图；

图24是本发明一个实施例中的工作流关闭流程图；

图25是本发明一个实施例中的工作流优先级设定流程图；

图26是本发明一个实施例中的执行引擎对于工作流管理的流程图。

具体实施方式

以下，结合附图和实施例对本发明进行详细说明。

其中，实施例1和2分别提出了一种低开销地在机群系统中实现各应用之间的实时关联的机群应用管理系统的解决方案。实施例3则是在实施例1或2的基础上，增加工作流编辑和管理界面模块、智能代理模块、事件服务模块、FTP服务器模块等一系列附属模块，从而使机群应用管理系统更加便于操作，特别是更加便于管理员对各应用(或工作流)进行监控。下面分别描述实施例1、2、3。

实施例1

根据本发明的一个实施例，提供了一种基于工作流的机群应用管理系统。该机群应用管理系统基于工作流描述模型对存在依赖关系的各应用进行组织，将每组相互关联的多个应用构成一个工作流，并以工作流为单位对数据库进行定期读取，来实现工作流内部各应用之间的实时关联，从而大幅地降低系统开销。为方便描述，本发明中，如果B应用的运行需要使用到A应用的结果，则称A应用是B应用的关联应用。B应用是A应用的被关联应用。一个应用可能只有一个关联应用，可能有多个关联应用，也可能没有任何关联应用。

本实施例提供的机群应用管理系统包括执行引擎模块和数据库模块。其中，执行引擎模块用于工作流的执行、监控(包括触发、挂起、恢复、关闭等)和对多个工作流进行统一的调度和管理。执行引擎模块在执行工作流时，将各应用的处理结果实时地写入数据库模块。数据库模块用于保存应用管理系统的系统信息，以及实时地存储各应用的数据处理结果。

为便于理解，首先介绍本发明所涉及的工作流描述模型。工作流描述模型是通过各种关联和运行约束，达到描述应用间关系的目的，从而实现用户和应用管理系统的交互语言。工作流描述模型包括：基本模型和扩展模型。基本模型由对象和连接组成，对象用于表示构成工作流的基本实体。连接用于表示对象之间的关系和约束条件。工作流通过使用对象和连接进行描述，一个对象拥有一条转入连接以及多条转出连接；如图2所示，在对象的基础上生成派生对象，形成扩展模型，派生对象包括：实体对象、控制对象。实体对象表示被管理的应用，它描述其所代表应用的信息，包括：应用名称，部署位置，启动方式等。控制对象用于表示流程控制语义，控制对象包括：并行开始、会聚、部分会聚、选择、等待。“并行开始”对象用于表示并行语义的开始，“会聚”对象用于表示并行语义的结束。“部分会聚”对象用于表示满足一定条件的并行语义结束。“选择”对象表示选择语义，选择对象对应多个转出连接，各个转出连接都会关联一个转出条件，运行时选择对象对转出条件进行判断，并根据判断结果选择转出连接。选择语义中的判断条件可以根据需要进行设置，比如可以设置为：结果大于1000。“等待”对象用于表示等待状态，也就是说进入等待对象后，流程执行就进入了等待状态，直到接收到推进消息。推进消息包括：应用运行结束的消息，完成系统数据的改写的消息，产生系统输出数据的消息等。从上文的描述可以看出“会聚”和“部分会聚”中也包含了等待的语义，即等待并行语义的全部结束和等待满足一定条件的并行语义的结束。

根据上述工作流描述模型，可以把多个机群应用按照各自的关联关系进行组合，从而形成工作流。本实施例中，执行引擎模块以工作流为单位来进行统一的调度和管理。对于一个工作流，组成该工作流的应用之间的关系包括：等待关系、并行开始关系、会聚关系、部分会聚关系和选择关系中的一种或多种。本实例中，通过执行引擎模块和数据库模块的配合来实现这些关联关系。

与传统方案不同，本实施例的数据库模块不为每个应用分别建立监控表，而是为每个工作流建立一个统一的工作流监控表，该监控表记录该工作流内所有应用的关联应用的结果表的改变。结果表即数据库模块用于存储应用结果的工作表，本实施例中，每个应用在数据库中都有一个对应的结果表。结果表的改变即结果表发生了数据变化。一般来说，需要为每个被关联应用定义触发条件，该触发条件通常是该应用的关联应用的结果表发生改变。

下面举例说明工作流内部各应用之间的关联关系的实现方法。图3示出了一个工作流实例，该工作流包含A、B、C、D四个应用对象，应用间存在3个“等待”控制对象，分别为：等待应用A的运行结果，等待应用B的运行结果和等待应用C的运行结果，如图4所示。应用B的触发条件定义为应用A的结果表的改变(即应用A的结果表发生了数据变化)，应用C的触发条件定义为应用B的结果表的改变，应用D的触发条件定义为应用C的结果表的改变。其中，结果表的改变的类型包括增加条目，删除条目，修改条目等，在触发条件的定义中，结果表的改变的内涵(即触发条件)可根据具体应用的不同自行定义。比如触发条件可以定义为结果表中增加条目，可以定义为结果表中删除条目，也可以定义为结果表中修改条目，进一步地，触发条件还以定义为上述三种情况“和”或“或”的逻辑组合。

数据库模块根据该工作流内各应用的触发条件，利用触发器监视触发条件中所涉及的关联应用的结果表，即应用A、B、C的结果表。当应用A、B、C的结果表中的任意一个发生改变时，触发器将该结果表的改变记录到工作流监控表中。

执行引擎模块则定期读取工作流监控表，当工作流监控表发生变化时，遍历该工作流内的所有应用，分别判断该工作流内部的每个应用是否满足其触发条件，当满足触发条件时，执行引擎模块触发该应用工作或触发该应用使用改变后的结果表的数据。比如执行引擎模块某次读取工作流监控表时，应用A的结果表发生改变，应用B、C的结果表没有改变。遍历该工作流内的所有应用A、B、C、D。其中应用A无触发条件，不做处理。应用B的触发条件是应用A的结果表改变，该触发条件满足，因此触发应用B。应用C、D的触发条件分别是应用B、应用C的结果表改变，这两个触发条件都不满足，因此不触发应用C、D。可以看出，按照上述方案，即可依序触发工作流内的应用A、B、C、D，从而使工作流获得良好的组织。并且，本实施例以整个工作流为单位定期读取数据库，而传统的应用管理方案中，对于应用B、C、D，需要分别定期读取数据库，可以看出，本实施例的方案可以大大地节省系统开销。

上述工作流实例只涉及最简单的“等待”关系，下面进一步介绍本实施例中对于应用之间的各种关联关系的实现方案。

数据库模块为每个工作流建立一个监控表。工作流中的各个应用的触发条件所涉及的每个关联应用的结果表分别由触发器监视，当其中一个结果表发生改变时，触发器就将该结果表的改变信息记录到监控表中，所记录的改变信息包括该结果表的名称和修改内容等项目。表1示出了一个工作流监控表的示例。

表1

执行引擎模块定期读取工作流监控表，当监控表发生改变时，遍历该工作表的所有条目，记录下发生改变的结果表的名称和修改内容。然后再遍历该工作流内部的所有应用，对每个应用，判断当前是否已满足其触发条件，如满足触发条件，执行引擎模块触发该应用，如不满足触发条件，执行引擎模块不触发该应用。

各种关联关系的触发条件如下：

对于“等待”关系，其触发条件定义为单个关联应用结果表的改变。

对于“会聚”关系，其触发条件定义为多个关联应用结果表的改变。如图5、6所示，应用A、B会聚于C，可以转换为应用C等待应用A和B的结束，即应用C的触发条件是应用A的结果表和应用B的结果表都发生改变。

对于“部分会聚”关系，其触发条件定义为多个关联应用结果表中任意一个的改变。如图7、8所示，应用A、B部分会聚于C，可以转换为应用C等待应用A或B的结束，即应用C的触发条件是应用A的结果表或者应用B的结果表都发生改变。

对于“选择”关系，其触发条件定义为一个或多个关联应用结果表中的修改内容是否满足选择条件。如图9、10所示，应用A结束后，选择执行应用B或者应用C，它可以转换为判断应用A的结果是否满足执行应用B的条件1，以及判断应用A的结果是否满足执行应用C的条件2。这需要判别应用A的结果表的具体修改内容是否满足相应条件。上述条件1或条件2可以是应用A结果表改变的类型，如增加条目、删除条目或者修改条目等，也可以是应用A的处理结果的大小，如结果大于1000，执行应用B，小于1000，则执行应用C。

在一个优选实施例中，为处理应用间更复杂的关联关系，可以在每个结果表条目设置一个改变标识符，遍历监控表条目时，通过标识符记录相应的关联应用结果表是否发生改变，比如发生改变，标识符为“真”，未发生改变，标识符为“假”。触发条件则可以定义为一个逻辑表达式，当所述逻辑表达式的值为“真”时，则判断当前已满足该触发条件。所述逻辑表达式由各结果表改变标识符和各种逻辑运算符号(如“与”、“或”、“非”、“异或”等)所构成，从而表达出应用间更为复杂的关联关系。该优选实施例中，在遍历各应用触发条件时，对每个应用触发条件的逻辑表达式进行计算，根据计算结果判断当前是否满足该应用的触发条件。

特别地，对于“并行开始”关系，如图5所示，表明应用A和应用B可以同时开始运行，对于应用C而言，它位于“会聚”之后，因此，应用C需要等待应用A和应用B的运行结果。在机群应用管理系统中应用A和应用B  “并行开始”表示为：“A&&B”的形式，它表明只有A、B对应的触发条件同时满足时，系统才能继续推进该工作流的流程。对于如何判断A、B对应的触发条件是否满足，采取的方式为执行引擎模块定期读取数据监控表，取回相关的变化信息，然后进行本地的匹配，如果应用A触发条件满足，就将应用A对应的标志置为“真”，如果应用B触发条件满足，就将应用B对应的标志置为“真”，每次处理完所有的返回信息后，如果机群应用管理系统发现应用A、B对应的标志置均为“真”，则说明“会聚”对应的触发条件均已满足，机群应用管理系统继续推进该工作流的流程。

从上述描述中可以看出，本实施例避免由每个应用分别读取工作表，只需要以每个工作流为单位，定期读取该工作流对应的一个监控表，即可实现该工作流内部的应用之间的各种复杂关联关系，极大地减少了数据库模块的操作次数(即减少数据库模块的连接数)，从而有效地降低了系统开销。

与现有技术相比，本实施例具有下列技术效果。

1、本实施例能够减少数据库访问连接数，提高性能，降低开销，提高了系统利用率。现有的解决方案中，每个需要查询结果表的应用都需要访问数据库，本发明只需要在机群应用管理系统软件一点访问数据库即可，因此可以有效地减少数据库连接数，从而提高性能，降低开销，提高了系统利用率。

2、本实施例降低了管理复杂性。本发明基于工作流统一管理数据库表，而现有的解决方案中，每个需要查询结果表的应用都需要自己管理数据库表，如建立数据库触发器，建立操作序列，建立数据变化监控表等。因此本发明降低了管理复杂性，提高了效率。

3、本实施例统一管理应用，而现有的解决方案中，每个应用需要自己查看运行状态，决定是否进行进一步操作，本实施例均由机群应用管理系统软件统一管理，降低了应用开发复杂性、系统运行开销。提高了系统利用率。

实施例2

本实施例与实施例1的区别是：本实施例的数据库模块建立一个统一的全局监控表，该全局监控表记录整个机群系统中所有应用的触发条件中所涉及的应用结果表的改变信息。数据库模块根据机群系统中各应用的触发条件，利用触发器监视触发条件中所涉及的结果表，并将这些结果表中的每一个改变记录到工作流监控表中。执行引擎模块则定期读取全局监控表，当发现全局监控表发生变化时，执行下列步骤：

1)遍历全局监控表，找出所有发生改变的结果表。

2)遍历所有工作流，如果当前工作流内任意一个应用的触发条件中涉及到发生改变的结果表，则将该工作流标记为待判定工作流。

3)对于每个待判定工作流，分别判断该工作流内部的每个应用是否满足其触发条件，当满足触发条件时，执行引擎模块触发该应用工作或触发该应用使用改变后的结果表的数据。

本实施例的其余部分与实施例1完全一致，不再赘述。

相对于实施例1，本实施例能够进一步地减少数据库模块的连接数。

实施例3

根据本发明的另一个实施例，提供了一个优选的机群应用管理系统。本实施例包括实施例1或2的所有技术特征，并在此基础上，参考现有的应用于办公软件的工作流管理系统的系统构架增加了用于支持所述执行引擎模块的执行支撑模块，从而构成一个更加完善的基于工作流的机群应用管理系统。如图11所示，该机群应用管理系统除了包括执行引擎模块和数据库模块外，还包括执行支撑模块，执行支撑模块包括：工作流编辑和管理界面模块，为用户提供工作流图形化编辑和图形化管理的界面；智能代理模块，负责自动安装和卸载应用的软件包、自动报告节点的运行状态和负载情况以及在节点上执行所述执行引擎模块发出的操作命令；事件服务模块，为系统中其他进程模块提供基于事件的通信通道；FTP服务器模块，为系统中其他进程模块(如智能代理模块)提供基于FTP协议的文件传输服务。

工作流编辑和管理界面模块提供工作流编辑和管理界面，便于用户进行基于工作流描述模型的机群应用的管理。首先用户使用工作流编辑和管理界面，创建机群应用，应用在界面上创建完成后，工作流编辑和管理界面将创建信息通知给执行引擎模块，执行引擎模块保存应用信息到数据库中，并通过智能代理模块对创建的应用进行部署，智能代理模块在部署成功后通过事件服务模块通知执行引擎模块，执行引擎模块收到部署成功的消息后，将消息通知给工作流编辑和管理界面，完成应用的创建。在所有需要管理的机群应用创建完成后，用户使用工作流编辑和管理界面，进行工作流的创建，用户使用工作流编辑和管理界面来定义应用间的工作流关系，进行工作流的创建，工作流在界面上创建完成后，工作流编辑和管理界面通知执行引擎模块，执行引擎模块将创建的工作流信息保存在数据库中，并通知工作流编辑和管理界面，完成工作流的创建。用户使用工作流编辑和管理界面，可以触发一个工作流，执行引擎模块收到触发命令后，执行工作流触发操作，工作流触发成功后，成为一个工作流的实例，并进入“运行”状态，执行引擎模块通过事件服务模块报告的工作流推进事件来开始推进流程，通过智能代理模块对工作流对应的应用进行启动、关闭等操作来执行流程，执行引擎模块可以对多个工作流进行统一的调度和管理。用户使用工作流编辑和管理界面通过和执行引擎模块交互，监控工作流运行和进行运行时管理。

智能代理模块的工作机制如图12所示，智能代理模块接收执行引擎模块的命令执行相应的操作，并向执行引擎模块报告节点(节点是指机群中的节点)的运行信息。在执行应用软件包的安装时，智能代理模块通过FTP服务器模块下载所需的软件包，然后进行软件包的安装；在执行应用的启动、关闭、卸载等命令时，智能代理模块在节点上执行相应的操作命令。

工作流编辑和管理界面模块包括：工作流编辑器和工作流管理器。工作流编辑器为用户编辑流程提供了一个可视化操作界面，在中用户通过工作流描述模型定义的元素来描述应用间的关系，构造工作流；工作流管理器，为用户提供工作流的图形化管理工具。

事件服务模块的工作机制如图13所示，事件服务模块为所述机群应用管理系统提供基于事件的通信通道，它支持事件消费者和事件提供者(事件的提供者和消费者与现实生活中的提供者和消费者概念相同，事件的提供者产生事件，事件的消费者获取事件)多对多的动态匹配，提供了一种松散耦合的调用关系，在此方法中事件服务模块被用于传输系统状态改变的事件，如：应用部署成功、应用运行结束、系统数据项被改写、应用产生输出数据等。

执行引擎模块的工作机制如图14所示，执行引擎模块通过和工作流编辑和管理界面交互，响应用户的请求；通过和智能代理模块交互实现应用的安装、卸载、启动、关闭和获取节点运行状态；通过注册事件服务的事件获取事件；通过和数据库的交互，获取和保存系统信息。执行引擎模块在提供相应的功能前，需要首先进行初始化，执行引擎模块的初始化流程如图15所示，初始化过程为：1)通过和数据库交互得到系统的配置信息，包括：系统的节点总数、节点的硬件信息、节点的网络信息。2)通过和数据库交互得到机群应用的配置信息和工作流的配置信息；3)注册为事件服务中机群系统事件的消费者；4)和智能代理模块建立联系，获取节点运行状态。初始化完成后，执行引擎模块可以提供相应的功能。

机群应用创建的过程如图16所示，用户在使用基于工作流描述模型构造的机群应用管理系统时，首先需要创建机群应用，应用创建的过程为：1)用户在工作流编辑和管理界面中定义应用的内容，包括：应用名称、应用运行的进程名称、应用的运行路径，应用的安装包名称，应用运行的节点列表。应用定义完成后点击完成；2)工作流编辑和管理界面将定义的应用信息通知执行引擎模块；3)执行引擎模块将应用信息保留在本地，并将应用信息通知数据库模块并在数据库模块中保存；4)执行引擎模块分析需要部署的节点，通知对应的智能代理模块，进行部署；5)智能代理模块进行应用的部署；6)部署完成后，智能代理模块通过事件服务模块通知执行引擎模块，执行引擎模块通知界面；7)用户通过工作流编辑和管理界面看到部署成功的消息。在应用创建的过程中，将应用状态定义为：“已创建”、“部署成功”、“部署失败”和“销毁”。应用状态的转移关系如图17所示。

用户在完成应用的创建后，需要进行工作流的创建。工作流创建过程为：1)用户在工作流编辑和管理界面中打开工作流编辑器，在编辑器中通过拖拽的方式来选定应用，和定义应用间关系，组成工作流，用户将工作流编辑结束后，点击保存；2)工作流编辑和管理界面将工作流的信息发送给执行引擎模块；3)执行引擎模块解析和存储相应的工作流信息；4)执行引擎模块将工作流触发条件的信息保存在调度队列中，为执行做准备；5)执行引擎模块将工作流的信息保存到数据库中，工作流创建完成。

工作流创建过程如图18所示，为了有效的管理工作流，将工作流的状态定义为：“未运行”、“运行”、“已挂起”；工作流的操作包括：触发、关闭、挂起、恢复。工作流的状态和操作的关系如图19所示。工作流管理中引入工作流实例的概念，一个工作流触发后，会生成一个工作流实例并且该工作流实例具有全局的实例号，工作流与工作流实例的关系如图20所示；工作流的触发流程如图21所示；工作流的挂起流程如图22所示，工作流的恢复流程如图23所示，工作流的关闭流程如图24所示。

工作流创建完成后，执行引擎模块能对多个工作流进行统一的调度和管理。执行引擎模块的调度依据为工作流的优先级，优先级的设定如图25所示，执行引擎模块对于工作流实例的管理如图26所示。

最后，上述的实施例仅用来说明本说明，它不应该理解为是对本发明的保护范围进行任何限制。而且，本领域的技术人员可以明白，在不脱离上述实施例精神和原理下，对上述实施例所进行的各种等效变化、变型以及在文中没有描述的各种改进均在本专利的保护范围之内。

Claims (5)

1.一种利用机群应用管理系统的机群应用管理方法，其特征在于，所述机群应用管理系统包括执行引擎模块和数据库模块，所述机群应用管理方法包括下列步骤：

步骤1：执行引擎模块执行机群系统中的各个应用，并将各应用的处理结果实时地写入数据库模块；

步骤2：数据库模块实时地存储各应用的处理结果，并建立监控表，所述监控表中记录多个应用的所有关联应用的处理结果的改变信息；

步骤3：执行引擎模块按照所设定的周期定期读取数据库模块中的监控表，每次读取监控表后根据所读取的多个关联应用的处理结果的改变信息，分别判断各被关联应用的触发条件是否已满足，并在触发条件满足时触发相应的应用。

2.根据权利要求1所述的机群应用管理方法，其特征在于，所述步骤1中，所述执行引擎模块执行各个工作流，在执行每个工作流的过程中依次触发并执行该工作流中的各个应用，每个所述工作流由相互关联的多个应用所构成。

3.根据权利要求2所述的机群应用管理方法，其特征在于，所述步骤2中，所述监控表是全局监控表，所述数据库模块在所述全局监控表记录所有工作流内的应用的处理结果的改变信息；

所述步骤3还包括：所述执行引擎模块在执行所述工作流时，以所设定的周期定期读取数据库模块中的全局监控表，并根据全局监控表内记录的应用的处理结果的改变信息，分别判断该工作流内各应用的触发条件是否已满足，当触发条件满足时触发相应的应用。

4.根据权利要求2所述的机群应用管理方法，其特征在于，所述步骤2中，所述监控表是工作流监控表，所述数据库模块为每个工作流建立一个工作流监控表，该工作流监控表中记录所对应的工作流内各应用的处理结果的改变信息；

所述步骤3还包括：所述执行引擎模块在执行每个所述工作流时，以所设定的周期定期读取数据库模块中的对应于该工作流的工作流监控表，并根据该工作流监控表内记录的应用的处理结果的改变信息，分别判断该工作流内各应用的触发条件是否已满足，当触发条件满足时触发相应的应用。

5.根据权利要求3或4所述的机群应用管理方法，其特征在于，所述工作流内各应用之间的关联关系包括：“等待”关系、“会聚”关系、“部分会聚”关系、“选择”关系；

对于“等待”关系，其触发条件定义为单个关联应用结果表的改变，

对于“会聚”关系，其触发条件定义为多个关联应用结果表的改变，

对于“部分会聚”关系，其触发条件定义为多个关联应用结果表中任意一个的改变，

对于“选择”关系，其触发条件定义为一个或多个关联应用结果表中的修改内容是否满足选择条件。

Images