【转载】关于大型asp.net应用系统的架构—如何作到高性能高可伸缩性

http://www.cnblogs.com/mikelij/archive/2010/11/30/1892261.html

关于大型asp.net应用系统的架构—如何作到高性能高可伸缩性

简介

　　前面一篇<<关于大型asp.net应用系统的架构-架构的选择>>写完以后，有一些同仁热心回复，有的是提问题，同时但愿能举一些例子来讲明；有的是提建议，但愿下一篇写得更详细点；还有的同仁提出不一样的观点。感谢你们的参与。会继续努力的。本文将针对Layer(层)和Tier(排)的区别作个辨析。并详细介绍3 Tier / N Tier架构中各Tier的开发。各Tier的分布式方式。以及为了达到高性能，低延迟，高可伸缩性，须要采起哪些方法和手段。

关于“大型asp.net应用系统 ”的概念

　　意指能支持同时在线用户数目不少的asp.net应用系统。同时在线用户数目要达到多少才算大型。其实也没有一个能够做为共识的定义，我的认为若是一个应用系统能作到7x24小时同时在线用户数很多于5000的，应该能够称为大型应用系统。例如：微软的官网www.microsoft.com，7x24小时都有来自全球的人访问，有查阅MSDN的，有访问微软博客的，有看微软产品信息的，有逛微软论坛的，等等等等。同时访问微软官网的人太多了，远多于5000。还有Myspace。 它有总数为几千万的用户，它的同时在线用户数也是至关惊人的。它之因此能服务众多的用户，是因其背后有一个庞大的系统来支撑。

Layer和Tier的辨析

　　这里针对上篇的评论，对Layer和Tier作个辨析。上篇提到了Layered(分层)的架构只能部署在同一台服务上，有同仁在评论里提出不一样意见，说Layered的架构也能够部署到多台服务器上的。Layer是指应用程序各功能在逻辑上的分组，而Tier表示了应用程序各功能是物理分部在多台计算机上。Layer很好理解，就是相同功能的类被逻辑上分到了一组，如：数据存取的类都放到了一块，在同一个名称空间下，在同一个程序集里，商务逻辑的类也是同样进行分组，各组之间有统一的调用形式。如商务逻辑的类引用数据存取的类，调用其方法，取得返回结果。同时UI层可调用商务逻辑层的类。商务逻辑层的类既有服务UI层的功能，也有调用数据访问层的功能。是个承上启下的Layer。这些Layer都是按照功能来划分的。Layer是一种逻辑上的划分。Tier是特指物理的划分，应用程序的各功能，分别被放在了不一样的服务器上，如UI功能单独占用一些服务器，商务逻辑功能占用另外的一些服务器。这两种功能部件之间有服务器的边界，那么就有专门负责分布式调用的功能部件。若是单从功能逻辑上看，Tier中也是有Layer的，只是比传统Layer的划分多了一些用于分布式调用的Layer。Tier是各Layer物理分离后，再加入一些负责分布式调用的Layer才造成的。Tier和Layer是有着联系的。从这个意义上说，Tier是Layer物理分离时的特例。有Layer物理分离的状况下，能够称之为Layered的架构，可是实际上这并不许确，由于Tier是专门为这个场景定义的。有物理分离，就叫Tier更准确些。Layer只要一作物理分离，就转化成了Tier。

　　从部署角度试图来区别Layered的架构和3 Tier / N Tier的架构。由于物理分离的场景已经被定义成Tier，那么剩下的就只能是物理不分离的场景了。因此Layered架构就特指部署在同一台服务上的场景（即物理不分离），3 Tier / N Tier架构就特指各Layer物理分离的场景。Layered的架构部署到多台服务器上，理论上是能够的，可是光靠原有的Layer是不够的，有了服务器的边界以后，原来在同一个进程里面的方法调用就再也不可行，必须新加一些Layer来作分布式的调用，才能让原来的各Layer运行起来。等作完这一切，发现这个架构再叫Layered的架构就不合适了，必须得叫3 Tier /  Tier架构才合适。

　　Layer和Tier之间有联系，Layered的架构和3 Tier / N Tier架构能够互相转化。

总体映象

