基于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/