用 SLA 保证第二代 Web 服务应用程序

SOA 延迟和吞吐量

级别: 初级

Judith M. Myerson, 系统设计师兼工程师

2004 年 9 月 01 日

第二代 Web 服务应用程序需要服务级别协议 (service level agreements，SLA) 来保证企业所购买服务的可靠性、实用性以及质量问题。由于有些应用程序要与非 Web 服务进行交互，客户将要求更加精确衡量的 SLA。Judith M. Myerson 说明了如何为那些应用程序制定 SLA。她讨论了故障警报、延迟和吞吐量，并举例说明了在测试应用程序的时候应该问哪些问题以及如何回答这些问题。

第一代体系结构

正如在“用 SLA 保证 Web 服务”（请参阅 参考资料）中所描述的那样，下图显示了 SLA 保证的 Web 服务体系结构。它非常简单。

该体系结构和 Web 服务一起工作得很好，在这个体系结构中，服务客户（请求方）查找服务，而服务提供者发布另一个服务，然后服务被绑定到提供者。每个服务角色和另一个服务角色之间只有一个连接箭头。

这个体系结构已经不适合如今日益复杂的 Web 服务应用程序。它已经过时了，特别是在面向服务的体系结构中 (Service-Oriented Architecture，SOA)，有以下 4 个原因：

• 原因 1：第一代体系结构基本上没有考虑到 Web 服务应用程序客户为完成最初的 Web 服务应用程序任务而发现另一个 Web 服务这方面的需要。它连续完成任务的时间可短可长。客户不接收确认或验证 Web 服务发现是否成功的警报信息。
• 原因 2：该体系结构假设提供者正常发送请求来发布所有的服务，并且代理以 100％ 的准确性和可靠性发布这些服务。提供者不需要代理发送是否成功完成资源库中的服务发布的通知。
• 原因 3：它没有涉及到客户从提供者接收关于将 Web 服务集成到 Web 应用程序之后下一步该做什么这方面的需求。这个集成可能需要通信同步（如客户使用 ATM 机器取款）或者异步（如一个包括了排序项的长期运行事务暂停运行几个星期）。
• 原因 4：这个体系结构没有考虑到在 SOA 中，Web 服务应用程序将与非 Web 服务应用程序争夺用来响应查询或请求 Web 服务应用程序所需的资源。它忽略了互操作性问题的可能性，没有涉及到将非 Web 服务集成到 Web 服务应用程序的问题。

Web 服务的第二代体系结构

要改进第一代体系结构的不足，您必需将 SOA 中的提供者和客户间的流程合并为一个机制，该机制从代理和通信端触发提供者警报和客户警报。在这个过程中，您创建了第二代体系结构，使用双箭头连接一个服务角色和另一个服务角色。

我们随意地将提供者警报和客户警报分为三类：确认、验证和故障。每种类型的内容对每个事件来说都不一样。

例如，当应用程序客户成功地发现一个 Web 服务应用程序时，代理发送警报来确认或验证发现成功。如果客户没有发现服务，则代理发送另一种类型的警报，提示发现尝试失败。

一接收到成功发现的警报，客户就将其与提供者绑定。如果提供者认为服务需要另外的 Web 服务来完成初始 Web 服务应用程序的任务，它将与客户进行通信，讨论接下来要做什么。

应用程序提供者给代理发送发布服务的请求。如果代理成功地发布了资源库中的服务，它将给提供者发送警报来确认发布成功。否则，它将发送尝试发布失败的警报信息。

SOA：总体描述

Web 服务应用程序是建立在独立于平台的协议——SOAP、WSDL、UDDI 以及 HTTP 之上的。这些协议满足了 SOA 的需求，比 Web 服务存在的时间要长。SOA 要求服务是可以被发现的，并且有可供调用的接口来实现业务流程。

在 Web 服务以前，SOA 中不存在 Web 服务应用程序。现在，Web 服务应用程序是 SOA 中的主要部分。它们补充了由非 Web 服务应用程序或组件组成的企业应用程序集成 (EAI) 应用程序。Web 服务应用程序与非 Web 服务应用程序竞争，争夺他们响应发现查询、发布请求以及绑定请求所必需的资源。

