簡(jiǎn)介

　　前面一篇《關(guān)于大型ASP.NET應(yīng)用系統(tǒng)的架構(gòu)-架構(gòu)的選擇》寫完之后，有一些同仁熱心回復(fù)，有的是提問題，同時(shí)希望能舉一些例子來說明；有的是提建議，希望下一篇寫得更詳細(xì)點(diǎn)；還有的同仁提出不同的觀點(diǎn)。感謝大家的參與。會(huì)繼續(xù)努力的。本文將針對(duì)Layer和Tier的區(qū)別做個(gè)辨析。并詳細(xì)介紹3 Tier / N Tier架構(gòu)中各Tier的開發(fā)。各Tier的分布式方式。以及為了達(dá)到高性能，低延遲，高可伸縮性，需要采取哪些方法和手段。

　　關(guān)于“大型ASP.NET應(yīng)用系統(tǒng) ”的概念

　　意指能支持同時(shí)在線用戶數(shù)目很多的ASP.NET應(yīng)用系統(tǒng)。同時(shí)在線用戶數(shù)目要達(dá)到多少才算大型。其實(shí)也沒有一個(gè)可以作為共識(shí)的定義，個(gè)人認(rèn)為如果一個(gè)應(yīng)用系統(tǒng)能做到7x24小時(shí)同時(shí)在線用戶數(shù)不少于5000的，應(yīng)該可以稱為大型應(yīng)用系統(tǒng)。例如：微軟的官網(wǎng)(www.microsoft.com)，7x24小時(shí)都有來自全球的人訪問，有查閱MSDN的，有訪問微軟博客的，有看微軟產(chǎn)品信息的，有逛微軟論壇的，等等等等。同時(shí)訪問微軟官網(wǎng)的人太多了，遠(yuǎn)多于5000。還有Myspace。 它有總數(shù)為幾千萬的用戶，它的同時(shí)在線用戶數(shù)也是相當(dāng)驚人的。它之所以能服務(wù)眾多的用戶，是因其背后有一個(gè)龐大的系統(tǒng)來支撐。

　　層Layer和排Tier的辨析

　　這里針對(duì)上篇的評(píng)論，對(duì)層Layer和排Tier做個(gè)辨析。上篇提到了分層Layer的架構(gòu)只能部署在同一臺(tái)服務(wù)上，有同仁在評(píng)論里提出不同意見，說分層的架構(gòu)也可以部署到多臺(tái)服務(wù)器上的。層Layer是指應(yīng)用程序各功能在邏輯上的分組，而排Tier表示了應(yīng)用程序各功能是物理分部在多臺(tái)計(jì)算機(jī)上。層Layer很好理解，就是相同功能的類被邏輯上分到了一組，如：數(shù)據(jù)存取的類都放到了一塊，在同一個(gè)名稱空間下，在同一個(gè)程序集里，商務(wù)邏輯的類也是一樣進(jìn)行分組，各組之間有統(tǒng)一的調(diào)用形式。如商務(wù)邏輯的類引用數(shù)據(jù)存取的類，調(diào)用其方法，取得返回結(jié)果。同時(shí)UI層可調(diào)用商務(wù)邏輯層的類。商務(wù)邏輯層的類既有服務(wù)UI層的功能，也有調(diào)用數(shù)據(jù)訪問層的功能。是個(gè)承上啟下的層。這些層都是按照功能來劃分的。層Layer是一種邏輯上的劃分。排Tier是特指物理的劃分，應(yīng)用程序的各功能，分別被放在了不同的服務(wù)器上，如UI功能單獨(dú)占用一些服務(wù)器，商務(wù)邏輯功能占用另外的一些服務(wù)器。這兩種功能部件之間有服務(wù)器的邊界，那么就有專門負(fù)責(zé)分布式調(diào)用的功能部件。如果單從功能邏輯上看，排Tier中也是有層Layer的，只是比傳統(tǒng)層Layer的劃分多了一些用于分布式調(diào)用的層Layer。排Tier是各層Layer物理分離后，再加入一些負(fù)責(zé)分布式調(diào)用的層Layer才形成的。排Tier和層Layer是有著聯(lián)系的。從這個(gè)意義上說，排Tier是層Layer物理分離時(shí)的特例。有層Layer物理分離的情況下，可以稱之為分層的架構(gòu)，但是實(shí)際上這并不準(zhǔn)確，因?yàn)榕臫ier是專門為這個(gè)場(chǎng)景定義的。有物理分離，就叫排Tier更準(zhǔn)確些。層Layer只要一做物理分離，就轉(zhuǎn)化成了排Tier。

