很多软件架构师在面向服务体系结构（SOA）设计中使用 XML，虽然没有一种 SOA 标准要求在 SOA 中使用 XML 或者提供相关指南。因此，软件开发社区做了很多实验和调查来发现定义服务端点和消息定义（模式）的最佳方式。这些方法大多数都会带来了糟糕的性能和可伸缩性。

比如，最早提出用 SOA 实现 ebXML 的 General Motors Corp.，其最初的设计使用的是 Universal Business Language (UBL)，建立的 XML 消息有 150,000 字节到 10 兆字节甚至更大。2004 年，我的性能测试公司 PushToTest 认为当时的 Java™ 应用程序服务器没有提供足够的吞吐量，在 GM Web Services Performance Benchmark 研究中提出了可伸缩性和性能问题。

当时基于 XML 的 Web 服务技术还非常新，我认为新一代应用程序服务器技术会解决性能问题。但大部分问题仍然存在。

Web 服务吞吐量问题和复杂的 XML

2005 年，PushToTest 完成了一项新的 SOA 性能研究（请参阅参考资料）表明，在处理复杂的 XML 消息时，使用当前 Java 应用程序服务器构建的应用程序其性能很差，不足以投入生产。是发现的问题和以前研究中的问题相同：

• 简单对象访问协议（SOAP）绑定（代理）低效而缓慢。
• 每次请求都需要一组全新的资源（对象、CPU 和网络带宽）来处理响应。没有缓冲模式。
• 使用关系数据库技术存储 XML 数据非常慢而且没有可伸缩性。

虽然可以使用使用不同技术建立基于 XML 的 Web 服务，但我发现多数开发人员更愿意从服务的 Web Services Description Language (WSDL) 定义开始。Java 应用程序服务器提供了输入 WSDL定义和生成代理类的工具。代理器接收 SOAP 请求并把请求转发给 Java 对象或 Enterprise Java Bean (EJB) 进行处理。SOAP 绑定（代理器）是一种 Java 类，可通过 servlet 接口调用它。

图 2 说明了 Web 服务消费者如何向服务发出 SOAP 请求。SOAP 绑定对 SOAP 消息体中的 XML 内容进行反序列化。这个过程需要进行大量的处理，非常复杂，因为消息体常常包含复杂的数据类型。比如，消费者可能向服务发送包含多个值的散列表。SOAP 绑定需要解码散列表的内容，对每个值创建 Java 对象的实例。散列表还可能包含其他散列表，因此解码 SOAP 消息内容不是一件容易的事。如果不相信的话，请看一看 Apache Axis 反序列化器的源代码。

SOAP 绑定实例化包含 SOAP 消息体内容的 Java Request 对象。SOAP 绑定调用目标类中的目标方法，并将 Request 对象作为参数传递。目标 EJB 或 Java 对象提供所有必要的处理来建立对请求的响应。SOAP 绑定将 EJB 或 Java 对象返回的值序列化到 SOAP 响应消息中。SOAP 绑定将响应对象中的值解码成能够序列化到 SOAP 响应消息中的值需要经过同样复杂的过程。

通过研究用流行的 Java 应用程序服务器工具创建的 SOAP 绑定，我发现了以下问题：

• 应用程序服务器工具创建的 SOAP 绑定效率很低。比如，我发现某些 SOAP 绑定创建 SOAP 请求的多个副本，每个请求都实例化为 String 对象 —— 这样做并没有明显的理由。一些 SOAP 绑定创建了 15,000 个 Java 对象来反序列化消息体中包含 500 个元素的 SOAP 请求。
• 在配备有双 CPU 3.0 GHz Intel Xeon 处理器的服务器上，我发现在处理有效负荷 10,000 字节、包含 50 个元素的简单 SOAP 消息时，每秒处理的事务为 15 到 20 个（TPS）。随着 SOAP 消息复杂性和大小的增加，我发现会造成明显的伸缩性和性能问题。有效负荷 100,000 字节、包含 750 个元素的 SOAP 消息会把吞吐量降低到 1.5 TPS。SOAP 消息体中元素个数越多，每个元素嵌套越深，问题就会越严重。

性能问题在 SOA 设计中会引起连锁反应。SOA 是一种组件软件重用技术。一个服务通常调用其他服务来确定对消费者请求的响应，从而形成一个调用链。

不仅仅是一个服务的性能问题，每个服务在序列化、反序列化请求和响应的时候都会增加同样的开销。随着服务调用层次的增加，性能问题也成倍增加。

1 2 3 下一页>>