　　从前面的描述中能够得知应用系统的每一Tier都是由许多服务器来完成的。好比UI  Tier，能够是几十个服务器，几百个服务器，甚至是几千个服务器。具体每个Tier所需服务器的数目根据实际的须要来配置。所谓实际的须要就是看这一Tier服务器的硬件资源利用率。好比CPU, 内存，磁盘读写等状况，若是至关高，就必须加入新的服务器部署该Tier一样的应用到新服务器上。让新的服务器也能分担些压力。其实这就是要让应用程序能支持高可伸缩性。在每个Tier之间有硬件负载均衡，再其后就是下一个Tier的服务接口了。在其服务接口以后才是该Tier的服务。

　　除了高伸缩性以外，还有如何保证高性能。即应用程序必须是良好设计的。在每个Tier的内部，能够采起一些措施让应用程序的执行效率达到最高。让硬件的资源获得充分的利用。这有一些策略，如缓存。减小访问数据库的次数，等等。如下是一个可伸缩的asp.net应用系统的总体映象图：

一个在互联网上的用户的请求的处理过程是这样的：

1. 首先经硬件负载均衡处理，选定一个Web服务器来响应这个请求，而后将该请求交给该服务器。

2. 此Web服务器执行所请求的页面，该页面的后端代码先查询缓存服务器，即调用缓存服务接口查询是否已经有缓存，若是有，就直接返回缓存的结果。

3. 若是缓存里没有就调用商务逻辑服务接口，进而调用商务逻辑服务。商务逻辑服务执行时，若是须要访问数据库，会先检查缓存中是否有缓存的数据库内容，若是有，就会用缓存的数据库内容来进行商务逻辑的计算。若是没有缓存，就会调用数据访问接口以存取数据。

4. 相似地，数据访问服务也会查看缓存，而后根据所要求的数据内容去访问相应的数据库，若是是只读的请求，数据访问服务能够将数据库访问请求发给作日志复制的数据库服务器。若是是写的请求，能够发给主数据库服务器。

5. 数据库服务器执行应用的Sql请求，返回结果。再由数据服务返回给商务逻辑服务。

6. 商务逻辑服务再返回给Web服务器，由Web服务器生成页面内容返回给互联网上的用户。

以上过程与Layered的架构相似，只是比Layered的架构多通过了几个服务接口。若是没有这些服务接口，由于UI  Tier，商务逻辑Tier，数据访问Tier是在不一样的服务器上的，它们根本就不能直接对话。由于它们是在不一样的.net VM中的。它们必须得借助与这些服务接口才能互相之间进行调用。这些服务接口具体的组成技术能够是WCF，也能够是.net remoting，等。应该说目前最好的选择是WCF。

 

UI  Tier

关于SessionState的技术方案

　　为了让应用程序具备可伸缩性，必须让每一Tier都有负载均衡的特性，也就是要作到用户的请求由任何一个同一Tier中的服务器来处理都不会有任何问题。关于用户Session的处理就必须有一个妥善的解决方案。有很多人不赞同采用SessionState，以为SessionState对ASP.NET应用的性能影响比较大。还有人写文章说同一个SessionID的AcquireRequestState会在页面代码前得到对Session对象的锁，所以容易有较大的延迟，对性能影响不小。另外的人认为Session占用服务器的内存比较多，同时须要一些CPU资源来将Session中的对象序列化和反序列化。因此一种比较广泛的观点是不采用ASP.NET自己提供的Session机制。其实采用SessionState和不采用SessionState都各有特色。了解其特色后再作权衡取舍才比较合适。

彻底不采用SesstionState

　　彻底不采用SesstionState是在Web.config中写上<sessionState mode=”Off”/>     或者   <Pages enableSessionState=”Off”/>来禁止SessionState。那整个应用的全部页面都不会用SessionState。其实这不全面，http请求处理周期里还有一个系统默认的httpmodule在处理SessionState。还须在Web.config加一句：

<httpModules>
         <remove name="Session" />
</httpModules>

　　应用程序里彻底不采用ASP.NET自己提供的SessionState机制，可是应用的需求是要求应用程序有相似于Session的机制的。好比购物车的概念。记住用户选择了哪些商品，在用户点了买单时才处理用户选择了的商品。若是不用ASP.NET自己提供的SessionState机制，就必须本身实现一个Session机制。好比能够在数据库中有一张表来记录自定义的Session数据。若是用户浏览器支持cookie，能够用该cookie存储自定义的Session ID值。这个Session ID值用于到数据库中去查询存储的Session数据。若是用户浏览器不支持cookie，那么就能够在页面中放置隐藏的字段(hidden field)。此隐藏字段用于存储自定义的Session ID。还能够用URL中参数放一个Session参数的办法。这样得到的Session机制是本身管理的Session机制。须要将Session的建立，过期失效，查询Session数据，删除旧Session等都管理起来。

