使用AOP实现应用程序失败转移

作者 沙晓兰 发布于 2007年11月16日

领域

架构 & 设计,

语言 & 开发

主题

Java ,

AOP

标签

AspectJ

近日，面向方面编程思想（AOP）是公开论战的中心。Gavin King称之为完全言过其实、失败的技术，Cedric Beust也对其成为编程主流思想表示极大的怀疑，但他仍然标榜AOP是非常好的思想，只是仅有一小部分开发专家才能真正掌握。这篇文章的要旨不在于试图使读者成为面向方向编程思想的盲目追捧者，而在于描述一个大金融机构在最后一刻修改了一些横切关注点（cross cutting concern）需求的情况下，这种技术是怎样给现实中的JavaEE项目带来诸多好处的。下文描述的场景和最终实现的解决方案很好地展现了AOP如何弥补OOP在商务应用模块化方面的不足。

问题

我们一直在为一个大型金融机构开发证券交易后台解决方案，所采用的是JavaEE技术，以Oracle 10g RAC做为数据库集群（database cluster），并以Websphere MQ为消息传送中间件。这个项目目前已经进入用户确认测试阶段（UAT phase），也正是在这个阶段中，管理层决定让我们在原有的集群构架上实现透明的应用程序失败转移（failover）服务。

Oracle 10g RAC支持快速连接失败转移（Fast Connection Failover），这给JDBC应用利用这些连接失败转移设施提供了一个好的途径。但真正的挑战在于如何在应用层处理失败转移并通过一个重试-恢复（retry-and-recover）机制对用户实现透明化。

一旦某个Oracle节点发生失败转移，下列事件会依次发生：

• 该节点上的数据库实例失败，该节点的连接缓存中遗留有过时的被破坏的连接。
• 数据库中的RAC机制生成一个RAC事件并发送给含有JDBC的Java虚拟机（JVM）。
• JVM的守护线程（daemon thread）找到所有受RAC事件影响的连接，通过抛出SQL异常通知它们与该节点的连接中断，并且回滚所有尚未提交的事务（open transactions）。当RAC服务失败传送到JDBC应用程序的时候，数据库已经回滚了本地事务。

如果快速连接失败转移（FCF）被激活的话，那么当一个RAC节点失败的时候，连接缓存会自动作废，所有未被使用的连接和另外的节点建立新的连接。然而，对于已经被应用程序使用了的连接则不尽其然。在这种情况下，如果应用程序试图使用在节点失败转移前已经建立的连接，那么它会抛出SQLException异常（ORA-17008,Closed Connection）。应用程序不得不手动重试该连接，快速连接失败转移可以确保下一次尝试连接的成功。

暴力方案

上述问题的解决方案需要通过合适的重试-恢复机制来解决应用程序手动重试的问题。我们意识到在应用层我们需要特殊处理ORA-17008，结合特定处理器以进行自动重试。但是问题在于代码库，这个应用程序的代码已经发展了2年多，其中包括2百多万行Java和JSP代码, 涉及到6000多个类和500多个数据表单，还有数不清的类似于如下的代码片：

long id = ...;
 try {
          Instrument instr = new Instrument(id, conn); } catch(SQLException ex) {
          throw new KeyedException("cam.error.failed.retrieve.instrument",
 ex);
 }
 ... 

