SOA 项目示例性能指标与测试

SOA 项目示例
某航空公司A，为完善其信息系统，需要对航线服务产品、客户服务、业务流程等进行整合。

一方面，现有系统缺乏对信息共享性、系统兼容性和接口标准规范的统一考虑，造成子系统之间的连接比较困难，应用和数据无法得到全面共享，系统间网状连接普遍存在。

随着子系统的不断增加，在业务和流程方面的整合将会因业务领域间的信息沟通障碍及子系统之间的紧耦合面临越来越多的困难。

在经过广泛的调研之后，A 公司决定采用基于SOA 架构的信息共享体系结构（ESB）建设信息共享平台，将现有的各应用系统之间可以共享、共用的数据和服务发布到共享平台上供其它业务使用。

图1. 基于SOA/ESB 的架构
.
由于采用基于标准的接口定义方式，使得各子系统间的耦合度大大降低，而且服务请求者与服务提供者不产生直接依赖，双方的独立变化均可以不对对方造成任何影响。

另一方面，统一的接口和高度的模块化使得业务流程的组装变得极为容易。

对于企业级应用而言，灵活性和可扩展性固然是极其重要的设计原则，但是如果以极大地牺牲服务性能为代价，则显然是不可取的。

相对于点对点的服务连接方式，ESB 的引入不可避免地会对整体服务性能造成或多或少的影响，因此ESB 本身的性能要作为设计之初的重要考量以及验收的重要指标。

测试策略
测试性能指标
对于大部分ESB 项目而言，通常都需要覆盖到以下性能指标：
最大并发请求数。

ESB 在该并发请求数的访问下，在一段时间内可以正常提供服务（满足响应时间、吞吐量、稳定性等指标）。

该指标的制定主要以业务高峰时段的运营历史数据作为依据，以保证系统在业务高峰时段能正常提供服务。

∙平均并发请求数。

ESB 在该并发请求数的访问下可以稳定运行较长时间（满足响应时间、吞吐量、稳定性等指标）。

该指标的制定主要以普通时段的运营历史数据作为依据，以保证系统在大部分时间可以持续稳定运行。

∙最大平均响应时间。

ESB 中各服务在稳定运行的情况下，在ESB 内部处理请求的平均时间不超过最大平均响应时间。

该指标的制定与特定服务的复杂程度，并发请求数有密切联系，一般而言，1s 以下的平均响应时间是可以接受的。

如果平均响应时间较大，将无法满足交互性需求。

∙吞吐量。

ESB 在单位时间内成功处理的请求数。

该指标的制定主要以实际业务数作为依据，以保证系统的业务处理能力满足生产需求。

∙稳定性。

在较长的时间内（如7*24 小时），ESB 可以持续提供服务，并且请求响应成功率较高（比如>95%）。

该指标包含了稳定持续时间、平均并发请求数、成功率三部分。

对于航空公司而言，7*24 小时的稳定持续时间是必要的，请求响应成功率也往往需要达到95% 甚至更高。

∙服务能承受的压力极限。

即超过这个压力之后，将会导致服务的崩溃（此处需要对服务崩溃定义，如响应成功率低于5%，或平均响应时间超过3s 等）。

该指标受服务器硬件性能影响较大，因此很难在测试之前进行预估。

通常这是作为一个检验性（而非验证性）指标，为生产维护和系统更新（如硬件更新）提供参考和建议。

∙最佳并发请求数。

ESB 在该并发请求数的访问下，在一段时间内可以正常提供服务（满足响应时间、吞吐量、稳定性等指标），且平均响应时间最接近最大平均响应时间指标。

与第一条指标不同的是，最大并发请求数是以实际的运营数据作为依据，而最佳并发请求数则是作为一个检验性指标，为生产维护提供参考。

那么，围绕这些性能指标，如何进行ESB 的性能测试呢？先来看看基于ESB 的请求- 响应模型。