　　这样的自定义的Session机制将Session数据存储到了数据库。那么就能够不依赖与某一台具体的服务器。从而得到的可伸缩的特性。

采用SessionState

　　采用SessionState是ASP.NET默认的机制。ASP.NET的SessionState有几种模式。InProc，StateServer，SqlServer模式和自定义模式。InProc不支持负载均衡的场景。只有StateServer和SqlServer模式才支持。自定义模式是指咱们本身实现Session数据的持久化，好比将Session数据放到Oracle数据库或者MySql数据库中，自定义模式也能够支持负载均衡。在StateServer和SqlServer模式时，放入Session中的数据都必须是能序列化的。建议采用SqlServer模式的Session机制。配置是这样的：

<system.web>

  <sessionState mode=" Off | InProc | StateServer | SQLServer "

                     cookieless=" true | false "

                     timeout=" number of minutes "

                     stateConnectionString=" tcpip=server:port "

                     sqlConnectionString=" sql connection string "

                     stateNetworkTimeout=" number of seconds " />

</system.web>

　　Session采用了SqlServer模式以后，全部数据都会经序列化，并存储到SqlServer数据库中。采用这种模式的Session机制，其Session能够由任何一个UI  Tier的服务器来处理，由于Session数据是存储在专门的数据库中的。若是是采用这种模式的Session机制，那么最好有专门的数据库服务器供存储Session数据。经过上述安排，ASP.NET应用就得到了负载均衡，可伸缩的能力。

　　采用了ASP.NET的SessionState的以后，同一个Session ID下的不一样页面请求会有必定的制约。注意这里说的同一个Session ID下的不一样页面。这就象数据库的锁机制同样。默认的ASP页面设置都是能对Session对象进行读和写。那么若是同一个Session ID的两个不一样请求访问两个不一样的页面，就会由于都去锁住Session对象，而形成有一个请求被阻塞较长时间，由于要等另外一个请求处理完毕。有同仁可能以为奇怪，怎么会有同一个Session ID请求两个不一样的页面。其实这与页面中的iframe，frameset和AJAX技术有关。包含iframe, frameset的页面已经要存取Session了，iframe或者frameset里面的页面也要存取Session，就有可能形成一先一后，都是同一个Session ID，后面的页面被前面的页面锁住，直到前面的页面都处理完，释放对Session的锁，才能处理后面的页面。AJAX也相似。也存在这个问题。这个默认的机制所带来的延迟在小型的ASP.NET应用中能够不用理睬。可是在大型的ASP.NET应用中是必须解决的问题。要解决这个问题，只能从应用的角度尽力减小须要写Session的范围，即明确肯定哪些页面须要读且写Session数据。还须要肯定哪些页面是只须要读Session数据。另外还须要肯定哪些页面不须要参与读或者写Session数据，即与Session数据无关的页面。经过这样的工做，就肯定了Session的范围。对于须要读且写Session的页面，能够显示地在页面中写上< % @Page enableSessionState=”On”% >。对于只须要读Session的页面，能够写上< % @Page enableSessionState=”ReadOnly”% >。对于不须要Session的页面，能够写上< % @Page enableSessionState=”Off”%  >。在一个iframe相关的全部页面中，不要全部的页面都去读写Session，这样就能够避免Session争锁所带来的延迟。AJAX所涉及的页面也是如此，尽量地减小读写Session，发生这种Session争锁的延迟就会少一些。锁越少，整个UI  Tier的处理能力就会越大。

 

关于ViewState的技术方案

　　ViewState使服务器控件能够在往返行程中从新填充它们的属性值，而程序员不须要编写任何代码。这些属性值包括可见的属性，也包括不可见的。可见的属性如Text属性，不可见的是某些控件的ControlState。ControlState是比较特殊的内容，它老是存储在ViewState字段中。即便用EnableViewState="false"禁止了ViewState，ViewState字段仍是有一些内容，这些内容就是ControlState。

