本文属spanzhang（张友邦）原创，发布地址为：http://blog.csdn.net/spanzhang。转载或引用请注明原文之出处，谢谢！
.NET企业级应用架构设计系列之开场白
.NET企业级应用架构设计系列之技术选型
这里要说到的是关于三层架构中的应用服务器。对于电子商务网站来说，成熟的架构基本上都是采用分层式的。分层的结构一方面适合人脑的思维方式，另一方面在解决扩展性方面非常有效。目前市面上的各大解决方案提供商在电子商务和一般WEB应用领域都有相应的分层解决方案，软件架构设计在这一方面几乎不存在多少争议。
出于对可扩展性以及可维护性的考虑，对业务逻辑的解耦得到的便是应用服务器。这样的情况在软件系统中非常常见，在任何情况下都能通过额外一层间接来获得灵活性，但可能会引入潜在的性能问题。在Windows Server 2008问世之前的.NET平台没有应用服务器的专门产品，架设应用服务器可以有多种可选的方案。常用的.NET应用服务器方案有：
A) 使用IIS驻留ASP.NET Web Service
B) 使用.NET Remoting提供远程对象
C) 使用Enterprise Services (COM+)提供跨进程对象调用
这三种方式中，采用TCP/Binary通道的.NET Remoting是三个方案中性能最好的，而采用ASP.NET Web Service则能提供更多的跨平台特性。在性能对比上，ASP.NET Web Service大约是TCP/Binary .NET Remoting的60%左右（和传递的数据有关），这中间的差异来自于网络传输上，ASP.NET Web Service会花费较多时间在大对象的数据串行化（Serialization）上。二进制格式的Remoting实现也提供了对象级（包括单件——singleton特性）的支持，在性能要求占主导地位的方案中较多采用。
面对这个情况，最好的解决方法是在实现的时候提供一个更加灵活的架构来随时调整策略而让调整的代价保持在最小。也就是说，把系统的核心逻辑实现为一个对象群，然后通过facet方式以最小的努力适配到不同的调用接口上。当然，最初是以SOA的方式发布WEB服务给客户端调用，以尽量实现可移植的环境。如果发现这种模式成为了系统中的性能瓶颈，则改为TCP/Binary .NET Remoting的方式发布对象。
总的来说，应用服务器的架构是一个演化模型，可以随着需求和实际负载的变化实行平滑过渡。当应用服务器的横向扩展也无法应付更大的负载的时候，实际的性能瓶颈已经转移到了系统的其它地方，比如磁盘访问或接入带宽等。