内容


在 SOA 环境中使用 Tivoli Composite Application Manager for Transactions 实现可用性和响应时间管理:案例研究

Comments

案例介绍

一个股票交易公司为最终用户提供了股票交易服务。最终用户通过 Web 浏览器访问股票交易服务,比如 Internet Explorer 和 Firefox,然后执行以下操作:登录/登出系统、查看最新的股票报价、在股票帐户和他们的银行帐户之间转帐,买进/售出股票并查询交易历史。

图 1 展示了交易系统的架构。股票交易服务依赖于图 1 所示的三个服务 —— 客户信息管理服务、股票报价/买入/卖出服务,以及转帐服务。后两种服务由外部提供商提供,因此,不受该股票交易公司的 IT 部门的管理。

图 1. 交易系统架构
交易系统架构
交易系统架构

股票交易公司要想减少用户投诉并保持用户忠实度,服务的可用性和股票交易系统的响应时间是至关重要的。具体来讲,存在下面几个需求:

  1. 应当对实际用户所体验的可用性和响应时间进行监视。无论任何时候,只要服务质量降低到预定义的阈值,都应当及时将问题报告给 IT 部门。
  2. IT 部门可以主动监视系统可用性和响应时间,并在用户报告之前发现问题。
  3. 当察觉到上面提到的问题时,应当可以很轻松地将问题与特定的组件或交互隔离。

使用 ITCAM 提供事务解决方案

基本上,有两种不同的方法可以监视应用程序的可用性和响应时间,第一种方法是对真实的最终用户的事务进行监视,另一种是主动监视。真实的最终用户事务监视将监视由最终用户触发的事务;而主动监视将通过记录并回放事务来模拟真实的最终用户的体验(如果他们在当时运行了一个事务的话),从而对事务进行监视。

ITCAM for Transactions 7.1 提供了一个全面的解决方案来满足 SOA 环境中对服务可用性和响应时间管理的需求,并且同时支持真实的最终用户事务监视和主动监视。ITCAM for Transactions 是一个构建在 IBM Tivoli Monitoring 框架之上的代理集合,具体包括:

  • Web Response Time (WRT) 代理实时监视真实的最终用户可用性和响应时间体验。
  • Robotic Response Time (RRT) 代理使用记录的回放脚本主动监视服务可用性和响应时间。
  • 当出现与可用性和响应时间有关的问题时,Transaction Collector (TC) 代理和 Transaction Reporter (TR) 代理将隔离问题并使用事务拓扑图进行诊断。

服务可用性和响应时间是从事务的角度进行监视的。在本文的场景中,典型的事务例子包括股票买进、股票报价、转帐,等等。下面的图 2 展示了解决方案架构。

图 2. ITCAM for Transactions 架构
ITCAM for Transactions 架构
ITCAM for Transactions 架构

要执行本文的步骤来演示如何构建这个完整的解决方案,至少需要使用 6 台机器(机器 M1 到 M6)。

您需要按照以下方式配置基础环境:

  • 在机器 M1 上安装 Tomcat 5.5,然后将 StockCenterProject.war 部署到这个 Tomcat。
  • 在机器 M2 上安装 Tomcat 5.5,并将 BankFundService.war 部署到这个 Tomcat。
  • 在机器 M3 上安装 WebSphere Application Server 6.1,并将 TradeSystem.war 部署到这个 WebSphere Application Server。
  • 在机器 M4 上安装 DB2 8.5 或更高版本,并创建客户信息数据库。

我们在此使用 Tomcat 而不是使用 WebSphere 托管 Stock Exchange Center 和 Bank 应用程序的原因是它们都是外部服务,应用服务器的类型并不重要。

ITCAM 解决方案产品应当按照以下方法进行安装和配置:

  • 安装 ITM 6.2, ITCAM for Transactions – 在机器 M5 上安装 AMC 代理和 TR 代理。
  • 安装 ITCAM for Transactions – 在机器 M3 上安装 WRT 代理和 TC 代理。
  • 安装 ITCAM for Transactions – 在 M6 上安装 RRT 代理。