　　曾经听到很多人抱怨说ViewState大，有时光ViewState就几百K。一个页面的HTML，很大的部分是ViewState占用了。微软的文章也在说不须要ViewState的地方就禁止ViewState。因此合理决定应用程序哪些地方须要ViewState。毕竟ViewSate也必定程度上带给程序员一些方便。禁止ViewState是能够在整个应用的级别，页面的级别，和控件的级别来禁止。整个应用的级别禁止ViewState:  <pages enableViewState="false" enableViewStateMac="false" enableEventValidation="false"></pages>，页面的级别如：< % @ Page EnableViewState="false" % >，控件的级别如：<asp:datagrid EnableViewState="false" datasource="..." runat="server"/>。禁止了ViewState以后，页面中的__ViewState字段已经大大减少了，可是仍是存在。上面已经提到了，__ViewState字段里剩下的内容就是ControlState的。若是想让__ViewState字段没有内容，能够改写Page类的此两方法：

protected override void SavePageStateToPersistenceMedium(object viewState)
{
}

protected override object LoadPageStateFromPersistenceMedium()
{
    return null;
}

　　这样__ViewState字段就彻底没有内容了。固然咱们能够在此两方法里面设计出本身的持久化ViewState内容的方案。好比将ViewState持久化到缓存中去，或者持久化到SqlServer中去。那么ViewState的内容就再也不须要发送的到用户浏览器中了。上面介绍了一些在某些地方禁用ViewState的方法。下面就由开发者和用户来决定哪些页面或者控件须要ViewState，仍是彻底不要ViewState。ViewState机制具备两面性，一方面方便了程序员，另外一方面可能对性能形成影响。因此要当心对待。

 

减小与服务器的交互次数和没必要要的服务器端处理

Page.IsPostBack

　　Page.IsPostBack能够判断是否有Form提交。第一次访问时的处理和有Form提交的处理是不同的。这样能够避免没必要要的服务器端处理。

AutoPostBack属性

　　许多服务器端控件都有AutoPostBack，能禁止的都禁止了。

多作客户端的数据验证

　　用户在浏览器里面的输入，尽可能先用客户端JavaScript验证处理，等经过了再提交给服务器。这样减小向服务器提交请求的次数。

AJAX的请求量进行控制

　　AJAX带来了很炫的效果，可是能适当地减小调用AJAX调用次数，好比可否合并AJAX的调用。

用Server.Transfer不用Response.Redirect

　　Server.Transfer发生在服务器端，而Response.Redirect发生在用户浏览器中。会多一次HTTP请求。

 

去除没必要要的默认httpModule

如不要SessionState，不要WindowsAuthentication，不要PassportAuthentication等等：

<httpModules>
         <remove name="Session" />
         <remove name="WindowsAuthentication" />
         <remove name="PassportAuthentication" />
         <remove name="AnonymousIdentification" />
         <remove name="UrlAuthorization" />
         <remove name="FileAuthorization" />
</httpModules>

 

设置processModel

手动设置processModel参数中的MaxWorkerThreads 和 MaxIOThreads 属性，经过观察效果带调整参数。若是机器资源容许，能够稍微多点。

 

设置Web garden

　　只要服务器资源容许，就能够创建Web garden，在同一个服务器上多开几个工做者进程。32位Windows上一个进程一般只能占用2G-3G内存(由于高地址的2G或者1G是Windows自己用来装配系统文件用的)。64位Windows上一个进程能占用的内存相对32位大一点，可是服务器有好比100多G的内存，能够适当多开几个工做者进程。这能够增长单台服务器的处理能力。要设置Web garden能够先在IIS管理器里面找到对应的应用程序池，在查看该应用程序池的高级属性，再找到最大工做者进程参数，见图。

缓存

　　ASP.NET中可用的缓存主要有：页面级的缓存，控件级，System.Web.Caching.Cache，以及分布式缓存如Velocity和memcahced。页面级的缓存能够在ASPX页面用< % @ OutputCache Duration="10" VaryByParam="none" % >，在用户控件中能够用< % @ OutputCache Duration="10" VaryByParam="none" VaryByControl=””% >，与页面级的cache相比，多了VaryByControl参数。必须得指出这些页面级的和控件级的缓存是存储在特定的Web服务器上的。除非在负载均衡的硬件上作特殊的设置，不然这些页面级和控件级的缓存都意义不大。由于这些页面级的和控件级的缓存是存储在特定的Web服务器上的，第一次用户的请求是由此服务器处理的，而后有了页面缓存，若是负载均衡硬件将第一次之后的请求交由其余服务器处理，那么这个处理第一次请求所作的页面和控件级缓存都失去了意义。只有进行了特殊设置后，负载均衡的硬件才能知道刚才这个请求是哪一个服务器处理的，就继续向该服务器转发HTTP请求。那么保存的页面等缓存才会起到相应的做用。System.Web.Caching.Cache是个很好的缓存机制，能够给程序员利用来缓存一些内容。惋惜它不是分布式的。它的存储限定在特定的服务器上。因此它对负载均衡是不支持的。要支持负载均衡，须要使用分布式的缓存如Velocity或memcached，在UI  Tier缓存的内容能够是数据库查询结果。若是是本身管理的Session机制，能够将分布式缓存做为Session的存储，全部Session中的对象，能够存储在分布式缓存中。还有ViewState，若是但愿客户浏览器不下载ViewState可是又要用ViewState，能够重载Page类的SavePageStateToPersistenceMedium和LoadPageStateFromPersistenceMedium方法，并在此方法中将ViewState存储到分布式缓存。

 

