因为协调对SOA应用是如此的重要，其细节对应用性能会产生重大影响。本文为消息交换的协议转换最小化提供指南，包括使用设计模式来聚合组件，为SOA应用增加装置，以及优化网络实现最佳响应时间等。

　　面向服务架构（SOA）的原则得到认可已有近20年的时间了，但是随着对云以及移动应用服务化的兴趣日益提高，SOA发展到了前所未有的深度。这一范围的延伸自然也会把SOA引入到对性能更为敏感的应用中，而SOA组件化、松耦合的原则就与高效接口、快速响应的实时性原则发生了冲突。

　　SOA性能与原则的平衡存在若干规则，但是需要特别关注那些对逻辑由分布式组件协调创建的应用。这是云最有可能形成的模式，在移动应用依赖于将逻辑从设备卸载到云端去时更是如此。

　　在SOA应用中，“协调”往往被用于定义构建应用逻辑流的流程，即将应用组件通过工作流引擎、消息总线或服务总线整合到一起。许多企业事务处理应用都是靠编排而来的，而企业服务总线（ESB）则往往是用得最多的。

　　功能完备的ESB包括消息排队和管理，需处理可用性短暂或可能存在多个实例的组件。还会提供一门流程定义语言（如Web services Business Process Execution Language或BPEL），此外还要有允许组件无需拥有兼容的本地接口、可以动态链接的接口和协议转换。显然，这些有助于实现可观的灵活性、尤其是涉及到多个组织时。

　　在高性能应用中，编排的挑战是SOA创造出来的灵活性过头了。有些用户曾报告说，一旦组件化的范围很广，再加上需要协议和接口转换来连接应用组件的话，交易处理时间会延长到原来的10倍。如果应用性能至关重要的话，用户不大可能会接受这种情况，所以需要采取措施减少过度编排的情况。

　　第一步是确保工作流消息格式及预期组件接口格式完全兼容。这可以消除对协议和格式转换的需要，这两者往往是最耗时的活动。如果所有应用组件均来自于同一组织，这件事情好办，但如果涉及到套装软件或多个组织，就需要对组件接口进行一些调整了。可试着使用Adapter Design Pattern来协调接口，不过要测试结果来确保调整后的速度要比已有的消息总线转换更快。

　　第二步是将某些组件聚合成更高层面的逻辑单元，这样内部接口就可以指向而不需要基于消息。对于分散为3、4个组件然后在其间传递消息却不能提高多少灵活性的情况，可用一个简单的应用将这些组件连接成一个单元，然后再将该单元接入消息总线。如果工作流牵涉到一组组件层迭的话这种做法尤其有用。

　　这种办法的局限性在于，需要编写一个“连接”应用，把所有的SOA组件直接连接起来，完全排除了消息总线的需要。总线的灵活性被牺牲掉了，不过如果应用内部组件间的关系是相对静态的话，由于不需要编排，协调过头的情况得到显著降低。

　　第三种策略是用硬件替换分散编码的组件来执行数据库查询和分析之类的任务。这些硬件往往可执行“脚本”，脚本可以编译并加载到设备当中，根据需要激活。这通常要比开发基于组件的分析或数据库应用快得多，同时，因为设备的输入或输出消息往往是简单的请求或响应，所以也可以降低与分散组件的更广泛交互相关的通信开销。

　　降低协调开销策略的下一步是优化消息服务总线实现的选择。ESB是一种架构模型，而非标准或实现，而若干底层消息总线要素的组合可以结合起来创建一到多个ESB实现。通过挑选那些的确有使用计划的组件，然后测试那些实现的性能，有可能将开销降低50%以上。

　　管理编排开销的最后一条策略是改善连接网络的性能。要想有效做到这一点，需要筹划协调应用中的消息流，找出重复出现的或处在流程关键点的那些消息流。此处的目标是识别影响整体延迟的那些交换，然后在网络层面让那些组件“靠得更近”来减少延迟。

　　记住，将组件共同部署在同一虚拟机器（vSwitch）或同一数据中心局域网内的性能表现要优于组件是通过广域网分布的。在移动组件时须小心处理好安全和访问控制问题；有时候一台新的主机会有不同的访问和安全策略，还可能引发合规性问题。

　　通过组件下发工作的应用功能协调是抽象的一种形式，所有的抽象都会有将影响性能的细节隐藏起来的风险。对应用模块化或工作流的任何改动都会对性能生重大影响，因此对每一项变更预先进行足够数据量的测试以确保测试与产品行为类似至关重要。把这一项加入应用生命周期管理目标中，对于维持高性能SOA应用的工作效率来说是必不可少的。