测试对象模型
以短信单发服务和航班查询服务为例，在生产环境中，它们的服务消息流如下图所示：
图2. 实际生产中的消息流
图中的client 可能为终端用户或其它子系统。

可以看到，消息流分为两段。

第一段是client 和ESB 内部服务之间的消息流，第二段是ESB 内部服务和后台服务之间的消息流。

诚然，在真实生产中，ESB 内部服务和后台服务缺一不可。

但是如果按上述模型进行性能测试，将面临以下问题：
∙我们的测试目的是验证ESB 的引入对整个系统的影响，而不是端到端的性能。

∙通常而言，ESB 内部的服务逻辑较为简单，因此影响端到端性能的主要因素是后台服务。

而后台服务种类繁多，功能各异，针对每个不同服务制定性能指标显然是不合理的。

∙后台服务可能是遗留系统，已经过单独的性能测试和生产运营的验证，不需要再次进行测试。

∙ESB 与后台服务在实现上是独立的，在测试的时候某些后台服务可能尚未接入。

因此针对性能测试，不妨对系统进行闭环改造：
图3. 更改后的消息流
client 的请求报文经过ESB 内部服务的处理后，不再发送给后台服务，而是模拟后台服务的响应报文，再经过ESB 内部服务的处理，返回给client。

为了降低开销，我们将模拟的后台服务的响应报文设为固定报文。

而对于client 而言，这个改动从某种程度上讲是透明的，因为请求报文与响应报文的格式均与生产环境完全一致。

确定了测试模型，下面就以短信单发和航班查询为例，介绍如何使用RPT for SOA 进行性能测试。

回页首测试场景
在介绍RPT 之前，结合之前提到的性能指标，我们不妨罗列几个针对上述测试对象的典型性能测试场景：∙短信单发/ 航班查询/ 混合服务在最大用户数下的平均响应时间（容量测试）
∙发送混合类服务请求，将负载用户逐渐增加，直至服务端崩溃，以检测服务负载能力的临界点（压力测试）
∙在最大用户数下持续执行测试一段时间（如7*24 小时）（稳定性测试）
对于以上测试场景，涉及到的问题或需要测试工具具备的功能可能有：
∙高负载生成
∙测试数据的实时监控
∙动态报文
∙分布式负载
∙自定义图表
RPT for SOA 是否具备这些功能？接下来我们就围绕上述测试场景，逐步了解RPT for SOA 以及如何利用RPT for SOA 的各项特性解决测试中的问题，完成测试。

测试准备
IBM® Rational® Performance Tester (RPT) 是一款性能测试工具，它通过模拟一定量用户的各种操作来
实现实际生活中的用户负载的虚拟，并且提供实时监控，图表生成等功能。

IBM® Rational® Tester for SOA quality 则是RPT 面向SOA 测试的一个扩展。

本文所述RPT for SOA 均是以上两个组件的集合。

构建RPT for SOA 测试环境
引入测试系统后，整个测试环境的网络拓扑结构如下所示：
图4. 测试环境
可以看到，RPT 采用workbench-agent 的部署模型，可以对agent 进行分布式部署（关于分布式部署
的细节问题，请参照分布式负载）。

Workbench 负责脚本、Schedule 的创建，agent 的控制，测试数据监控等，而agent 则是真实客户的模拟，负责请求报文的发送和响应报文的接收。

完整的请求- 响应消息流路径为：
1. Workbench 将测试信息传达给agent（多台同时），驱动agent 进行测试活动；
2. Agent 发送请求至load balancer；
3. Load balancer 对请求进行分发，以轮询的方式按1:1 发送至两台ESB Server；
4. ESB 内部服务对DB 进行数据读写操作；
5. ESB 内部服务处理完请求报文后，生成响应报文，按(3)(2)(1) 路径返回，更新workbench 的
实时图表。