假设您具有基本的 ITM 知识。如果对它们不熟悉的话,请参考 “术语” 部分,并参考 ITM 信息中心了解详细内容。

监视真实的最终用户事务

WRT 代理通过观察来自网卡的 HTTP 请求/响应来监视真实的最终用户的事务可用性和响应时间。您首先需要将 HTTP URL 映射到有意义的业务事务,然后创建 ITM Situations 来定义阈值。要完成这些任务,需要执行以下步骤:

创建事务定义

通过单击工具栏上的 Application Management Configuration 图标,打开 Application Management Configuration Editor (AMCE)。

  1. 定义 Stock Trade 事务以捕捉 HTTP 请求/响应,URL 类似 *TradeSystem*,如图 3 和图 4 所示:
    图 3. 定义 Stock Trade 事务的过滤器
    定义 Stock Trade 事务的过滤器
    定义 Stock Trade 事务的过滤器
    图 4. 定义 Stock Trade 事务的 Reporting 模式
    定义 Stock Trade 事务的 Reporting 模式
    定义 Stock Trade 事务的 Reporting 模式
  2. 创建一个 Profile 来包含刚刚定义的事务,然后将 Minimum Response Time 设置为 2 秒,如图 5 所示,然后将 profile 发布给 WRT 代理。
    图 5. 创建 profile
    创建 profile
    创建 profile
  3. 单击 OK 以确认修改并关闭 AMCE 窗口。

创建解决方案

  1. 通过单击工具栏上的 Situation Editor 图标打开 Situation 窗口。
  2. 创建如图 6 所示的场景。当应用程序中超过 10% 的事务变慢(长于 2 秒),那么这个场景就会被触发。
    图 6. 创建场景
    创建场景

出现问题后……

当出现与响应时间有关的问题后,您首先会收到事件通知,这是由您定义的场景触发的,如图 7 所示。

图 7. 场景被触发后将弹出事件
场景被触发后将弹出事件
场景被触发后将弹出事件

在 Transactions 工作空间中,我们可以看到具体的变慢的事务。显然,从下面的图 8 中,您会看到出现问题的事务是 /TradeSystem/TradeSysCall

图 8. WRT Workspace 显示事务信息
WRT Workspace 显示事务信息
WRT Workspace 显示事务信息

在 AMC 工作空间中,可以看到企业环境中的所有应用程序的完整状态。可以从图 9 中看到,最慢的事务 /TradeSystem/TradeSysCall 被 Web Response Time 代理和 Transaction Reporter 代理同时捕获。在后面的小节中,您将看到如何将问题与 Transaction Reporter 代理隔离。

图 9. AMCE 工作空间显示事务的完整状态
AMCE 工作空间显示事务的完整状态
AMCE 工作空间显示事务的完整状态

主动监视服务可用性和响应时间

我们可以使用 Rational Performance Tester (RPT) 来记录事务并使用 RRT 代理来回放这些事务,从而执行主动监视。当为我们回放的事务定义好阈值后,我们就可以在出现性能问题时收到警告事件,并在问题影响到真实的最终用户之前采取修复措施。

1. 使用 RPT 记录脚本,将脚本上传到 AMC

RPT 是一个性能测试工具,用于识别是否存在系统性能瓶颈以及引起瓶颈的原因,您可以使用它的记录功能来记录希望进行监视的事务。在安装 RPT 后,您就可以开始记录事务并将脚本上传到 AMC 了。这些脚本应当根据真实的最终用户的使用情况进行记录。

在本文中,我们将记录一个名为 BuyStock 的 RPT 脚本,从而模拟一个真实的最终用户在我们的股票交易系统中执行一些主要操作的情景,比如登录、查看股票价格、将资金从银行转到股票帐户,以及购买股票。这个脚本类似图 10 所示:

