改善SOA应用程序性能

根据摩尔定律，自从晶体管在1958年发明以来，处理速度和容量一直是大约每两年提高一倍。因此，我们制作更大和更复杂的软件系统的时候也要跟上这种容量增长的速度以满足这些系统的需求。

我们如何领先于这种趋势？考虑到内存和存储在企业计算领域一直在增长，软件需要跟上这种增长速度。我们要使用正确的方法从一开始就设计软件具有灵活的伸缩性和可预见的延迟。数据文件和信息传输的尺寸日益增大要求进行更多的处理。在许多情况下，在进行处理之前还需要使用多个输入的信息来源才能进行数据处理。

制作电信电话设置和计费、在线游戏、证券交易、风险管理和在线订购旅游等XTP（极限事务处理）式的应用程序的那些人也了解这种难题。在许多行业都能够使用的更广泛的应用案例是Web应用程序。这种应用程序能够升级要满足互联网的通讯量，也能适应从来不处理那种通讯的后台系统。

边界成本

在与客户讨论有关用可预见的延迟升级一个SOA应用的时候，经常会遇到“边界成本”这个词汇。在一个应用环境中解释一下这个词汇。考虑一下这个情况，一个XML文件也许是来自内部应用程序、外部业务合作伙伴或者是从一个EDI文件转换过来的，需要由许多服务进行处理，这些服务是由一个BPEL（业务处理执行语言）流程协调的或者由一个企业服务总线流程管道协调。通用的方法是把XML文件放在总线上，让总线根据这个流程的定义调用这个服务，把这个XML文件作为这个服务请求载荷的一部分传送。需要处理那个数据的每一个服务都要相应地访问这个XML文件。也许还会出现与数据库的交流。这种方法听起来是很简单的，见图1

图1：使用BPEL流程或者服务总线管道调用服务

然而，在实践上，使用这种方法会有一些伸缩性方面的挑战。从一个服务到另一个服务的跨边界成本是什么？在调用一个简单的业务流程的情况下会产生多少次这种成本？如果这个XML文件容量有数MB大，或者有数千个这种文件，怎么办？或者这两种情况同时出现怎么办？

使这种挑战更困难的是这个现实：大多数IT环境都是许多平台和技术的混合体。不管你的处理引擎或者服务总线是多么充分，在服务端点进行处理都是一个瓶颈。最近，一个客户网站发表的谈话披露了一个一般需要15秒钟的15个步骤的业务流程。但是，在工作量的最高峰时，这个流程违反了30秒钟的服务级协议。开发人员用了两年的时间优化和微调这15个服务中的每一个服务的性能，发现的端对端的延迟的其它原因是服务之间的边界成本。详细的检查发现，在开源web服务工具集中分析和配置XML工作负荷的过程中，这15个服务中的每一个服务的调用都需要1至2秒的时间。

图2：图2是传统的SOA数据负载模型，显示把XML从一个服务转送到另一个服务的过程。显示每一个服务调用的XML至对象（Object）和关系（Relational）与其相反顺序之间的服务请求边界成本。

什么是应用程序网格？

应用程序网格是内存存储引擎中显示应用程序状态数据的一个平行的可伸缩的代理。它有效地提供一个分布式共享的内存池，能够线性地伸缩以适应不同种类的机器网格。这些机器包括高端硬件和低成本的商品硬件。在一个应用程序中使用应用程序网格可同时向内存中的数据提供新能、伸缩性和可靠性。

应用程序使用一个应用程序网格的一个方法是使用类似于Java Hashmap、.NET目录或者JPA接口等API级别的接口。一种替代的方法是使用SOA环境中的一个服务级接口。

如图3所示，应用程序网格接受一个把数据放到地图中的请求，并且通过一个高效率的网络协议传送到拥有主要实例数据的网格节点P。然后，这个主要节点把这些副本转变为更新的值传送到第二个节点B进行备份。接下来向这个服务返回控制。

图3：应用程序网络集群保证不同机器上的主要/备份的内存中的数据。