　　從部署角度試圖來區(qū)別分層Layer的架構(gòu)和3 排Tier / N 排Tier的架構(gòu)。因?yàn)槲锢矸蛛x的場(chǎng)景已經(jīng)被定義成排Tier，那么剩下的就只能是物理不分離的場(chǎng)景了。所以分層Layered架構(gòu)就特指部署在同一臺(tái)服務(wù)上的場(chǎng)景（即物理不分離），3 排Tier / N 排Tier架構(gòu)就特指各層Layer物理分離的場(chǎng)景。分層的架構(gòu)部署到多臺(tái)服務(wù)器上，理論上是可以的，但是光靠原有的層是不夠的，有了服務(wù)器的邊界之后，原來在同一個(gè)進(jìn)程里面的方法調(diào)用就不再可行，必須新加一些層來做分布式的調(diào)用，才能讓原來的各層運(yùn)行起來。等做完這一切，發(fā)現(xiàn)這個(gè)架構(gòu)再叫分層Layered的架構(gòu)就不合適了，必須得叫3 排Tier / N 排Tier架構(gòu)才合適。

　　層Layer和排Tier之間有聯(lián)系，分層Layered的架構(gòu)和3排Tier / N 排Tier架構(gòu)可以互相轉(zhuǎn)化。

　　整體映象

　　從前面的描述中可以得知應(yīng)用系統(tǒng)的每一排Tier都是由許多服務(wù)器來完成的。比如UI排Tier，可以是幾十個(gè)服務(wù)器，幾百個(gè)服務(wù)器，甚至是幾千個(gè)服務(wù)器。具體每一個(gè)排Tier所需服務(wù)器的數(shù)目根據(jù)實(shí)際的需要來配置。所謂實(shí)際的需要就是看這一排Tier服務(wù)器的硬件資源利用率。比如CPU, 內(nèi)存，磁盤讀寫等情況，如果相當(dāng)高，就必須加入新的服務(wù)器部署該排Tier同樣的應(yīng)用到新服務(wù)器上。讓新的服務(wù)器也能分擔(dān)些壓力。其實(shí)這就是要讓應(yīng)用程序能支持高可伸縮性。在每一個(gè)排Tier之間有硬件負(fù)載均衡，再其后就是下一個(gè)排Tier的服務(wù)接口了。在其服務(wù)接口之后才是該排Tier的服務(wù)。

　　除了高伸縮性之外，還有如何保證高性能。即應(yīng)用程序必須是良好設(shè)計(jì)的。在每一個(gè)排Tier的內(nèi)部，可以采取一些措施讓應(yīng)用程序的執(zhí)行效率達(dá)到最高。讓硬件的資源得到充分的利用。這有一些策略，如緩存。減少訪問數(shù)據(jù)庫的次數(shù)，等等。以下是一個(gè)可伸縮的ASP.NET應(yīng)用系統(tǒng)的整體映象圖：

　　一個(gè)在互聯(lián)網(wǎng)上的用戶的請(qǐng)求的處理過程是這樣的：

　　1. 首先經(jīng)硬件負(fù)載均衡處理，選定一個(gè)Web服務(wù)器來響應(yīng)這個(gè)請(qǐng)求，然后將該請(qǐng)求交給該服務(wù)器。

　　2. 此Web服務(wù)器執(zhí)行所請(qǐng)求的頁面，該頁面的后端代碼先查詢緩存服務(wù)器，即調(diào)用緩存服務(wù)接口查詢是否已經(jīng)有緩存，如果有，就直接返回緩存的結(jié)果。

