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 小时）（稳定性测试）
对于以上测试场景，涉及到的问题或需要测试工具具备的功能可能有：soa
∙ 高负载生成
∙ 测试数据的实时监控
∙ 动态报文
∙ 分布式负载
∙ 自定义图表
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 均是以上两个组件的集合。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。