基于AOP概念实现事务同步框架

吴潇峰

0 引言

众多的大型跨国企业，目前都会有一些IT策略来防止自身的应用系统在互联网上遭到黑客的攻击。本文所涉及的客户在其企业内部网（信任区域）与互联网（非信任区）之间建立了一个DMZ（缓冲隔离区）区域。此外，在缓冲隔离区与企业内部网之间建立一层防火墙。并且使用IBM MQ产品作为跨越这两个网络区域的唯一的、可靠的数据传输通道。企业服务应用系统被完全相同地部署在缓冲隔离区和企业内部网络中，并且各自拥有独立的后台数据库系统。因此，为了使得这两个数据库中的数据同步和一致，必须每隔一段时间同步一次两边的事务处理。由于在缓冲隔离区和企业内部网络区之间，同时还部署着许多其他的应用，并使用了相同的数据通道；所以用户同时还需将每个数据包的大小限定为4MB之内，以防止瞬时的大数据量导致数据通道堵塞。

根据以上的描述，这里有几个问题需要我们去做相应的处理：

实时的应用服务同步操作，每个网络区域中的事务处理都将在另一端重复发生。消息数据在发送时作分包处理，在接收端再作组装处理。失效恢复处理。

1 解决方案

1.1 事务处理同步基础框架

一个事务处理同步的基础框架模块，如图1所示：

图1 事务处理同步框架

灰色图框中的组件组成了通用的事务处理同步模块。该模块对业务层应用提供了接口，业务层的应用服务只需实现该接口，并在事务处理函数中调用由事务同步框架所提供的API，而无需了解底层的详细调用实现。该API将串化所有的参数并将相应的服务调用信息传输到另一端，并将在另一端同样的调用执行相应的服务。

相应的事务同步处理具体流程如下：

1.应用服务调用事务同步处理模块提供的接口函数去触发事务同步服务。

2.事务同步接口将串化所有的应用服务中的参数数据及调用对象信息，并将根据预设的传输包大小限制进行分包和装箱处理（根据应用需求传输数据包的大小将被限定在4MB以下）,并设置相应的组号，一次服务调用只会具有一个相同的组号，以便于之后数据包的拆箱，随后通过MQ控制器对串化后的数据进行传输。

3.接收端的MessageBean将对指定的消息通道不间断地进行监听。

4.当接收端收到数据后，暂不做处理，将该串化的消息数据存入数据库，待同组的数据包全部到达后一并处理。

5.当处理到相应的数据包时，首先将拥有相同组编号的一组数据包从数据库中取出，并按序拆箱和拼接。

6.在接收端将利用Java的反射机制来调用反串化后的相应的服务函数；相当于将发送端调用过的服务函数在对端相同地调用一次。如果在接收端调用成功并且事务提交没有异常的话，将从数据库中移除这一组数据包记录。以表示该次事务同步已成功完成。

1.2 在实现过程中应用AOP理念

如图2所示：

图2 应用Spring框架中AOP来实现事务同步

对于事务同步处理流程的步骤2和步骤4，可以看出，在发送端的业务逻辑层的函数将会调用通用事务同步模块提供的接口函数，而在接收端则有事务同步模块来调用相应的业务逻辑层函数以达到事务同步的目的。使用了 Spring框架中的AOP来实现事务同步的调用。而应用服务本身并不需要显式地调用事务同步接口函数；AOP的代理机制将会来执行该调用。

“Spring框架中使用代理的设计模式来实现 AOP的功能。为了能对业务代码调用顺序有更好地控制，我们选用了AroundAdvice的模式。创建TransactionSyncInterceptor并实现 MethodInterceptor接口中的 invoke()函数”[1]。并在其中截获到的调用方法及参数信息进行串化及装箱处理。在成功执行MethodInterceptor.proceed()函数（即原业务服务方法）之后，系统将调用 MQ控制器提供的函数将串化和分组的消息数据放入MQ的消息队列中。其中部分Java代码描述如下：

1.3 使用第三方开源组件Quartz

本框架中还应用了第三方开源组件 Quartz以实现可配置的定时执行消息数据的拆箱及事务处理的执行。“在Quartz中，当调度器被初始化后，它可以被启动,置于一个待机状态并可以被关闭。注意，一旦当调度器被关闭，那么它无法重新启动直到它被重新初始化以后。触发器也不会被激发(调度任务不会执行)直到调度器被启动。”[2]

创建QuartzJobSchedulerServlet类，并将其配置在web server启动的servlet列表中，同web servery一同启动加载。部分Java代码描述如下：

1.4 选用MQ作为可靠的消息传输通道

IBM WebSphere MQ产品能够提供准确响应，超低延迟的并且完全符合JMS规范的企业级消息服务。

