微信号:infoqchina

介绍:有内容的技术社区媒体

【实战】维护遗留应用的实用技术

2014-06-26 18:27 InfoQ

我一直在负责维护这种遗留应用程序已经两年多了,在这篇文章中,我想分享我对如何务实地维护一个大的遗留应用程序的经验。

我强调“务实”,因为遗留应用程序可能有很多的技术缺陷,从技术和经济上说处理所有技术缺陷是不可行的。选择正确的方式需要有策略性。

刺探敌情

我们正在维护的大型的遗留应用程序的简要说明:

大房子标识JBoss 4.0。出于某种原因,JBoss 4.0以一些不兼容的方式进行了部分调整,使其难以升级。所以房子构建的有些孱弱(内部正在漏雨)。两个小房子代表了部署到JBoss上的两个Web应用程序(两个WAR包)。一个房子要小得多,并提供更小的功能。每一个页面必须由两个房子提供。有三个连接池,两个事务的机制,一是自制缓存,一个自制的集群机制,一是自制的RMI机制等。

维护遗留应用程序的第一步是理解它。我们要了解应用程序的每一个细节是不切实际的,但我们可以了解整体概貌:

  1. 为什么要用两个WAR包服务于单一页面?两个WAR包相互影响,怎么办?开销是什么?我们如何将它们合并?

  2. 事务是如何处理的?两个WAR包,三个连接池和两个事务机制间的交互是否存在事务失败的风险?

  3. 我们如何知道性能瓶颈在数据库中还是在代码中?如果在代码中,我们如何诊断?

静态代码分析或者不充分,或者不准确。我们开发了一些工具来在运行时监视应用程序,回答这些问题。我们谨慎地以附加组件形式执行这些工具:他们与应用程序代码不耦合,所以它们不产生我们必须维护的额外代码。有关这些工具的更多详细技术细节,看看我的博客。

SQLTracer

此工具可以打开任何一个网页,跟踪那个SQL查询产生问题,发生多少次,以及耗费时间。很重要的是,它为这些查询产生TKPROF,用于性能故障排除。

技术细节

SQLTracer 使用如下逻辑探测JDBC操作:如果页面跟踪已经打开并在ThreadLocal存储页面信息,一个页面请求获得javax.servlet.Filter的检查。当连接从连接池取出的,他们的行动是由AspectJ 切面来捕获,跟踪SQL语句,调用次数和运行时间。使用Oracle DBMS_SESSION.SET_IDENTIFIER()的连接都标有相同的标识符,它们的活动是使用dbms_monitor.client_id_trace_enable()跟踪。这种技术允许跟踪不同的连接。

Perfspy

PerfSpy是一个运行时的日志记录和性能监控工具。我们用它来监视独立页面,它会记录方法调用日志,运行时间,方法,参数和返回值,总之,它步进调试和存储的后续检查的一切信息,你没必要在IDE做到步进调试。它的运行时代码分析和诊断性能瓶颈。它有一个应用程序的用户界面,以树形式显示了方法调用,并提供方法来操作树:隐藏节点,搜索节点,标记节点诸如此类。

技术细节

PerfSpy使用AspectJ来做到运行时监控。PerfSpy有一个抽象的切面,用于记录,监视和跟踪。一旦该切面生效,将查询配置文件来决定它应该收集多少信息和它应该执行什么代码分析。使用PerfSpy,你扩展PerfSpy抽象切面的切面,在扩展切面中指定代码流程以及你想捕获的代码流程的方法。

BLSpy

BLSpy多用于业务逻辑的诊断。很多时候,我们的用户(有时甚至是我们自己)困惑于我们的遗留应用程序所产生的数据;他们想知道应用程序如何计算这些数据。用户可以对业务数据的单一类型进行诊断。

有了这个工具,现在用户能够无需联系我们就能解决这样的问题。我们自己也使用这个工具判断一些计算缺陷。

技术细节

BLSpy是在PerfSpy之上开发的。PerfSpy让我们捕捉到计算代码流程,我们以业务词汇向用户表示计算。例如,我们想传达讯息,如“来计算部门A本周的人力资源成本,我们从A部门获取人力资源的时间记录,并发现了杰森曾维护20小时数据库,以及他的时薪是30元……”。要做到这一点,我们标注了参与计算流程的方法的含义,并在运行时,获取意图,并结合由PerfSpy捕获的方法,向用户展示有意义的信息。

有选择的战斗

遗留应用程序可能像雷区。你愿意挖掘每个地方,你会发现比你预期更大的问题。堵住所有漏洞,在技术上和经济上是不可行的。通常管理方很想收缩维护遗留应用程序的人力资源,使其不断变小,因此每项投资都要算计。

每个功能点的缺陷测算有常用指标。许多用户使用应用程序,当他们遇到他们问题,会将日志工单给我们。在工单中,他们选取发生问题的功能点。然而,这个指标是不够的,因为:

  1. 该指标不能提供架构级缺陷的广阔视野。分类功能问题是很容易的。另一方面,非功能性的问题,如性能问题,可扩展性的问题,以及稳定性问题,尽管他们可能表现在功能点,但根本原因可能越过功能店的范围。例如,在创建订单模块处理慢,或在申诉模块的发起申诉慢,都可能是底层队列机制所造成的。

  2. 它创造的动机使用“权宜之计”的战术来扭转这个数字。例如,我们的交易机制导致了很多脏数据的问题。通常的“权宜之计”的战术将是直接从数据库删除脏数据或在代码中处理脏数据,这种方式可以迅速提升指标,但都没有改善系统运行状况。

我们决定在常用指标之上创建一个指标,我们称之为“高影响”指标。这个指标主要强调困扰遗留应用程序中影响最大的问题,要求高层管理人员的支持改善遗留应用程序的架构。我们定义的“性能”,“稳定性”,“脏数据”,和其他一些非功能性的问题为“高影响”,因为它们要么需要较长的时间来解决,要么经常招致用户问题升级。

进行战斗

使用“高度影响”指标,我们知道想要解决什么;通过各种诊断工具,我们知道如何深入挖掘遗留应用程序的黑盒,我们准备好迎接战斗了。

因为遗留的应用程序往往很少有单元测试,所以重构遗留应用程序可能是相当危险的。在这篇文章中描述了我们的方法。

结论

维护遗留应用程序是一场持续的战争。使用“高影响”指标,我们选择下一个大仗要打。使用各种诊断工具,我们可以发现敌人的底细。使用我们正在建设和不断完善的测试框架,我们能够征服敌人(重构旧代码)。


更多精彩内容,请点击阅读原文。


 
InfoQ 更多文章 Facebook如何实现PB级别数据库自动化备份 学术派Google软件工程师Matt Welsh谈移动开发趋势 Spotify为什么要使用一些“无聊”的技术? 妹纸们放假了,汉纸们做啥? 大多数重构可以避免
猜您喜欢 (送)女神必备!智能魔镜,100%提升化妆技能! 如何创造提高效率的编程工作环境 IXDC创新之旅,穿越科技前沿的硅谷 MD5足够吗----谈PHP中信息加密技术 Network Namespace在Openstack中的应用