四方面分析WCF性能

随着时代的发展，Microsoft推出的WCF被我们越来越多的人使用，我们就WCF性能分析一下，设计、构建、维护和版本控制分布式应用时一个复杂的任务。安全性、可靠性、事务性和伸缩性的因素和任务变得更加复杂。因为问题的复杂性，所以WCF被设计来解决这些问题，WCF是相当复杂的技术。为了能看清WCF性能，我把主要的功能分为10个类别：独立版本控制、异步只进消息、平台统一、安全性、可靠性、事务支持、互操作性、性能、扩展性和配置性。

独立版本控制

#T#应用系统版本控制已经成为一个头疼的问题。如我之前提到的，面向组件的设计不能在分布式应用中很好地解决这些问题。任何技术如果在分布式世界里获得认可，必须允许分布式应用的不同部分能够独立的版本控制。遵照WS-*规范，关注WS-*关于消息定义的内容，允许被调用的服务可以再不同速率开发。这些特性不像创建WCF应用的底层原理那么重要，但是我认为这是使用WCF最重要的副产品。

异步单向消息

我们的许多应用是使用请求-响应模式调用功能的。典型的是，我们调用一个功能，然后等待结果返回，然后根据返回结果执行。这种方式在Internet上尤为多见。每次我们请求一个页面，我们必须等待网页的响应。局限我们的条件，大部分分布式应用使用的都是请求-响应方式。尽管开始看起来不自然，对于穿越 IO边界的任务分布式应用，异步只进消息方式是更加高效的方式。我认为这是使用WCF的又一个好处。异步只进消息方式允许使用高效的处理资源，更加方便地使用分布式应用的高级的功能、可靠性和相应能力。

平台统一

过去微软已经发布的很多分布式技术;有些成为WCF诞生的重要的导向技术。并且许多技术依然在使用。例如，在WCF发布以前，微软支持5种主要的分布式技术： RPC, WSE, ASMX, Remoting, COM+, 和MSMQ。过去，***的分布式技术取决于应用系统的需求。例如，假如分布式应用都是基于.NET Framework，那么会选择.NET Remoting，因为它是.NET Remoting应用程序之间一种高效的通信方式。如果一个应用需要担保消息传输和持久化，那么MSMQ是***的选择。两个技术有不同的API、编程方式、操作要求和配置需求。结果，应用程序代码紧密地绑定到这些技术上，这些技术也绑定到特定的功能上。一些新的技术允许我们组合特性，比如事务性和队列性的COM+。只要需求不改变或者不使用其它的不支持的方式，这种模式是可以工作的。

什么是你的应用系统与其他的 .NET Framework应用、非 .NET Framework应用和支持事务的处理通信所需要的？在WCF之前，没有好的选择，本质上讲，这些需求使得开发者要么放弃一个需求要么编写自己的通信技术。与旧的技术相比，WCF能够集成旧的技术特性并且统一为一个编程模型，如表1-1所示。

表1-1 WCF特性对比

客观地说，WCF性能没有提供给我们无约束连接的特性，但是确实提供给了我们比以更多的连接特性。