对所有类似于上述例子的代码片段来说，SQLException是针对所有数据库相关失败的普通“检查的异常”（checked exception），必须被捕获且遍布代码库各处（上帝，多么痛苦的“检查的异常” :-(......真应该像Spring那样把它封装在“非检查异常”（unchecked exception）中）。暴力方法需要在所有捕获SQLException异常的地方加入特定的处理器。但这个方案不得不被摒弃，因为我们很清楚案例已经进入到用户验证测试阶段，暴力会对代码库造成巨大恶劣的影响，而客户也截然不会乐意看到这些。

引入“方面”思想

经过对代码库进行慎重的分析之后，我们发现受影响的主要领域是需要实现重试-恢复机制的大量服务控件和控制平台。究于历史原因，我们没有使用EJB，取而代之的是所有服务控件和控制平台都由“启动基础类”（launcher base classes）来启动。但需要加入的所有功能依旧涉及到大部分代码库，这恰恰是一个横切关注点。

这个时候，我们想到了结合“方面”的思想来考虑这个问题，最后提出和实现的方案是这样的：

1. 定义一个“切点”（pointcut）来处理SQLException异常。
2. 定义一个“通知”（advice），将在截获异常的切点处此执行的并抛出已定义类型异常（typed exception）
3. 这个错误只会在两个基础类中处理，一个针对服务控件，另一个针对控制后台。这两个类在该错误的处理器中实现重试-恢复的功能。

下面的aspect实现了此机制的基本框架：

public aspect AspectFastConnFailOver
 {
          pointcut sqlHandler(SQLException exception):
          handler(SQLException+) && args(exception);

           // advice to be executed as the handler of SQLException 
          // its derived exception
          before(SQLException exception): sqlHandler(exception){

           ...

          // handle only if non-UI
          if (!Application.getInstance()
          .getContext()
          .getCallerIdentity()
          .isInteractiveUser()) {
                   if(exception.getErrorCode() == Globals.FCF_SQLEX_ERRORCODE)
 {
                        throw new DatabaseNotAvailableError();
             }       } }
 ... }

实现MQ失败转移

针对数据库服务器的透明应用程序失败转移实现以后，我们立刻决定对Websphere MQ服务采用相似的机制。该案例中的Websphere MQ建于使用了Veritas的Storage Foundation 4.0/HA 以及同样来自Veritas的MQ代理服务器的集群配置（cluster configured）之上。

一旦失败转移采用Oracle 10g RAC, 无论失败转移何时发生，都会引发适当的事件，然后向应用程序的JDBC层发送特定的错误代码。基于该错误代码，JDBC将连接池(pool)中未被使用的连接全部作废，并且回滚和当前连接相关的事务。在应用层，我们需要捕捉该错误代码，并写重新尝试得到一个新连接来处理当前情况。如果在失败转移发生之后再发送建立连接的请求，新连接应该会成功地被建立起来。

由于Veritas cluster本质上并不处理失败转移，所以没有任何事件返回给应用层，这导致MQ失败转移的情况要比前者更复杂。应用程序需要侦测到失败转移，然后将连接池中的连接和会话（session）全部作废，并且回滚未提交事务。和SQLException在消息处理方面的能力一样，按照JMS规范说明中所提到的，所有类似于Connection、Session、Receiver、Sender和Browser接口的每个方法潜质上都能够抛出JMSException异常。因此，重试-恢复机制需要通过适当的切点在集中的处理器上实现。

下面这段类似的aspect代码段实现拦截的功能：

public aspect AspectFailOver
 {
         pointcut jmsHandler(JMSException exception): 
         handler(JMSException+) && args(exception)
         && !within(...)
         && !withincode(...));

          // advice to be executed as the handler of JMSException
         // its derived exception

                 before(JMSException exception): jmsHandler(exception){
         ...
                  if (!Application.getInstance()
                  .getContext()
                  .getCallerIdentity()
                  .isInteractiveUser()) {
                           if(isMQFailoverException(exception)) {
                                 throw new MQNotAvailableError();
                           }
                  }
 }         ...
         }
 } 

和oracle失败转移相似，MQNotAvailableError错误在实现启动服务控件和控制后台的基础类中被捕获，以此最终实现重试-恢复的循环。

最小的影响，最好的效果

最后效果非常好！多亏AOP的力量，我们最终达到了将目前代码库所受影响最小化的目标。我们使用了AspectJ并在编译时编织，尽管编译和创建的时间延长了，但客户对因为引进AOP技术而成功地避免了对代码库产生巨大影响这个事实感到非常开心。

关于作者

Debasish Ghosh，Anshin Software的CTO，拥有在跨国IT企业17年之多的工作经验，擅长为各种客户（无论是小公司还是财富500强企业）提供领先的企业领域解决方案。他是 Anshin软件的技术传道士，并对自己将软件设计和编程最佳实践制度化而引以为傲。他热爱Java、Ruby和Scala编程，也曾经沮丧地试图从尚不成体系的C++世界中退隐。作为Anshin软件的核心管理团队的一员， Debasish曾为公司从4人小组发展成今天的150人的规模作出不可磨灭的贡献。最近一段日子以来，他在个人blog（http://debasishg.blogspot.com）上大量地发布文章。

查看英文原文：Application Failover using AOP

1. 返回顶部

   re

   发表人 Wang Potitics

   "作者 沙晓兰" 应该是译者？

   回复

• 更早的 >