1、网驰平台统一监控工具的设计与实现应用背景:当前分布式企业级应用的特点：流程制导，多中间件平台异构集成。业务流程通过组合异构平台上的应用组件，为客户提供复合的服务。Travel Plan 旅游定制系统中的中间件平台：Process Engine：Once BPELService Engine: Once SEEJB Container: Once ASPortal Server: OncePortal应用系统监控中存在的问题传统的监控方案：分别对异构中间件平台上的应用组件进行监控。缺点是监控信息分散，缺乏对应用中各个组件之间关系的考虑，难以了解应用系统整体的运行状况和定位出现性能问题的组件位置，
2、也不利于对应用整体性能进行分析从上图 TravelPlan 应用中可以看到，不同中间件平台上的应用组件实际是以流程引擎中的应用流程为中心的。TravelPlan 流程通过调用各个平台上的应用组件(web service 或 EJB 等)，为 TravelPlan 门户提供组合后的服务。在这样的应用中，我们的监控需求包括:1. 组件性能监控（包括 EJB、web 服务等组件） ；2. 流程性能及执行状态监控，包括a) 复合服务性能的监控b) 异常的监控c) 流程变量（如循环条件，pre-condition，post-condition 等等） ；d) 活动开始结束时间e) 业务逻辑监控f) 业务
3、流程执行过程监控3. 快速定位流程性能瓶颈以及分析各组件对流程整体性能的影响。解决方案1. EJB、web 服务等应用组件性能监控在传统的流程制导，多中间件平台异构集成的应用中，应用组件性能的监控分别在各个中间件平台上实现。实际上，EJB、web 服务等应用组件都是由业务流程来调用，可以通过监控应用组件的调用事件对他们的性能进行监控。因此，我们在流程引擎上统一地对 EJB、web 服务等应用组件的性能以及复合服务的性能进行监控。在 BPEL 流程当中，EJB、web 服务等应用组件的调用是 活动执行的结果，为了不对 BPEL 流程引擎的代码产生影响，我们采用 AOP 技术在活动执行时获取组件的
4、性能信息。2. 流程性能及执行状态监控a) 复合服务性能的监控业务流程为客户提供的复合服务在 BPEL 中是由和 活动对或者和来完成的，接受调用事件， 将调用结果返回给调用者。如：TravelPlan 流程提供的登录操作，接收登录验证请求是活动，验证结果返回是活动，他们在 BPEL 中的定义如下：可以通过 和 活动中 partnerLink、portType、operation 三个属性将操作的事件对应起来。通过 AOP 技术分别对这两个活动的执行进行监控，从而得到复合服务的性能。b) 流程变量和活动开始结束时间的监控流程变量和活动开始结束时间都可以采用 AOP 技术在流程活动运行时获取c)
5、业务逻辑监控已有工作已经完成业务逻辑的监控，这里的工作主要是将其集成到统一监控工具中。d) 业务流程执行过程监控在之前的业务流程实际执行过程的监控中，采用的方法是: 将 BPEL 流程引擎中产生的监控事件通过活动 id 与 BPMN 当中相应的图元对应，从而确定业务流程当执行的真个过程。这个方法存在如下的问题：在我们项目的实践过程中，我们发现由于网络延迟或者其他的原因监控器所接收到的监控事件可能会出现失序的现象。而监控事件的失序可能给业务流程的监控带来严重的后果。例如：在如下图所示的并发流程结构中，invoke3 必须在两条分支都运行结束的时候才能运行。假设 invoke3 的监控事件先于 i
6、nvoke1 的监控事件到达，因为之前的方法是直接将监控事件匹配流程节点。监控结果是流程执行出错，这显然是与事实不符的。另外一个例子：在如下的循环结构中，假设循环要求执行三次 invoke1，而 invoke2 的监控事件先于第三次 invoke1 的监控事件到达。监控结果是，在循环条件没有满足的情况下，invoke2 已经执行，流程执行出错，这也是与事实不符的。在实际应用中，流程执行的错误判断，可能造成业务失败等不良后果，给企业带来极大经济损失。因此，应当采用合适的解决方案，消除因监控失序导致的错误判断。而流程失序这个问题，并不能通过简单的给监控事件标记先后顺序或者加上时间戳解决。例如，在下
7、图的流程结构中，两条路径是并行的运行的，并且 act2 活动可能循环运行多次。四个活动的监控事件的顺序可能是 12345，13524 ，13452, 3412，13542，12534 ，12354等等中的任意一种，根本无法给监控事件标记先后顺序。而给监控事件加上时间戳，也并不能确定当前事件之前是否应该还有其他监控事件。因此，这两种方法都无法解决流程监控消息失序的问题。为了解决流程监控事件失序的问题，我们考虑 BPEL 流程本身结构，提出一种流程监控模型和一种监控事件匹配算法。在运行时，将监控事件匹配到监控模型上，并采用有限状态自动机来实现将监控事件序列匹配到流程运行模型的整个过程。能够很好的解
8、决监控事件失序的问题。流程监控模型定义：在流程运行过程，流程实际运行路径上的每个活动都会产生两个监控事件：activation 和completion 事件。而对于复合流程活动，例如活动，它的内部活动的监控事件实际上都在 活动的 activation 事件和 completion 事件之间发生。因此，我们可以将业务流程的监控事件序列看成是一个有向图。例如：我们将上图中包含活动的流程的监控事件流表示如下：其中， 节点表示相应活动的 activation 事件， 节点表示相应活动的 completion 事件，图中的有向边分为两种。一种是连接同一个流程活动的 节点和 节点的边，一种是连接复合流程活
9、动和它内部子流程的边，还有一种是表示流程执行方向的边。图中的有向边有一个共同特点，边尾的监控事件都要比边首的监控事件先发生。图中主要考虑了活动，而其他类型的复合活动也可以通过类似的方式表示出来。基于以上讨论，我们的流程监控事件流模型定义如下：流程监控模型可以表示成一个三元组：G=(N, E, L)。N 是一个有限节点集合，E 是一个连接N 中节点的有向边，L: 是一个节点标识函数，对于流程中的结构活动（flow ，switch 等） ，L 为节点的标识，它由一个二元组（type，id）表示，type 为节点类型，id 为节点在流程中的 id。另外， G 应该满足如下条件：1. N 中的节点可以
10、划分为节点对。每组节点对 n1，n 2 共享节点标识，即： l(n1) = l(n2)。在节点对中，一个节点称为开始节点，表示为 act(l)；另一个节点称为完成节点，表示为com(l), l 为他们共享的标识。在 act(l)和 com(l)之间有且只有一条有向边从 act(l)指向com(l)；2. E 中的边分为三种：一种是用于连接共享同一标识的开始节点和完成节点，一种用于连接复合活动和它内部子流程；另外一种用于连接顺序执行的活动；3. 对于每条有向边，边尾的节点先于边头节点发生；根据如上流程监控模型的定义，我们将流程执行中的监控事件序列与流程监控模型上的节点依次进行匹配，每个监控事件只
11、能够和模型上的一个节点匹配上。匹配的算法采用有限状态自动机来实现，描述如下：监控事件匹配算法：给定一个 BPEL 流程监控模型 m，根据模型 m 产生一个自动机，m 中的节点与自动机中的状态一一对应。每个状态可以为活动（active）和不活动（inactive） 。 开始的时候，只有流程的开始节点对应的状态处于 active； 对于其他状态来说，只有当它接受到它所有父亲节点的激活消息时，才能够从 inactive变成 active；例外是，对于复合活动的 状态，不一定需要接受到它所有父亲状态的激活消息，例如当活动的 状态接受活动 状态以及任一分支上父亲状态的激活消息即可从 inactive 转
12、变为 active； 当处于 active 的状态接受到其对应的监控事件时，它向他的所有孩子发送一个激活消息； 每个监控事件都包含一个时间戳，新接收到的监控事件按时间戳递增的顺序插入到消息队列中; 处于 active 的状态不断地与队列头部的监控事件进行匹配； 当匹配完业务流程结束状态的完成节点时，匹配算法结束；根据我们的监控模型和匹配算法可以看到，当接受到失序监控事件时，失序事件将因为无法匹配任何 active 的状态而被放在消息队列中。直到接受到并匹配完毕失序事件之前的所有监控事件之后失序事件才能与其相应的节点匹配。业务流程的监控人员将不会因为监控事件的失序对业务流程的执行产生错误的判断，
13、从而减小因此给企业带来的经济损失。3. 组件对流程性能影响及流程性能瓶颈分析（分析性能瓶颈问题）（方法）（效果，通过图示）异构平台上的应用组件由业务流程制导，组合成复合的服务提供给客户。影响业务流程性能的因素主要是外部应用组件的性能和流程业务逻辑执行的性能。然而，在 BPEL 语言描述的业务流程中，通过解析 BPEL 文件不能够确定复合服务的性能在运行时受到哪些应用组件性能的影响。例如，在上图的流程例子中，业务流程在 receive 活动接受用户请求，在 reply 活动将调用结果返回给用户，为用户提供一个复合的服务。在流程的执行过程中，流程可能选择三条分支中的任意一条。当流程执行不同分支时，
14、复合服务的性能将受不同服务的影响。为了在复合服务性能出现问题时，迅速的定位发生性能问题的组件的位置，我们对业务流程的实际执行路径进行监控。在这里有必要对流程执行过程的监控和执行路径的监控进行区分。流程执行过程的监控关注的是现有方法并没有考虑描述流程的实际执行路径。并且在监控事件的匹配过程中，我们可以记录流程的实际运行路径，结合通过监控得到的复合服务和运行路径上单个组件的性能指标，我们可以分析出复合服务的各个操作在执行过程中的性能受到哪几个应用组件性能的影响。举个简单例子，如下图所示，业务流程对外提供的登录操作，中间的活动是调用具体的登录 web 服务。通过对流程执行过程的监控，我们可以分析出复
15、合服务提供的登录操作受到登录 web 服务性能的影响，以及登录web 服务的相应时间占复合服务登录操作响应时间的比率等信息。这也有助于在复合服务性能低下时定位造成性能问题的具体组件。图。 。 。系统最终形态流程引擎：通过 AOP 技术在流程活动执行时获取活动中的变量的值，性能指标等信息，将监控事件发送给监控服务；流程监控事件格式：为了监控流程的运行过程，我们在流程实际运行路径上的每个流程活动产生两个监控事件，活动开始事件(activation) 和活动完成事件(completion)。监控事件采用 XML 格式，其基本结构如下：travelPlan43242login2009-02-28T11
16、:32:46.510+00:00invokecompletion324itemVar.监控事件包括两部分：Header 包括事件的识别信息：流程名，流程 id，活动名和时间戳；Payload 包括活动类型，触发点（activation 或者 completion） ，活动持续时间和变量的值。监控服务：对监控事件进行匹配以及监控信息持久化；监控界面：对监控结果进行展示。包括如下几个方面：1. 单个应用组件的性能的监视；2. 复合服务的性能的监视；3. 复合服务性能受各个应用组件性能的影响的可视化，用柱状图表示各个应用组件性能指标占复合服务性能的比重；4. 业务流程执行过程的监控可视化，包括业务流程执行的路径，流程中各个活动中变量的值，以及各个活动的性能指标等。项目计划和进展情况项目计划按照以下几个步骤来完成：1. 在 OnceBPEL 中采用 AOP 技术获取监控信息；2. 监控服务的实现，包括以下几个方面： 监控服务的接口实现； 从 BPEL 文件中得到流程监控模型的实现； 监控事件匹配算法的实现；3. 基于 Web 的监控客户端的实现；项目进展状况：由于之前 OnceBPEL 代码和 AOP 技术不是很熟，花了一些时间学习。目前项目第一步还没有完全完成。另外，基于 Web 的监控客户端之前一直由孙峥负责，所以这部分需要借助孙峥的帮忙完成。
