事实上，在面对大量的使用者时，如何在保证高性能的同时，对服务进行抽象处理，是迫在眉捷的一个问题。如果对服务的抽象度不足，暴露了过多的细节，那么快速的组装系统，满足客户业务需求，提高系统的质量，都好比椽木求鱼，将成为一句空话。
服务抽象下的性能
解决SOA的性能问题，可以归结于两点：
力 求一个服务构件内部的原子服务的性能尽可能的高；所谓的原子服务是对现有的系统进行抽象，然后通过服务构件以接口的形式来开放各种服务，所以提高这些原子 服务的性能是提高服务构件性能的必要条件。可能正如许多人期望的一样，提高原子服务的性能还是可以采用已往那些行之有效的性能提升技术 （performance quality assurance，以下简称PQA），如集群，虚拟技术，负载测试。因此今天的架构师要学会如何从底层开始规划整个系统的架构，比如说，提供足够的数据 库处理能力，如何在集群中平衡负载等。
此外，传统的那些性能提升技术对原子服务仍然有效。对服务接口的负载模拟测试与以往对Web页面的性能测试非常相似的。那些为Web Service提供性能测试的软件供应商们有预见的将自己的产品建立在We页面的PQA工具上，这样可以通过Web接口以传统的Web页面测试方式来测试 性能。虽然Web Service与Web页面的共性颇多，但还是存在着本质上的不同。象Web页面是通过发送请求，接收回复进行交互，而Web Service的交互方式则是多元化，包括异步，同步，事件驱动，发布/订阅等。那么对这样一个支持多种交互方式的服务，进行负载测试，就需要更多的先进 技术，已非那些以Web页面为中心的传统性能测试工具所能完成。
性能优于服务抽象的考虑
SOA系统性能严重依赖于所使用的服务，将一堆服务打包在一起并不能构建一个结构良好的SOA系 统。我们将一个面向服务的业务系统称为SOBA（Service-Oriented Business Applications），架构师们在设计这些系统时，必须考虑这些服务所消耗的资源，包括那些可能根据业务需要而动态提供的服务。不幸的是，从本质上 来讲，SOBA就是灵活多变的，因此在性能方面，潜在性的为架构师，实施人员们提出了更加复杂的挑战。
接下来谈到的内容与性能相关，是构建SOBA时，所要关注的，可供架构师参考。
要仔细考虑可用与重用，在两者之间取得一个平衡点--一些服务希望具有高可用性，可以处理大量数据，而另外一些则希望可被更多的系统重用。通常情况下，在 一个SOBA系统中，高可用性总是很容易被分析出来，而高重用性则相对难一些，但对于架构师而言，两者之间不可偏颇，需取法其中。
庞大的消息传输和粒度
有些服务在进行交互时会传递大量的消息（Very Large Messages，简称VLMs）。VLMs的性能问题可能是因为不同的底层结构或者是不同的服务交互而引起的。有些时候，VLMs往往是与服务的粒度密切相关，也有可能是与SOAP附加的信息，或者加密，这些特性都会加大数据量。但不管在什么情况下，架构师必须考虑消息传递的数据量对SOA系统性能的影响。
动态性能策略--通常情况下，对于每个服务都有一定的性能基准，以便为其它服务所使用，但是还需要一些性能的策略，在必要的时候，可以对那些可控的服务进行性能调整。事实上，能对性能进行调整是一个业务上的需要，因此架构师也应当将其列入考虑因素。
服务依赖
服务这个协奏曲形式并不单一，它有流动的曲调，多变的舞姿，诸如此类，由多种元素组合而成。通过将一个服务的输出，作为下一个服务的输入，从而将多个服务 首尾相连串，因此正如水桶原理揭示的那样，如果这个服务链上的某一个服务环节很慢，那么整个服务也会很慢。如果有多个瓶径，其带来的后果，不是简单的加 法，而是会产生放大作用的乘法，因此架构师必须对此多加考虑。（想像一下，5000辆车的拥挤和1000辆车的拥挤不是一个简单的加法）
跟踪SOA的性能问题
着手解决系统性能瓶径，尤如海边逐浪，往往是一波未平，一波又起。但是更坏的消息，却是：基于SOA的系统可能会有更多的性能瓶径。因此，在一开始进行架构设计的时候就必须多管齐下，在抽象服务层的上下两层（译注：即服务的依赖层和引用层）加以精心考量。换而言之，在系统设计之初，可以详细参考下文给出的一些技巧和经验，以便设计优良的架构。
服务和结构的虚拟化
现在各种虚拟化可以提供多种低成本的方案来处理各种性能问题，比如说将结构中的一部分剥离出去。对于那些突如其来的需求变化，更是有效，但异构的虚拟化资源也可能限制这种方案的有效范围。
正确的进行松耦合，并有策略的进行紧耦合。如果简单的去看SOA技 术，可能松耦合会优于紧耦合，但松耦合总是会带来的一定的代价，而紧耦合却可以调整这些瓶径。架构师所面临的挑战就是那些业务需求在不同情况下所应采用的 耦合度，再根据相应的需要进行设计。比如说在抽象的服务层背后，可以在底层采用可编译代码的方式来处理各种事务，还可以进行分布处理以提高并发性能。
基于注册机制的动态路由--有一种面向服务的负载平衡方案，它基于服务注册机制，在不同的服务实例间进行负载分配，从而满足服务需要。这样动态路由的方案，对于系统的可伸缩性以及容错性，都不如那种紧耦合的集群，但是可以良好的应用于异构系统环境。
在SOA系统的内部，必须关注性能。--不要在出了性能问题以后才想起使用注册管理功能，事实上，解决SOA性能最有效，也最简单的方法就是将SOA的 性能作为内容框架的一个组成部分。由于受到技术上的限制，还需要一些技巧来保证能够为用户提供服务。比如说，如果架构师小组可以将SOBA支持的类型与不 支持的类型正确的分辩出来，然后这个小组能够制订有针对性的策略来正确的限制SOBA的创建，从而可以对整个的性能限制给出预测。
（这段作者写的有些乱，也有些涩，翻译的不好，对不起；事实上我对这段文字也不是很明白）
PQA贯穿整个服务的生命周期。--对于传统的PQA而言，通常用于在系统正式上线以前，来模仿真实的环境，这可不会对已经上线的系统带来麻烦。毕竟在大 量负载的情况下，可以将一个系统置于崩溃，所以没有人会希望未经测试就直接上线。但是这种方法难于应用于SOBA系统，因为每个SOBA都会使用大量的第 三方服务。因此为SOA设 计的PQA必须能够提供更加可靠的方式来测试，而不是不停的为骆驼的背上加上稻草，直到骆驼到地为止（译注：因为一个SOBA系统所使用到的服务很可能是 由其它已经正式运行的系统提供的，如果进行传统的压力测试，可能会导致那些正式运行的系统崩溃）。事实上，这些PQA要依赖于配置，以确认某个服务是处于 正常运行还是测试模式，同时可以要求SOA管理程序提供更高的性能，并采取一些预防手段，以免系统服务被置于崩溃的边缘。
ZapThink认为（译注：ZapThink是一家咨询公司）
在分析了SOA的性能问题，我们认为SOA还需要继续发展，但并不需要革命性的变化。架构师必须学会使用每一个性能计划和性能保障工具，然后再通过掌握一些新的工具来将这两者有机的结合。事实上，如果没有为传统的WEB程序做过可伸缩性方面的设计，要么对于如何设计Web Service的伸缩性，也会无从下手。
值得注意的是：不是通过保证每一个服务的性能，就能保证SOA的性能。就象不是把一堆服务绑在一起就是SOA一样。SOA的功能也不仅仅是通过SOBA暴露接口对外提供服务的总和（译注：想起一句古语，总体大于局部之和）。还有，SOA的性能与现在迷人的Web2.0企业应用息息相关，企业不会将一个具有高可用性的，易协作的程序架构在一个无法保证性能的系统上，所以更要关注SOA的性能。
言而总之，解决SOA的性能问题需要一套完整基于SOA的企业系统架构方案。那些性能瓶径有如海浪，可能出现在企业的每一部分，在每一个抽象层上。事实上，SOA为用户隐藏企业架构复杂度的同时，却是对企业提出更多高的需要，因为SOA需要的高可靠性，高性能要求企业在每一个方面都提供高性能，高可靠性。