考虑预编译

　　将全部ASP.NET页面都预先编译。能够减小第一次访问时因为ASP.NET编译页面所带来的延迟。

在生产环境禁用调试模式

　　生产环境使用Release模式的编译，会使程序运行稍微快一点。

尽可能避免异常

　　异常是非正常的程序控制流。发生异常多对性能的影响比较大。因此在程序中多对可能的状况进行检测，好比判断某对象是否为空。此一样适用于其余Tier。

尽可能避免锁住资源

　　在多线程的场景下，尽量地去避免锁住资源。尽可能各线程都用私有的资源。此一样适用于其余Tier。

压缩页面和相关文件

　　好比能够打开IIS的gzip，还有用一个自制的HTTP module压缩页面的HTML, .js文件。去掉不显示的回车和空格。进行尽量多的压缩。

 

商务逻辑Tier

商务逻辑服务接口

　　前面已经提到，服务接口能够考虑用WCF, Remoting等技术。目前最好的是采用WCF。缘由是WCF支持事务，支持多种通讯方式。商务逻辑服务有时是必须在互联网上公开。因此WCF能够选用基于Web service的通讯方式，这样支持的外部系统比较多。若是商务逻辑服务只是在内部使用，能够选用TCP/IP socket的通讯方式。这个商务逻辑服务接口其实就是后面的商务逻辑服务的包装。商务逻辑服务提供哪些方法，就用相应的接口进行对应。

商务逻辑

事务的控制

　　商务逻辑这里应该对事务进行控制。这与WCF接口支持事务想匹配的。

预取与缓存

　　好比翻页，能够在用户取第一页时，取出5页，缓存起来，用户日后翻几页时就能够再也不查询数据库。减小对数据库的查询次数。有些查询特别多的数据，直接都在分布式缓存里面存着。只有缓存里没有的时候，才去查询数据库。

对数据库的访问也是能够分布式的调用

　　你们看到了上面的图，对数据库的访问也是须要经过分布式的调用才能完成。数据库查询的结果经过自定义的对象集合来传递。

采用自定义的对象做为商务逻辑的处理对象

　　这些自定义的对象其实就是一个数据库中数据的在内存中的反映。商务逻辑的处理对象最好用自定义的对象。不要用DataSet。

商务逻辑Tier最好是无状态的

　　该Tier最好是状态无关的。与商务有关的数据都存储到分布式缓存里面。服务器内存里面不长时间存储商务有关的数据。这样，一个对商务逻辑的请求就能够由任何一台商务逻辑Tier的服务器来处理，这样就作到了负载均衡。

长时间计算型的任务最好交给其余系统来在后台处理

　　有些计算密集的任务，最好交给其余系统在后台运行。与计算密集的系统交互就只经过数据文件进行交互。

 

数据访问Tier

数据访问服务接口

　　相似于商务逻辑服务接口，数据访问服务接口能够考虑用WCF, Remoting等技术。目前最好的是采用WCF。缘由是WCF支持事务，支持多种通讯方式。能够选用基于Web service的通讯方式，也能够选用TCP/IP socket的通讯方式。这个数据访问服务接口其实就是后面的数据访问服务的包装。

数据访问

对事务的支持

　　如前所述，商务逻辑控制着事务，数据访问Tier只是做为商务逻辑控制的事务的一部分。数据访问Tier中有许多数据库的操做，如，查询，更新等。建议全部的数据库操做都用存储过程来实现。这些数据库操做都做为商务逻辑控制的事务的一部分。不要在存储过程当中实现商务逻辑。这些数据库操做都只是替商务逻辑服务完成数据库查询或者存储数据到数据库的任务。因此不要在存储过程或者数据访问Tier实现任何商务逻辑的内容。

 

