一些层来做分布式的调用,才能让原来的各层运行起来。等做完这一切,发现这个架构再叫分层Layered的架构就不合适了,必须得叫3
排Tier / N 排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都各有特点。了解其特点后再做权衡取舍才比