为了构建一个完整的高负载的分布式测试环境，我们需要安装（导入）以下组件（license）：
1. IBM® Rational® Performance Tester（RPT 主体文件，安装于workbench）
2. IBM® Rational® Tester for SOA quality（RPT for SOA 扩展，安装于workbench）
3. IBM® Rational® License Server（License Server，安装于workbench）
4. IBM® Rational® Performance Tester Extension for SOA Floating License（导入License Server）
5. IBM® Rational® Test XYZ Virtual Tester Pack Floating License Key（XYZ 为相应的虚拟用户数，
如5000，导入License Server）
6. IBM® Rational® Agent Controller（每台Agent 机上均需安装）
如果要对ESB server 进行系统资源监控，则需要在server 上开启/ 安装系统资源监控服务/ 工具（如rstatd，Tivoli 等）。

回页首RPT 图形用户界面
RPT 构筑于Eclipse 框架之上，如果接触过Eclipse 或其它基于Eclipse 的产品，应该不会对RPT 的图形界面感到陌生。

图5. RPT GUI
图 5 大图
默认的视图为Test（在这个视图可以方便地创建/ 配置/ 运行测试资源，并提供图形化支持），在Test Navigator 中进行测试资源的CRUD 操作。

当然也可以切换回Java 视图，对原生的Java 类进行更改。

图6. 视图选择窗口
回页首创建SOA 脚本
以混合服务的容量测试为例，首要任务就是创建Web Service 测试脚本（对于短信服务和航班服务需要分别创建独立的脚本）。

测试脚本是RPT 的基础单元之一，封装了服务URL，请求报文，期望响应报文，验证点等核心的测试业务逻辑，是测试必不可少的组成部分。

在RPT 中可以很方便地通过图形化的方式进行测试脚本的创建和配置。

通常来说，可以以录制或手动的方式来创建测试脚本。

对于SOA 测试而言，手动创建脚本是个较好的选择。

以下就简要介绍一下手动创建SOA 测试脚本的步骤：
1. 首先创建一个test project。

在菜单栏中选择File->New->Others…，并在弹出页面中选
取Test->Test Assets->New Web Service Test。

图7. 创建Web Service 测试脚本
2. 依照创建向导进行配置，直至Select service Call Interface这一步。

若之前未曾导入过WSDL
文件，则需通过Add...先导入短信（航班）服务的WSDL 文件（如果没有WSDL 文件，但是知道服务URL，完整的请求报文等信息，也可在此导入任意WSDL，然后在配置脚本时更改报文内容，具体参照配置测试脚本一节），并选择需要测试的接口（我们的短信服务的WSDL 文件中一共包含了 5 个接口的描述，选择短信单发接口）。

图8. 选择Web Service 调用接口
3. 在下一步：Configure Protocol中可以对网络协议相关的配置进行更改，比如服务URL，协议
类别，方法，版本等。

图9. 配置协议
4. 点击finish，测试脚本就创建完成了。

可以在Test Navigator的相应test project下看到类似于
的图标。

回页首配置测试脚本
我们可以看到，在创建测试脚本的过程中，只指定了请求报文和服务URL；而对于本次测试来说，不仅有请求响应成功率的指标，而且对于稳定性测试来说，如果有大量请求响应失败，显然也是不能忍受的，因此我们还需要设定期望响应报文，对真实响应报文进行验证。

期望响应报文无法在测试脚本的测试过程中进行指定，但是我们可以在完成脚本的创建后对其进行配置。

双击Test Navigator下的script图标，可以打开脚本配置的主窗体。

图10. 测试脚本主窗体
主窗体由Test Contents和Test Element Details两部分组成，Test Contents是一个树型结构，点击不同层次的元素可以进行相应的配置。

默认情况下选择的是根元素，可以进行脚本级别的配置。

通常情况下对于这一层次保持默认配置即可。

点击Test Contents的一级子元素，可以对请求报文进行配置。

图11. 配置请求报文
图11 大图
对于本次测试来说，需要关心的有：
∙Overview/Source：请求报文（XML）的不同显示形式，会根据导入的WSDL 自动生成。