数据库读写分离的支持

　　如前图所示，数据库有只读模式的。能够将部分读的请求分流到只读模式的数据库服务器上。只有写的请求才流到主数据库服务器上。这就要求分别支持不一样的链接。

链接池的管理

　　每台数据库服务器所容许的链接数是必定的。须要管理好个数据访问服务的数据库链接。管理好每台数据访问服务服务器链接池。

在读的时候用SqlDataReader

　　读取数据的时候，可用SqlDataReader来读取快速只进的数据流。

缓存

　　将数据库访问得到的内容缓存到分布式缓存服务器上。

 

数据库的设计和安排

读写分离

　　主数据库服务器是集群的数据库服务器。SqlServer 2008 R2 / Windows Server 2008 最多支持16台服务器的集群。能够架设一些只读模式数据库服务器，采用日志复制方式，将主数据库的全部日志复制到只读模式的数据库服务器上。那么只读模式数据库服务器内容就能够保持和主数据库服务器一致。这些只读数据库服务器就能够用于分担读的压力。

库表的分离

　　从应用的角度将某一些数据分到多个数据库来存储。好比Myspace有7000多万用户，它把每一百万用户存放于一个数据库。这样每一个数据库都小了不少。查询起来相对快一些，可是程序就会设计得复杂一点。分开的数据库能够放在不一样的服务器，也可在同一服务器。请根据实际状况来决定。

表的设计

　　3NF, BCNF是确定要达到的。这很少说了。主要想说说汇集索引。表的汇集索引是很关键的一个索引。须要从应用角度考虑，最多的查询是什么样的，而后按照使用最频繁的查询来设计汇集索引。通常来讲汇集索引须要选用短的，基本数据类型的字段。好比整数, 固定长度的文本，日期之类的字段做为汇集索引的字段。并且具备单向递增的特性，好比日期，自增的字段。良好的汇集索引的设计，对最频繁的查询的性能改进是颇有帮助的，同时对插入，更新都有较大的帮助。插入时是在物理的表记录末尾加入新记录，引发的磁盘IO较小；更新时也可按照索引来很快查找到记录并更新。同时也得考虑删除时的效率。若是可能的话尽可能不要删除记录，只将须要删除的记录置成删除状态。

　　除了汇集索引，还有普通索引，合适的普通索引对查询的性能也是有帮助的。仍是分析应用可能的查询，能够将次优先的那些查询分析一下，这些查询主要用到哪些字段做为搜索条件。而后能够适当地创建普通索引。这些汇集索引和普通索引对查询的性能是有帮助的。

建立表分区

　　将表的记录按必定规则来分到不一样的数据文件上存储。能够分区的字段也是基本的类型。好比日期，文本等。建立分区的表的IO能够由多个线程同时来读写不一样的数据文件。在IO上能够有所改进。

合理使用视图

　　建立必定数量的试图，能够对查询性能起到帮助。

 

分布式调用越少越好？

　　前面一篇文章<<关于大型asp.net应用系统的架构-架构的选择>>有同仁提出分布式调用越少越好的观点。这里能够说一下。若是只有一台服务器的时候，单纯比较用分布式调用和非分布式调用，分布式调用确定比非分布式调用慢，由于分布式调用要多一些中间接口的处理。可是非分布式调用能同时支持那么多人同时访问吗？非分布式调用能将用户的请求交由任何一个服务器来处理而不出现问题吗？万一一台服务器出现了问题，那么这台服务器上的用户就丢失他/她的会话和数据吗？你们看吧。

　　固然也有这种可能，就是整个系统中某些地方采用分布式调用，另一些地方采用非分布式调用。例如：商务逻辑服务和数据访问服务之间就不用分布式调用了。那么整个系统的图就成了这样：

　　这样作不是不能够，就是有其优缺点，优势是商务逻辑调用数据访问能够比所有分布式的更快，缺点就有多是，商务逻辑服务器多到必定程度，就会发现，数据库链接却不能再往上增长了，而要统一调度数据库链接也是很困难的。商务逻辑与数据访问的耦合度是否有点高？

 

结束语

　　对于大型的ASP.NET来讲，首先要保证负载均衡和可伸缩性，再来作到每一台服务器的性能最大化。要使整个系统的服务能力最大化，须要使用软件硬件的全部手段。这里谈到的只是一些方面，不够全面。