　　3. 如果緩存里沒有就調(diào)用商務(wù)邏輯服務(wù)接口，進(jìn)而調(diào)用商務(wù)邏輯服務(wù)。商務(wù)邏輯服務(wù)執(zhí)行時(shí)，如果需要訪問數(shù)據(jù)庫，會(huì)先檢查緩存中是否有緩存的數(shù)據(jù)庫內(nèi)容，如果有，就會(huì)用緩存的數(shù)據(jù)庫內(nèi)容來進(jìn)行商務(wù)邏輯的計(jì)算。如果沒有緩存，就會(huì)調(diào)用數(shù)據(jù)訪問接口以存取數(shù)據(jù)。

　　4. 類似地，數(shù)據(jù)訪問服務(wù)也會(huì)查看緩存，然后根據(jù)所要求的數(shù)據(jù)內(nèi)容去訪問相應(yīng)的數(shù)據(jù)庫，如果是只讀的請(qǐng)求，數(shù)據(jù)訪問服務(wù)可以將數(shù)據(jù)庫訪問請(qǐng)求發(fā)給做日志復(fù)制的數(shù)據(jù)庫服務(wù)器。如果是寫的請(qǐng)求，可以發(fā)給主數(shù)據(jù)庫服務(wù)器。

　　5. 數(shù)據(jù)庫服務(wù)器執(zhí)行應(yīng)用的Sql請(qǐng)求，返回結(jié)果。再由數(shù)據(jù)服務(wù)返回給商務(wù)邏輯服務(wù)。

　　6. 商務(wù)邏輯服務(wù)再返回給Web服務(wù)器，由Web服務(wù)器生成頁面內(nèi)容返回給互聯(lián)網(wǎng)上的用戶。

　　以上過程與分層Layered的架構(gòu)類似，只是比分層Layered的架構(gòu)多經(jīng)過了幾個(gè)服務(wù)接口。如果沒有這些服務(wù)接口，因?yàn)閁I排Tier，商務(wù)邏輯排Tier，數(shù)據(jù)訪問排Tier是在不同的服務(wù)器上的，它們根本就不能直接對(duì)話。因?yàn)樗鼈兪窃诓煌?NET VM中的。它們必須得借助與這些服務(wù)接口才能互相之間進(jìn)行調(diào)用。這些服務(wù)接口具體的組成技術(shù)可以是WCF，也可以是.NET remoting，等。應(yīng)該說目前最好的選擇是WCF。

　　UI排Tier

　　關(guān)于SessionState的技術(shù)方案

　　為了讓應(yīng)用程序具有可伸縮性，必須讓每一排Tier都有負(fù)載均衡的特性，也就是要做到用戶的請(qǐng)求由任何一個(gè)同一排Tier中的服務(wù)器來處理都不會(huì)有任何問題。關(guān)于用戶的Session的處理就必須有一個(gè)妥善的解決方案。有不少人不贊同采用SessionState，覺得SessionState對(duì)ASP.NET應(yīng)用的性能影響比較大。還有人寫文章說同一個(gè)SessionID的AcquireRequestState會(huì)在頁面代碼前獲得對(duì)Session對(duì)象的鎖，因此容易有較大的延遲，對(duì)性能影響不小。另外的人認(rèn)為Session占用服務(wù)器的內(nèi)存比較多，同時(shí)需要一些CPU資源來將Session中的對(duì)象序列化和反序列化。所以一種比較普遍的觀點(diǎn)是不采用ASP.NET本身提供的Session機(jī)制。其實(shí)采用SessionState和不采用SessionState都各有特點(diǎn)。了解其特點(diǎn)后再做權(quán)衡取舍才比較合適。

完全不采用SesstionState

　　完全不采用SesstionState是在Web.config中寫上<sessionState mode=”Off”/>     或者   <Pages enableSessionState=”Off”/>來禁止SessionState。那整個(gè)應(yīng)用的所有頁面都不會(huì)用SessionState。其實(shí)這不全面，http請(qǐng)求處理周期里還有一個(gè)系統(tǒng)默認(rèn)的httpmodule在處理SessionState。還須在Web.config加一句：

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

        

        
        
      
        
NET技術(shù)：關(guān)于大型ASP.NET應(yīng)用系統(tǒng)的架構(gòu)—如何做到高性能高可伸縮性，轉(zhuǎn)載需保留來源！
        
鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請(qǐng)第一時(shí)間聯(lián)系我們修改或刪除，多謝。