在我们的测试中，由于已知完整的请求报文，打开Source 选项卡，将里边的内容替换掉即可。

∙Protocol：包含了网络协议相关的一些配置，也可以在此修改服务URL。

如果在WSDL 文件中已经包含了正确的URL（参照创建SOA 脚本），则此处无需修改。

∙Security for Call/Return：报文中安全相关的配置。

安全头可以直接写入到Source 中。

右键点击Test Contents中的请求报文，选择Add->Web service Return，可以创建该请求报文的期望响应报文。

图12. 添加返回报文
创建过程中有两个选择：
∙如果服务尚不可用，则创建空响应报文，并手动进行填充。

∙如果服务可用，则通过Update方式获取真实响应报文（一般而言，功能测试会先于性能测试完成，因此通过这种方式获取的响应报文往往是正确的。

当然如果不正确也可以在创建完成后进行修改）。

期望响应报文创建完成后，Test Contents显示如下：
图13. 返回报文添加成功
回页首报文验证
通常来说，具备输入，期望输出，测试步骤（对于本项目而言就是简单的发送报文），一个测试用例就算是完整了。

但是对于SOA 测试而言，有些时候我们的期望输出并不是一个固定的静态报文，我们可能需要：
∙真实响应报文只要包含指定的报文段即算测试通过。

∙忽略命名空间的验证。

响应报文中部分XML 元素的命名空间可能不是固定的，但我们并不关心它。

∙某个字段的值只需匹配一个正则表达式即算测试通过。

RPT 提供了验证点（Verification Point）的概念，来解决上述问题。

验证点可以通过右键点击期望响应报文->Add->选择VP 类别进行添加。

图14. 验证点类别
目前RPT 中支持四类验证点：
∙Contain Verification Point：响应报文只需包含指定的报文段即算测试通过。

在VP 中指定被包含的报文段。

∙Equal Verification Point：真实响应报文须与期望响应报文相同才算测试通过。

事实上可以通过设置忽略譬如命名空间的验证（见下面部分）。

∙Query Verification Point：根据XPath表达式对响应报文进行查询，若节点数与期望节点数的关系符合配置项（大于/ 等于/ 小于），则算测试通过。

∙Attachment Verification Point：依据报文附件进行验证。

为我们的脚本添加Equals Verification Point 后，Test Contents更新如下：
图15. 验证点添加成功
对于Contain VP 和Equal VP，在Test Element Details中可以设定是否验证命名空间/ 文本节点
/XML 属性：
图16. 验证选项
由于本次测试中包含动态的命名空间，因此将命名空间的验证去掉。

回页首Performance Schedule
测试脚本已经包含了测试的必备条件，可以直接运行，但是有以下问题：
∙无法指定负载数量、测试持续时间、Think Time 等调度信息，虚拟用户数固定为1 个，只会发送和接收一次报文。

∙缺少系统资源监控配置项，无法生成相应图表。

∙无法实现分布式负载。

∙无法实现其它较复杂的部署和调度功能。

通过Performance Schedule，可以很好地解决这些问题。

创建Performance Schedule 的步骤非常简单，选择菜单栏上的File->New->Performance Schedule即可。

创建完成后，双击打开其主窗体，初始界面如下：
图17. Performance Schedule 主窗体
图17 大图
窗体结构与测试脚本类似。

初始情况下，右侧显示的是schedule 全局的配置项，包含了一系列小项。

常用的配置项有以下这些：
User Load：设置虚拟用户数，测试持续时间，虚拟用户变化规律（一开始就将虚拟用户加到最大，或以一定的速率逐渐递增）。

对于最大/ 平均/ 最佳并发请求数指标的验证，都可以在此设定并发数。

Think Time：设置从接收到响应报文到发送下一个请求报文之间的时间间隔。

适当地选取Think Time，既能准确地再现真实场景，也能在保证并发数的情况下，减轻服务器与客户机的压力。