图 10. RPT 脚本窗口
RPT 脚本窗口
RPT 脚本窗口

2. 为 RRT 定义 profile 以回放脚本

在记录好 RPT 脚本后,您可以将它们上传到 AMC 并定义一个 profile 来回放它们。如图 11 所示,您可以定义一个名为 StockApp 的 profile,每 15 分钟回放一次脚本 BuyStock,然后为其定义一个性能阈值。该阈值应当根据平均体验值或服务水平协议定义。Min Response Time Threshold 属性用于定义该阈值,在这里我们将事务阈值设置为 10.0 秒。

图 11. 用于 RPT 脚本回滚的 Profile 定义
用于 RPT 脚本回滚的 Profile 定义
用于 RPT 脚本回滚的 Profile 定义

3. 识别最慢的事务

当您在 RRT 代理上回滚了 RPT 脚本后,就可以从 AMC 代理工作空间中查看事务响应时间数据。该工作空间列出了在我们的整个环境中进行监视的所有应用程序。当应用程序的响应时间慢于 Min Response Time Threshold,它的 Overall Status 将被修改为 Warning 或 Critical,如图 12 所示:

图 12. AMCE 工作空间中的应用程序状态
AMCE 工作空间中的应用程序状态
AMCE 工作空间中的应用程序状态

当我们注意到 BuyStock 应用程序的 Overall Status 变为 critical 时,我们可以连接到相应的 RRT 代理来查看此应用程序的详细信息,例如,我们可以向下钻取此应用程序的事务和子事务,以找出最慢的事务和子事务。

可以从图 13 中看到,脚本 BuyStock 的响应时间被分解为包含在该脚本中的每个子事务的响应时间。您可以看到 TradeResult 是最慢的事务。在我们的股票交易系统中,TradeResult 的任务就是将交易请求提交到后端系统并将交易结果反应给最终用户。要找出引起事务响应时间变慢的因素,我们可以使用 Transaction Tracking 代理来帮助我们分离问题。

图 13. RRT 工作空间中的子事务信息
RRT 工作空间中的子事务信息
RRT 工作空间中的子事务信息

分离性能下降问题

当我们找到响应时间最慢的事务后,可以使用 TC 代理和 TR 代理来向下钻取该事务并分离可能引起性能下降问题的组件,比如 web 应用服务器、数据库或后端 web 服务。

1. 在上下文中从 AMC 工作空间启动到 Transaction Reporter 工作空间

转到 AMC 工作空间并展开 Applications 节点,找到 BuyStock 项,单击它,随后我们可以看到在 Transactions 表中有两个项,一个用于 RRT 代理,另一个用于 TR 代理。右键单击 Transaction Reporter 代理项的链接锚点;当弹出一个菜单后,选择 Transaction Topology 选项,如图 14 所示,它将链接到 Transaction Reporter Agent 的 Transaction Topology 工作空间。

图 14. 在上下文菜单中启动
在上下文菜单中启动
在上下文菜单中启动

2. 在 Transaction Reporter 工作空间中分离问题

在此工作空间中,我们看到了 Buy Stock 事务的完整拓扑。从图 15 的拓扑中可以看到,fundCall 节点上有一个红色箭头,它表示正是该节点使 Buy Stock 事务变慢。通过进行分析,fundCall 的响应时间就是用于调用 Bank 服务的响应时间。因此,造成性能下降的根本原因是因为 Bank 服务的响应时间较慢,这属于外部服务问题。随后我们可以要求 Bank 服务的提供商处理它。

图 15. TR 工作空间中的事务拓扑视图
TR 工作空间中的事务拓扑视图
TR 工作空间中的事务拓扑视图

结束语

本文描述了在 SOA 环境中用于解决典型响应时间变慢问题的基于 ITCAM for Transactions 的解决方案,并展示了如何部署和配置它。

