转自http://www.ibm.com/developerworks/cn/webservices/ws-itcamtransaction/
一个股票交易公司为最终用户提供了股票交易服务。最终用户通过 Web 浏览器访问股票交易服务，比如 Internet Explorer 和 Firefox，然后执行以下操作：登录/登出系统、查看最新的股票报价、在股票帐户和他们的银行帐户之间转帐，买进/售出股票并查询交易历史。
图 1 展示了交易系统的架构。股票交易服务依赖于图 1 所示的三个服务 —— 客户信息管理服务、股票报价/买入/卖出服务，以及转帐服务。后两种服务由外部提供商提供，因此，不受该股票交易公司的 IT 部门的管理。
股票交易公司要想减少用户投诉并保持用户忠实度，服务的可用性和股票交易系统的响应时间是至关重要的。具体来讲，存在下面几个需求：
- 应当对实际用户所体验的可用性和响应时间进行监视。无论任何时候，只要服务质量降低到预定义的阈值，都应当及时将问题报告给 IT 部门。
- IT 部门可以主动监视系统可用性和响应时间，并在用户报告之前发现问题。
- 当察觉到上面提到的问题时，应当可以很轻松地将问题与特定的组件或交互隔离。
基本上，有两种不同的方法可以监视应用程序的可用性和响应时间，第一种方法是对真实的最终用户的事务进行监视，另一种是主动监视。真实的最终用户事务监视将监视由最终用户触发的事务；而主动监视将通过记录并回放事务来模拟真实的最终用户的体验（如果他们在当时运行了一个事务的话），从而对事务进行监视。
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 架构
要执行本文的步骤来演示如何构建这个完整的解决方案，至少需要使用 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)。
- 定义 Stock Trade 事务以捕捉 HTTP 请求/响应，URL 类似 *TradeSystem*，如图 3 和图 4 所示：
图 3. 定义 Stock Trade 事务的过滤器
图 4. 定义 Stock Trade 事务的 Reporting 模式
- 创建一个 Profile 来包含刚刚定义的事务，然后将 Minimum Response Time 设置为 2 秒，如图 5 所示，然后将 profile 发布给 WRT 代理。
图 5. 创建 profile
- 单击 OK 以确认修改并关闭 AMCE 窗口。
- 通过单击工具栏上的 Situation Editor 图标打开 Situation 窗口。
- 创建如图 6 所示的场景。当应用程序中超过 10% 的事务变慢（长于 2 秒），那么这个场景就会被触发。
图 6. 创建场景
当出现与响应时间有关的问题后，您首先会收到事件通知，这是由您定义的场景触发的，如图 7 所示。
在 Transactions 工作空间中，我们可以看到具体的变慢的事务。显然，从下面的图 8 中，您会看到出现问题的事务是 /TradeSystem/TradeSysCall
在 AMC 工作空间中，可以看到企业环境中的所有应用程序的完整状态。可以从图 9 中看到，最慢的事务 /TradeSystem/TradeSysCall 被 Web Response Time 代理和 Transaction Reporter 代理同时捕获。在后面的小节中，您将看到如何将问题与 Transaction Reporter 代理隔离。
我们可以使用 Rational Performance Tester (RPT) 来记录事务并使用 RRT 代理来回放这些事务，从而执行主动监视。当为我们回放的事务定义好阈值后，我们就可以在出现性能问题时收到警告事件，并在问题影响到真实的最终用户之前采取修复措施。
RPT 是一个性能测试工具，用于识别是否存在系统性能瓶颈以及引起瓶颈的原因，您可以使用它的记录功能来记录希望进行监视的事务。在安装 RPT 后，您就可以开始记录事务并将脚本上传到 AMC 了。这些脚本应当根据真实的最终用户的使用情况进行记录。
在本文中，我们将记录一个名为 BuyStock 的 RPT 脚本，从而模拟一个真实的最终用户在我们的股票交易系统中执行一些主要操作的情景，比如登录、查看股票价格、将资金从银行转到股票帐户，以及购买股票。这个脚本类似图 10 所示：
在记录好 RPT 脚本后，您可以将它们上传到 AMC 并定义一个 profile 来回放它们。如图 11 所示，您可以定义一个名为 StockApp 的 profile，每 15 分钟回放一次脚本 BuyStock，然后为其定义一个性能阈值。该阈值应当根据平均体验值或服务水平协议定义。Min Response Time Threshold 属性用于定义该阈值，在这里我们将事务阈值设置为 10.0 秒。
当您在 RRT 代理上回滚了 RPT 脚本后，就可以从 AMC 代理工作空间中查看事务响应时间数据。该工作空间列出了在我们的整个环境中进行监视的所有应用程序。当应用程序的响应时间慢于 Min Response Time Threshold，它的 Overall Status 将被修改为 Warning 或 Critical，如图 12 所示：
当我们注意到 BuyStock 应用程序的 Overall Status 变为 critical 时，我们可以连接到相应的 RRT 代理来查看此应用程序的详细信息，例如，我们可以向下钻取此应用程序的事务和子事务，以找出最慢的事务和子事务。
可以从图 13 中看到，脚本 BuyStock 的响应时间被分解为包含在该脚本中的每个子事务的响应时间。您可以看到 TradeResult 是最慢的事务。在我们的股票交易系统中，TradeResult 的任务就是将交易请求提交到后端系统并将交易结果反应给最终用户。要找出引起事务响应时间变慢的因素，我们可以使用 Transaction Tracking 代理来帮助我们分离问题。
当我们找到响应时间最慢的事务后，可以使用 TC 代理和 TR 代理来向下钻取该事务并分离可能引起性能下降问题的组件，比如 web 应用服务器、数据库或后端 web 服务。
1. 在上下文中从 AMC 工作空间启动到 Transaction Reporter 工作空间
转到 AMC 工作空间并展开 Applications 节点，找到 BuyStock 项，单击它，随后我们可以看到在 Transactions 表中有两个项，一个用于 RRT 代理，另一个用于 TR 代理。右键单击 Transaction Reporter 代理项的链接锚点；当弹出一个菜单后，选择 Transaction Topology 选项，如图 14 所示，它将链接到 Transaction Reporter Agent 的 Transaction Topology 工作空间。
2. 在 Transaction Reporter 工作空间中分离问题
在此工作空间中，我们看到了 Buy Stock 事务的完整拓扑。从图 15 的拓扑中可以看到，fundCall 节点上有一个红色箭头，它表示正是该节点使 Buy Stock 事务变慢。通过进行分析，fundCall 的响应时间就是用于调用 Bank 服务的响应时间。因此，造成性能下降的根本原因是因为 Bank 服务的响应时间较慢，这属于外部服务问题。随后我们可以要求 Bank 服务的提供商处理它。
本文描述了在 SOA 环境中用于解决典型响应时间变慢问题的基于 ITCAM for Transactions 的解决方案，并展示了如何部署和配置它。
来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/14780828/viewspace-665650/，如需转载，请注明出处，否则将追究法律责任。
转载于:http://blog.itpub.net/14780828/viewspace-665650/
扫一扫
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