SOA 主要是利用 Web 服务标准来支持跨企业的互操作性问题，前提是 SOAP、WSDL 和其它的互操作性问题已经在 SLA 保证的 Web 服务应用程序投入到生产环境之前得到解决。这包括将 SLA 作为 UDDI 或其它的公开注册中心里的公用服务的 SLA Web 服务。这些 Web 服务必需要涉及到由于争夺资源对响应时间的性能影响而带来的权利和补偿（技术上的和金钱上的）。

与 Web 服务应用程序的体系结构的逻辑类似，SOA 服务客户为服务查询目录服务。如果客户找到了服务，目录服务通过代理让服务提供者调用该服务。反过来，如果客户没有找到服务，它可能会从目录服务收到一个警报，提示搜索失败。同样的，如果提供者不能在目录中发布服务，它也可能会收到一个警报，提示尝试失败。

发送故障警报

由于所有的 SLA 都包含提供者从各种故障事件中恢复所必须经历的阶段，因此，通信和警报信息必须包括每个服务角色为响应各种故障事件需要花费多少时间（致命错误除外），以及从警告故障中自动恢复又需要多少时间等这些方面的信息。

提供者必须要能控制住故障事件。当服务保障在某一级别出现问题（例如，在正常运行时间里实用性低于 99.9%），提供者需要确定将要避免的故障类型和权利以及补偿，补偿是必需的。如果故障事件超出提供者的控制范围，开发人员以及提供者应该将它作为 SLA 中的例外情况，例如，硬件故障、远程通信故障、软件错误和缺陷，甚至监视和测量系统故障。

由于解释一些故障可能比较繁琐，协助提供者为每个消息或易发生的潜在故障指派代码是一个好办法，无论是按数字顺序排列（最好采用十六进制）还是按字母顺序排列，或者是两者都用。当分配权重以估算响应时间时，您应该将代码随意分成三种不同的类别：警告、严重警告和致命错误。如果业务操作经常中断，由于对于重复性问题的解决方案不如人意，客户可能需要有行使权利的特权，执行 SLA 退出子句。

估算响应时间

一个最好的估算响应时间的办法是提问并回答。编译完问题后，您可以在延迟、吞吐量和故障转移的基础上对其进行优化。

延迟是数据包从一个地点到另一个地点然后返回这一个来回所花费的时间。例如包括：

• 在数据库服务器端的 SQL 延迟
• 从网络 A 路由器到网络 B 应用程序服务器的延迟
• 动态警报和绑定的延迟
• 动态应用程序集成的延迟

吞吐量是代理在给定的时间内能处理的请求的数量。故障转移测试衡量 Web 服务应用程序的故障转移解决方案是如何正常运行的。开发人员必需权衡考虑延迟和吞吐量。另一个需要考虑的衡量元素是应用程序如何为死锁、挂起以及超时提供纠正措施。

提问

下面是当您试图通过修改 Web 服务应用程序或开发新的应用程序来提高他们的性能时，可能会提出的一些问题：

• Web 服务应用程序是不是需要花费很长时间（例如，超过 10 秒）来响应客户的查询？当 Web 服务不适于发布或调用时，还能给终端用户发送警报信息吗？
• Web 服务客户为响应通信需要花费很长时间，这是由于提供者引起的吗？如果代理没有发现服务，它是不是需要花费很长时间来启动警报？
• Web 服务代理是不是需要花费很长时间来响应用于发布服务的请求？在服务被发布或发现之后，还需要验证或确认请求吗？
• 在 SOA 中，Web 服务应用程序会与非 Web 服务应用程序争夺为处理大量的客户或提供者的查询请求所需的资源吗？
• Web 服务应用程序中网络传输的增加是由于高速缓存机制不够引起的吗？

要回答这些问题，估算响应时间的标准应该精确一些。否则，各方就 SLA 是在衡量不同网络场景中的哪个服务或性能，以及用的是 SOA 中的哪个服务级别将不能达成一致意见。

考虑客户的意见

有些情况下，客户可能认为一个双方同意的服务级别将估算三个网络，在给定的时间内，每个网络都分布着不同的 Web 服务应用程序和非 Web 服务应用程序，如下所示：

表 1.场景 1

Web 服务应用程序 非 Web 服务应用程序 Web 服务应用程序对非 Web 服务的调用 A 90% 0% B 100% 0% C 70% 30%

