|
|
簡介
前面一篇《關于大型ASP.NET應用系統的架構-架構的選擇》寫完之后，有一些同仁熱心回復，有的是提問題，同時希望能舉一些例子來說明；有的是提建議，希望下一篇寫得更詳細點；還有的同仁提出不同的觀點。感謝大家的參與。會繼續努力的。本文將針對Layer和Tier的區別做個辨析。并詳細介紹3 Tier / N Tier架構中各Tier的開發。各Tier的分布式方式。以及為了達到高性能，低延遲，高可伸縮性，需要采取哪些方法和手段。
意指能支持同時在線用戶數目很多的ASP.NET應用系統。同時在線用戶數目要達到多少才算大型。其實也沒有一個可以作為共識的定義，個人認為如果一個應用系統能做到7x24小時同時在線用戶數不少于5000的，應該可以稱為大型應用系統。例如：微軟的官網(www.microsoft.com)，7x24小時都有來自全球的人訪問，有查閱MSDN的，有訪問微軟博客的，有看微軟產品信息的，有逛微軟論壇的，等等等等。同時訪問微軟官網的人太多了，遠多于5000。還有Myspace。 它有總數為幾千萬的用戶，它的同時在線用戶數也是相當驚人的。它之所以能服務眾多的用戶，是因其背后有一個龐大的系統來支撐。
層Layer和排Tier的辨析
這里針對上篇的評論，對層Layer和排Tier做個辨析。上篇提到了分層Layer的架構只能部署在同一臺服務上，有同仁在評論里提出不同意見，說分層的架構也可以部署到多臺服務器上的。層Layer是指應用程序各功能在邏輯上的分組，而排Tier表示了應用程序各功能是物理分部在多臺計算機上。層Layer很好理解，就是相同功能的類被邏輯上分到了一組，如：數據存取的類都放到了一塊，在同一個名稱空間下，在同一個程序集里，商務邏輯的類也是一樣進行分組，各組之間有統一的調用形式。如商務邏輯的類引用數據存取的類，調用其方法，取得返回結果。同時UI層可調用商務邏輯層的類。商務邏輯層的類既有服務UI層的功能，也有調用數據訪問層的功能。是個承上啟下的層。這些層都是按照功能來劃分的。層Layer是一種邏輯上的劃分。排Tier是特指物理的劃分，應用程序的各功能，分別被放在了不同的服務器上，如UI功能單獨占用一些服務器，商務邏輯功能占用另外的一些服務器。這兩種功能部件之間有服務器的邊界，那么就有專門負責分布式調用的功能部件。如果單從功能邏輯上看，排Tier中也是有層Layer的，只是比傳統層Layer的劃分多了一些用于分布式調用的層Layer。排Tier是各層Layer物理分離后，再加入一些負責分布式調用的層Layer才形成的。排Tier和層Layer是有著聯系的。從這個意義上說，排Tier是層Layer物理分離時的特例。有層Layer物理分離的情況下，可以稱之為分層的架構，但是實際上這并不準確，因為排Tier是專門為這個場景定義的。有物理分離，就叫排Tier更準確些。層Layer只要一做物理分離，就轉化成了排Tier。
從部署角度試圖來區別分層Layer的架構和3 排Tier / N 排Tier的架構。因為物理分離的場景已經被定義成排Tier，那么剩下的就只能是物理不分離的場景了。所以分層Layered架構就特指部署在同一臺服務上的場景（即物理不分離），3 排Tier / N 排Tier架構就特指各層Layer物理分離的場景。分層的架構部署到多臺服務器上，理論上是可以的，但是光靠原有的層是不夠的，有了服務器的邊界之后，原來在同一個進程里面的方法調用就不再可行，必須新加一些層來做分布式的調用，才能讓原來的各層運行起來。等做完這一切，發現這個架構再叫分層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都各有特點。了解其特點后再做權衡取舍才比較合適。
完全不采用SesstionState
完全不采用SesstionState是在Web.config中寫上<sessionState mode=”Off”/> 或者 <Pages enableSessionState=”Off”/>來禁止SessionState。那整個應用的所有頁面都不會用SessionState。其實這不全面，http請求處理周期里還有一個系統默認的httpmodule在處理SessionState。還須在Web.config加一句：
<httpModules>
<remove name="Session" />
</httpModules>
NET技術：關于大型ASP.NET應用系統的架構—如何做到高性能高可伸縮性，轉載需保留來源！
鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。
