专家答疑：改善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秒的时间。