另一些情况下，客户可能认为一个双方同意的服务级别将用相同的分布来衡量相同的网络，但是要从响应时间估算中排除所有三个网络中运行的非 Web 服务应用程序，如下所示：

表 2.场景 2

Web 服务应用程序 非 Web 服务应用程序 Web 服务应用程序对非 Web 服务的调用 A 90% 0% B 85% 0% C 75% 0%

为完成一连串的任务，一些 Web 服务应用程序对非 Web 服务应用程序的调用增加了问题的复杂性，但是，客户可能认为这些非 Web 应用程序不在估算范围之内。如图 3 所示，并不是所有的 Web 服务应用程序都要依赖于非 Web 服务应用程序。

表 3.场景 3

网络 Web 服务应用程序 非 Web 服务应用程序 Web 服务应用程序对非 Web 服务的调用 A 90% 10% 7% B 100% 0% 0% C 70% 30% 10%

测试和监视 SLA

Web 服务测试工具——比如那些由 PushtoTest 提供的——（参阅下面的 参考资料部分以获得相关链接）并不是充当 SLA 监视器的唯一机制。您可以设置异常条件来监视和检查 Web 服务的延迟、吞吐量以及高速缓存机制。这些条件必须作为经同意的 SLA 的一部分而被列出。

结束语

到目前为止，我已经解释了 SLA 保证的第二代 Web 服务应用程序的更高级技术参数。如果您打算为您的付费客户提供与非 Web 服务交互的 Web 服务应用程序，他们可能想要一个 SLA 来确保获得他们期望的投资回报。

我还给出了问题实例，您可以以其中的一些问题为基础来满足客户对衡量延迟和吞吐量的期望。充分做好准备回答这些问题能对提高客户对 SOA 中的双方同意的服务级别的满意程度起到一定的帮助作用。

另外，客户和提供者必须就协议条款重新谈判（包括权利、补偿和例外情况）以确定满足客户的服务级别，作为对 EAI 应用程序的补充。对于开发人员来说，在集成 Web 服务应用程序与非 Web 服务并执行他们的过程中记住这一点很重要。开发人员必须同时考虑客户对在 SOA 中集成结果的运行情况的业务期望和技术期望。

参考资料

• 请了解更多关于 PushtoTest的知识来测试和监控 Web 服务。
  
  
• 请阅读 Judith Myerson 的 中间件完全手册 ，它主要讨论系统设计的基本原则和优先考虑的问题，并强调了电子商务和分布式集成系统的增长带来的新需求。
  
  
• 通过阅读 企业系统集成，第二版 ，深入了解企业以及关于如何确保成功的系统集成方面的技术。
  
  
• 在 IBM‘s UDDI version 2 registry发布您的 Web 服务或应用程序，这个注册中心的特征是有图形用户接口和一致的 API 供大家公用。
  
  
• 请阅读 “用 SLA 保证 Web 服务”，该文章涵盖了 SLA 保证的 Web 服务第一代体系结构的测试机制和例外情况（ developerWorks，2002 年 4 月）。
  
  
• 从现有的 Java 代码构建基于 SOAP 的 Web 服务时，请研究和学习更多有关 “基于 SOAP 的 Web 服务中的复杂数据类型”的知识（ developerWorks，2001 年 5 月）。
  
  
• 从 IBM Redbook for Domino administrators中深入了解制定服务级别协议的具体细节。
  
  
• 快速启动 Web 服务，学习 Web 服务知识、工具和技巧，那里提供最新的基于 Java 的软件开发工具和来自 IBM 的中间件（测试版），还有在线教程、文章以及在线技术论坛。
  
  
• 访问 Developer Bookstore，那里有比较全面的技术书籍，包括许多 Web 服务主题的书籍。
  
  
• 想要更多的相关信息？developerWorks 的 SOA 和 Web 服务专区有大量关于如何开发 Web 服务应用程序的资料文章和初级、中级以及高级教程。
  

关于作者

Judith M. Myerson 是一位系统设计师兼工程师。她感兴趣的领域包括中间件技术、企业级系统、数据库技术、应用程序开发、网络管理、安全性方面以及项目管理。您可以通过 jmyerson@bellatlantic.net与她联系。