WebSphere MQ使应用程序在必要时通信，同时从开发和使用角度保持其独立性。WebSphereMQ应用(我们姑且称之为应用 A)，将需要与之通信的其他应用，看作是通过队列表示的一组服务接口。这些其他应用的物理实现，可能随着时间的推移而发生变化。

“WebSphere MQ 可以降低应用程序、Web服务或网络失败时数据丢失的风险。它也有助于确保数据不被复制，且作为工作或交易的一个单元完成。可靠的交付意味着WebSphere MQ 形成了许多关键通信系统的验证主干网，并被委托交付业务关键型和高位值数据。WebSphere MQ 可以根据应用程序和 Web 服务的需求，同步或异步地交付信息。它经过某种配置后，也可以为次关键型数据提供较健壮质量的服务。”[3]

2 主要辅助功能

2.1 消息分包组件

在发送端，超过限定大小的数据信息，将首先被分拆成小于4MB的数据包集合，并且每个数据包将具有一个统一的消息组编号和一个独立组内序列编号。在分拆后这些数据包，将通过MQ消息通道进行传输。

在接收端，每个数据包都能按这两组编号，重新合并成一个完整的数据包，然后通过反序列化和Java的反射机制，重新在接收端执行一次相应的服务调用。

每个数据包的最大容量，是定义在一个系统配置文件中，可以按照不同的客户的真实环境要求进行改变。不过必须保证的是在缓冲隔离区和企业内部的该配置信息的一致性。

2.2 包数据信息的持久性

一旦包数据信息到达一端的本地消息队列中，数据接收处理程序，将首先浏览一遍整个数据包，并且将该数据包存入数据库，同时将该包数据从本地消息队列中删除。当所有同组的包数据信息到达后，进行包数据的组合与反串化，从而获得能通过Java反射执行的服务调用。只有当该服务调用的执行成功后，才会将这一组的包数据信息从数据库中移除。否则，这些包数据信息将一直被保存在数据库中，并等待下一次的执行，如图3所示：

图3 包数据信息保存于数据库

2.3 失效恢复

失效恢复，在该同步模块中具有相当重要的作用，若要保持两端数据的一致性，必须有类似于数据库事务处理备份机制。因为在出现爆发式大数据量或者事务集中处理的时候，要确保偶发性的事务处理失败或解/压包数据出现错误时，系统能将状态保持，并能保留完整的日志记录及将来可重新执行的事务数据。

在事务同步模块中，使用了包消息的持久机制，消息数据直到被成功拆箱执行后才会被全部删除。并有一个出错恢复程式去监控执行过程中的错误，并且自动重新尝试执行该出错服务，直到该服务调用成功数据将被移除；或者超出最大重试次数后，数据被表示成不可执行，可有管理员从日志中查获相应出错信息，做出相应的调整后，更改包数据的执行状态，等待之后的重新执行。该出错恢复程式是一个基于时间触发器的组件，所以失效恢复的执行间隔都是可配置的，如图4所示：

图4 失效恢复模组

3 结论

通过使用AOP的理念实现该事务同步框架，我们能够得到以下具有优势的功能：

1) 自动的失效恢复

系统能在接收端的执行期间，自动地恢复执行失败的服务调用。

2) 在服务调用级别的同步

通常的数据同步组件都是基于数据库级别的同步。但是事实上，也许有时系统只是需要同步部分的数据，那些有特殊服务所做的数据更新的同步。因此用这个事务同步框架就可实现基于服务级别的可配置的数据同步。并且框架可以与时下的SOA框架做到无缝连接整合。

3) 用AOP技术达到低耦合

对业务处理过程中的切面进行提取，它所面对的是处理过程中某个步骤或子阶段，以获得逻辑过程中各部分之间低耦合性的隔离效果。文中的事务处理同步框架正是使用了AOP的设计理念，运用配置文件来定制服务级别的数据同步。并可轻松提取运用到其他的企业服务中去。

4) 多路由

文中提及的案例是一个端对端的实例。事实上，我们可以通过配置来实现该事务处理同步框架的多路由功能，以达到一对多的消息发布目的。串化后的包消息可以通过配置好的路由信息并通过消息队列发送到多个端。

[1]Rod Johnson, Juergen Hoeller, Alef Arendsen, etc.The Spring Framework - Reference Documentation,URL:http://static.springsource.org/spring/docs/2.0.x/refer ence/index.html

[2]Quartz 1.x Tutorial,URL:http://quartz-scheduler.org/documentation/quartz-1.x/tutorials

[3]WebSphere MQ概述,URL:http://www-01.ibm.com/software/cn/websphere/inte gration/wmq/features/