Resource Monitoring：服务器系统资源监控相关配置（参照测试执行）。

目前支持的数据源有：∙IBM Tivoli Monitoring
∙Unix rstatd monitor
∙Windows Performance Monitor
涵盖了绝大多数的操作系统。

Statistics：测试过程中实时数据相关的一些配置，包括取样间隔，取样对象（取所有或部分虚拟用户的数据）等。

如果测试持续时间较长（比如稳定性测试），则应适当延长取样间隔（如30 分钟取样一次），以提高结果图表的可读性，不同降低workbench 的压力。

通过schedule 的全局配置项可以满足我们绝大部分的需求，但有些配置需要针对单个User Group 进行。

点击Schedule Contents中的User Group，Schedule Element Details显示如下：
图18. User Group 配置
在此可以指定group 的大小（绝对值/ 百分比），以及group 的位置（在分布式负载一节对此做详细介绍）。

接下来就可以对User Group 添加测试脚本了。

由于7.0 版本的一个问题，直接添加测试脚本将不会按照脚本中设定的持续时间运行，可以在User Group 下先添加一个Loop（Duration 设为Infinite），然后再在Loop 下添加脚本即可。

完成后的Schedule Contents 如下所示：
图19. 添加Loop
回页首分布式负载
分布式负载是性能测试工具一个很重要的特性，通过分布式负载，可以达到以下目的：∙使测试更接近现实。

在生产环境中，很少有请求均来自于同一个地址的情况。

∙有效地降低客户机（Agent 所在机器）的负载。

在虚拟用户数较大的情况下，客户机性能可能成为瓶颈，导致请求发送堵塞，甚至崩溃（值得注意的是，如果一台客户机足以承受负载，则增加客户机未必能提高性能，甚至可能起反作用）。

∙突破网络限制。

Workbench 和服务器可能分属两个不同的子网，两者交互要经过路由器和防火墙，导致最后得出的响应时间极大地收到网络开销的影响。

通过workbench 远程控制一台与服务器
处于同一子网的agent，就可以解决这个问题。

现在考虑测试混合服务在最大用户数下的平均响应时间这个场景。

局域网内有两台客户机
（192.168.0.33/34，见构建RPT for SOA 测试环境），现在分别用它们发送短信单发和航班查询请求。

首先为performance schedule 添加一个新的User Group 和测试脚本。

根据以前的运营统计数据来看，短信请求和航班请求的比率约为4:6，因此设定两个User Group 的group size 分别为40% 和60%。

图20. 添加新的User Group
图21. 设置User Group 的location
在Response Time vs. Time Details 图表（测试执行一章中包含了更多关于测试图表的信息）中，可以看到不同请求的响应情况。

图22. Response Time vs. Time Details
回页首数据池
数据池用以为测试提供可变值。

在创建测试脚本的时候，我们提供了输入值，测试步骤及预期输出，在测试的每一个迭代，我们发送完全一致的请求报文。

完全一致的报文可能导致以下问题：∙与真实的情况不符。

在生产环境中，请求报文不会一成不变。

∙缓存问题。

由于服务端一直保存着该请求的响应报文的缓存，使得响应时间偏小。

使用数据池可以解决或部分解决这些问题。

以下以短信单发服务的短信内容为例，介绍如何为其添加数据池：
1. 通过File->New->Datapool新建数据池。

图23. 创建数据池
2. 打开datapool，为其添加数据条目。

图24. 为数据池添加记录
3. 打开短信测试脚本，在Test Contents中选择请求报文；在Test Element Details的Overview
tab 中右键点击短信内容字段的值，然后在弹出菜单中选择Substitute From->Datapool
variable。

图25. 设置为从数据池获取数据
4. 选择datapool和指定列。

图26. 选择数据池和指定列
5. 选择datapool的访问模式：Sequential，Random 或Shuffled。

图27. 数据池访问模式
6. 添加完datapool后，相应行标记为绿色背景。

图28. 数据池已添加。