用 SLA 保证 Web 服务
介绍、体系架构和测试机制
级别： 初级
Judith M. Myerson 系统设计师和工程师
2002 年 4 月 01 日
许多企业正要求服务品质协议（SLA），SLA 可以保证企业为之付费的 IT 服务的可靠性。随着 Web 服务成为主流，客户将要求保证服务质量的 SLA。在本文中，Judith M. Myerson 说明了如何建立保证 Web 服务的服务品质协议（SLA）。她讨论了 SLA 中应该考虑进的例外情况，并给出了把 Web 服务作为由 SLA 保证的、公开的 Web 服务投入到生产环境之前应该测试其 SOAP 互操作性的示例。
服务品质协议（service-level agreement）（SLA）是服务提供者和客户之间的一个正式合同，用来保证可计量的网络性能达到所定义的品质。SLA 为服务提供者提供了一种在当今多变而又竞争激烈的市场中胜过对手的方法。服务提供者可能是一个国内的 IT 组织、一个应用程序服务提供者（ASP）、一个网络服务提供者（NSP）、一个因特网服务提供者（ISP）、一个受管服务提供者（MSP）或者任何其它类型的服务提供者。
SLA 可以非常笼统或者极度详细，它一般都包含出现故障时服务提供者和客户应采取的步骤。服务提供者保证它提供的服务在一定百分比的时间内（例如，99.9%）是可用的。提供者还能够强制向客户通知 SLA 当机时间的最长和平均响应时间，或者在网络接口发生改变之前的最长和平均响应时间，并利用基于因特网的工作流自动化、分发和报告技术。如果经过指定的一段时期后提供者无法达到所定义的性能品质，客户就可以获得一些权利和赔偿。各个 SLA 的权利、赔偿和例外情况是不同的。客户还同意接受协议一般条款的指定例外情况。
在每个 SLA 中都必须精确定义服务品质；否则各方关于 SLA 将以哪种品质衡量什么服务或性能标准将无法达成一致。例如，一个客户可能认为一个双方同意的服务品质将衡量网络 A、网络 B 和网络 C，同时后两者连接到第一个，而服务提供者却认为它只衡量网络 A。还有一点很重要的是正常运行时间可用性百分比的小数位数：例如，一年中的当机小时数和当机天数比，99.999% 的正常运行时间所允许的当机时间比 99.9% 的正常运行时间所允许的当机时间还少。SLA 应该为客户包含进一个退出条款；当因为不能圆满解决经常发生的可用性、可靠性和安全性问题而使客户的业务运转频繁中断时，客户希望他有终止协议的权利。
SLA 已经出现了一段时间了。在二十世纪六十年代，它们是用于达到已定义的服务品质和响应服务问题的一般操作程序，而这些服务问题是用户组织在购买或租用大型机上的机器时间时就已经同意过的。 超大型计算机（big iron）是缺省的企业系统，其它任何技术的处理能力都无法与它相比。
当客户机／服务器和网络桌面系统进入计算机世界时，人们就构思出了分布式网络系统这个概念。这些系统后来发展成了跨网络运行企业资源规划（ERP），供应链管理（SCM）和客户关系管理（CRM）系统的企业范围的系统。
在这个发展过程中，企业对因特网的依赖已经使得公司的应用程序套件的网络延迟影响越来越明显。同时，用户（也就是客户）已经委托一定品质的服务质量保证相关的可用性、可靠性和响应时间以确保业务运转不被中断，并且依赖外部服务提供者来提供应用程序、因特网、网络，受管服务和其它服务。结果，SLA 变得更复杂，范围更广，一个用户可以有与不同提供者签定的几个 SLA。反过来，提供者自己的 SLA 也可以是与其它提供者签定的，每个 SLA 都有一套不同的需求、衡量标准和例外情况。
因特网（和企业内部网）的新方向提供了将来自不同来源（通过 Web 服务）的全异系统聚合并集成在一起的新方法和机会。随着不断扩展的分布式网络系统中提供者之间的关系变得更加复杂，Web 服务已经使 SLA 变得更富有挑战性。我们看到这些 SLA 不仅仅保证网络性能和正常运行时间可用性；由于每个 Web 服务都有不同的特征和网络需求，它们还被用来保证应用程序的性能。目前，一些 SLA 可以或者早已经作为公共 Web 服务公开了。
所有的 Web 服务都提供在 Web 上集成和修改系统组件的灵活性，以允许用户更改需求和在一定网络流量条件下处理网络资源争用。然而，这种灵活性要受到简单对象访问协议（Simple Object Access Protocol，SOAP）和统一描述、发现和集成（Universal Description and Discovery Integration，UDDI）互操作性问题的限制，因为一些主要厂商对这些协议的标准规范的解释是不同的。这意味着在把 Web 服务投入到生产环境和在 UDDI 或另一个公共注册中心将其作为公共服务发布之前，必须解决互操作性问题。对于 SLA 保证的 Web 服务（我们有时候称其为 SLA Web 服务）也是如此，不管该服务是独立的还是作为一套 Web 服务的一部分。后者的一个很好的示例是一个单独的 SLA，它适用于 Web 基础架构的每一段，从因特网到 Web 服务应用程序。
在进行进一步讨论之前，让我们来看一下 SLA 保证的 Web 服务的体系架构。这个体系架构，如下 图 1所示，需要三个服务角色：一个 服务提供者、一个 服务客户和一个 服务代理。通过在适当的平台上创建一个 Web 服务并生成 WSDL 文档和服务的基本 SLA ，服务提供者发布一个由 SLA 保证的 Web 服务。下一步，它把服务细节发送到服务代理以存储在资源库中。服务客户向代理注册，然后在代理的资源库中搜索并发现适当的 Web 服务，检索服务的 WSDL 和 SLA。然后它再与提供者协商把 SLA 正规化、确定下来并绑定到它的 Web 服务。
必须监视任何符合 HTTP、HTTPS、SOAP、UDDI 和 Web 服务描述语言（Web Service Description Language，WSDL）的由 SLA 保证的 Web 服务的可伸缩性和性能。在把 SLA 保证的 Web 服务投入到生产环境之前，必须解决所有的 SOAP、WSDL 和其它的互操作性问题。如果服务无法满足一定的标准，按照 SLA 的条款，提供服务的提供者可能要付财政责任，所以确保所有这些问题都在控制范围内特别重要。
在建立 SLA 保证的 Web 服务之前，应该使用测试机制 ― 比如来自 PushtoTest 的工具和脚本 ―（请参阅下面的 参考资料部分获得链接）来测试该 Web 服务的各种协议和组件。在启动服务后，这些测试工具可以充当 SLA 监视器。
表 1是一个核对表示例，当开发者测试一个将被 SLA 保证的服务时，他应该考虑这个表。
| 测试类型 | 问题 |
| 有状态 | 当您使用 SOAP 设置服务器值时，服务器在并发的状态下是否正确响应？ |
| 访问 | 一个未经授权的用户能成功访问只有经过授权的管理员才能使用的控制权吗？ |
| 响应时间 | Web 服务响应时是不是花费的时间太长（例如，超过了 10 秒）？ |
| 超时 | 当 Web 服务超时时会发生什么事情？ |
| 版本 | 新的构造会破坏现有 Web 服务的功能吗？ |
象任何协议或保险单一样，SLA 通常会指定其条款中的例外情况。Web 服务的 SLA 应该包含关于例外情况的详细信息。我将随意将它们分为四类：故障、不受服务提供者直接控制的网络问题、拒绝服务和预订的维护。 表 2说明了可以归入这些类别的某些特定情况。
只要客户公司可以得到当机期间的适当赔偿，还可以添加其它一些例外情况来适应提供者的情况。通过在 SLA 中包含进例外情况，提供者可以在出现问题或网络损耗时免负责任。另一方面，如果竞争的服务提供带有极少例外情况的 SLA，客户可以选择那些在业务运转中提供更长正常运行时间并且有更好的服务保障的协议。即使 99.5%、99.9% 和 99.999% 这几个正常运行时间可用性保证之间的差别也可以影响选择 SLA 的决策者。
| 类型 | 示例 |
| 故障 | 硬件故障（请注意，错误的硬件极少） 远程通信故障（例如，提供者无意切断了光缆线） 软件错误／缺陷 监视／测量系统故障 |
| 不受服务提供者直接控制的网络问题 | 主干对等端问题（例如，UUnet 在加利福尼亚的一个路由器坏了，拒绝因特网服务进入整个西海岸） DNS 不受服务提供者的直接控制 |
| 拒绝服务 | 客户疏忽／明知故犯 网络流量过大、黑客攻击和一般攻击 不可抗力、战争、罢工、电讯不可用、无法得到提供 SLA 所需的供给或设备。 |
| 预订的维护 | 硬件升级 软件升级 备份 |
虽然 SLA 的重点是最大上载可用性和带宽的保证，但 SLA 无法为那些对延迟敏感的 Web 服务应用程序保证一致的响应时间。延迟是数据包从一个地点到另一个地点然后返回这一个来回所花费的时间（通常以毫秒计）。当数据包完成它的旅途花费的时间太长时就会发生延迟问题。例如，当 Web 服务产生的音频开始断断续续或者鼠标指针开始微微颤抖的时候，您就会注意到这些问题。
SLA 应该指定给定时间周期（假设一个月）内的平均来回延迟和数据报丢失。它应该把平均来回延迟定义为它在网络和其目的地之间的平均来回包传送，并把包丢失定义为在数据传送的来回时间内丢失包占总包数的百分比。协议应该把这种丢失限制到一定程度 ― 假设 1% 或更少 ― 如果在同意的时间段内这种丢失超过了这个程度还应该指定赔偿，包括偿还或退款。
目前为止，我已经说明了 SLA 保证的 Web 服务的技术参数。如果您计划为您的付费客户提供 Web 服务，他们通常都想要一个 SLA 以确保获得他们期望的投资回报。本文中讨论的主题应该会让您在准备自己的 Web 服务以满足 SLA 的需求方面处于领先地位。
本文并没有讨论可用于估量客户期望的各种工具；在真实的商界，您可以发现即便您的服务满足同意的服务品质，您的客户仍可能对服务不满意，因为技术上的服务交付能力还没有达到企业的期望。在这些情况下，客户和提供者必须就协议条款重新谈判以确定满足客户的服务品质。对于开发者，在创建和实现 Web 服务时记住这一点很重要。开发者必须既考虑客户的业务期望又考虑技术期望。
- 您可以参阅本文在 developerWorks 全球站点上的 英文原文.
- 请了解更多关于 PushToTest的知识来测试和监控 Web 服务。
- 请阅读 The Complete Book of Middleware， 它主要讨论系统设计的重要原则和优先考虑的问题，并强调电子商务和分布式集成系统的增长带来的新需求。
- 请阅读 Enterprise Systems Integration, Second Edition， 它向您提供企业内部机制和技术诀窍并确保成功地集成系统。
- 请阅读 Anbazhagan Mani 和 Arun Nagarajan 所著的“ 理解Web服务的服务质量”（developerWorks，2002 年 1 月）来改善您的 Web 服务的性能。
- 这本面向 Domino 管理员的 IBM Redbook描述了制定一个服务品质协议的具体细节。
- 一旦 Web 服务就绪，您就可以在 IBM 的 UDDI 版本 2 注册中心中发布它，这个注册中心的特征是有图形用户界面和一致的 API 供大家公用。
 |
||
|
|
|
Judith M. Myerson 是一位系统设计师和工程师。她对中间件技术、企业范围的系统、数据库技术、应用程序开发、网络管理、分布式系统、基于组件的技术和项目管理都很感兴趣。您可以通过 mailto:[email protected][email protected]与她联系。 |