术语

  • 场景:一个条件集合。当这些条件得到满足后,将触发一个事件。
  • 阈值:阈值是一些可自定义的值,比如,用于定义事务可接受的最大响应时间。
  • Profile:Profile 用于定义您需要对哪些事务进行监视,何时执行监视,以及在哪些位置执行监视。对于主动监视,您还可以定义回放脚本的时间间隔,从而模拟最终用户对应用程序的访问。
  • 应用程序:一个应用程序表示将要被监视的一个业务流程。
  • 事务:完成某个特定操作或结果的一个交换操作。事务可以发生在工作站和程序之间,两个工作站之间,或两个程序之间。一个被记录的事务包含一个或多个子事务。当一个事务及其子事务被放在一起考虑时,它被称为父事务。子事务表示父事务的孩子。
  • AMC:Application Management Console 代理是 ITCAM for Transactions 代理的一种,用于配置监视环境,并进行呈现……
  • WRT:Web Response Time 代理是 ITCAM for Transactions 代理的一种,它用于以实时的方式监视 web 应用程序的响应时间。
  • RRT:Robotic Response Time 代理是 ITCAM for Transactions 代理的一种,它用于模拟真实的最终用户对 web 应用程序的访问,并以主动方式监视 web 应用程序的响应时间。
  • RPT:Rational Performance Tester 是一种性能测试工具,用于识别系统性能瓶颈及其原因。

下载资源


相关主题

  • 深入剖析 ITCAM for SOA 与 WebSphere Service Registry and Repository 的集成”(developerWorks,2007 年 7 月): 本文从体系结构的角度系统地介绍了 IBM Tivoli Composite Application Manager for SOA(ITCAM for SOA) 和 IBM WebSphere Service Registry and Repository (WSRR) 的集成架构,详细说明了集成模块 ITCAM for SOA Event Handler 的技术细节,以及动态地在 IBM WebSphere Service Registry and Repository 中记录和存储服务性能元数据的方法。
  • 使用 ITCAM for WAS 对 Websphere 进行监控管理和问题诊断”(developerWorks,2008 年 2 月): 本文通过一些实例说明如何用 ITCAM for WebShpere 对 WebSphere 的三个管理层面做监控管理和分析,其中列举了 WebSphere 管理员最关心的性能问题的监控和对内存泄漏问题的诊断。ITCAM for WebShpere 是一个非常强大的 WebSphere 管理工具,它的另一组件——ITCAM for J2EE 能够对 Weblogic、JBoss、Oracle App Server、Tomcat 等其它中间件进行深入的监控分析,形成对中间件和复合应用的完整监控。
  • ITCAM for Websphere v6.0 与 ITM v6.1 集成的快速指南”(developerWorks,2008 年 6 月):本文简单清晰地介绍了 ITCAM Websphere 的工作原理、安装配置和集成后的功能与效果,是一个良好的 ITCAM for Websphere v6.0 与 ITM v6.1 集成的快速指南本文适用于对 Websphere 及其应用监控与诊断分析感兴趣的朋友,适用于 IT 管理员、Webshpere 管理员、应用管理员,可以帮助他们快速的了解并实施。
  • 使用ITCAM for WebSphere进行性能诊断”(developerWorks,2008 年 12 月):本文以 ITCAM for WebSphere 在 WebSphere Application Server (简称 WAS)自带样本应用中的性能诊断为例,介绍了借助于此类专业工具快速定位性能瓶颈的思路。
  • SOA 和 Web 服务 中,获得提高 Web 服务技能所需的资源。
  • 下载 ITCAM for Transactions 产品评估版本,研究它并开始使用来自 DB2®、Lotus®、Rational®、Tivoli® 和 WebSphere® 的应用程序开发工具和中间件产品。

评论

添加或订阅评论,请先登录注册

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=SOA and web services
ArticleID=495152
ArticleTitle=在 SOA 环境中使用 Tivoli Composite Application Manager for Transactions 实现可用性和响应时间管理:案例研究
publish-date=06102010