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



 写点什么

近日，面向方面编程思想（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）来启动。但需要加入的所有功能依旧涉及到大部分代码库，这恰恰是一个横切关注点。

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

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

下面的 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