【IT168 技术文章】

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

    比如，最早提出用SOA实现ebXML的GeneralMotorsCorp.，其最初的设计使用的是UniversalBusinessLanguage(UBL)，建立的XML消息有150,000字节到10兆字节甚至更大。2004年，我的性能测试公司PushToTest认为当时的Java?应用程序服务器没有提供足够的吞吐量，在GMWebServicesPerformanceBenchmark研究中提出了可伸缩性和性能问题。
   
    当时基于XML的Web服务技术还非常新，我认为新一代应用程序服务器技术会解决性能问题。但大部分问题仍然存在。
   
    Web服务吞吐量问题和复杂的XML
    
    2005年，PushToTest完成了一项新的SOA性能研究（请参阅参考资料）表明，在处理复杂的XML消息时，使用当前Java应用程序服务器构建的应用程序其性能很差，不足以投入生产。是发现的问题和以前研究中的问题相同：
   
    ·简单对象访问协议（SOAP）绑定（代理）低效而缓慢。
   
    ·每次请求都需要一组全新的资源（对象、CPU和网络带宽）来处理响应。没有缓冲模式。
   
    ·使用关系数据库技术存储XML数据非常慢而且没有可伸缩性。
   
    为了了解这三个问题，设想一下软件开发人员如何使用J2EE应用程序服务器工具构建和部署XML服务。

图1.WSDL定义的例子

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

图2.Java方法调用

    图2说明了Web服务消费者如何向服务发出SOAP请求。SOAP绑定对SOAP消息体中的XML内容进行反序列化。这个过程需要进行大量的处理，非常复杂，因为消息体常常包含复杂的数据类型。比如，消费者可能向服务发送包含多个值的散列表。SOAP绑定需要解码散列表的内容，对每个值创建Java对象的实例。散列表还可能包含其他散列表，因此解码SOAP消息内容不是一件容易的事。如果不相信的话，请看一看ApacheAxis反序列化器的源代码。
   
    SOAP绑定实例化包含SOAP消息体内容的JavaRequest对象。SOAP绑定调用目标类中的目标方法，并将Request对象作为参数传递。目标EJB或Java对象提供所有必要的处理来建立对请求的响应。SOAP绑定将EJB或Java对象返回的值序列化到SOAP响应消息中。SOAP绑定将响应对象中的值解码成能够序列化到SOAP响应消息中的值需要经过同样复杂的过程。
   
    通过研究用流行的Java应用程序服务器工具创建的SOAP绑定，我发现了以下问题：
   
    ·应用程序服务器工具创建的SOAP绑定效率很低。比如，我发现某些SOAP绑定创建SOAP请求的多个副本，每个请求都实例化为String对象——这样做并没有明显的理由。一些SOAP绑定创建了15,000个Java对象来反序列化消息体中包含500个元素的SOAP请求。
   
    ·在配备有双CPU3.0GHzIntelXeon处理器的服务器上，我发现在处理有效负荷10,000字节、包含50个元素的简单SOAP消息时，每秒处理的事务为15到20个（TPS）。随着SOAP消息复杂性和大小的增加，我发现会造成明显的伸缩性和性能问题。有效负荷100,000字节、包含750个元素的SOAP消息会把吞吐量降低到1.5TPS。SOAP消息体中元素个数越多，每个元素嵌套越深，问题就会越严重。
   
    性能问题在SOA设计中会引起连锁反应。SOA是一种组件软件重用技术。一个服务通常调用其他服务来确定对消费者请求的响应，从而形成一个调用链。

图3.消费者

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