轉：關於大型asp.net應用系統的架構-架構的選擇

來自：http://www.cnblogs.com/mikelij/archive/2010/10/26/1856014.html#commentform

前言

　　最近幾年在.net方面的工作經曆，讓我長久以來(有幾年了)想寫關於大型asp.net應用系統架構文章的念頭。之前和同事們聊天的時候說的都是一些思維片段，其中的想法不盡完善，聊完天再仔細想想，一些主意就逐漸清晰了。現在終於付諸行動了，將一些想到的主意與大家一起探討，也算是對過去幾年在ASP.NET方面的一個總結。這對我來說也是一個學習過程。

　　部落格園有不少同仁在寫系統架構或者公司專屬應用程式架構方面的文章，我看過其中一些。就我看過的這些文章，我發現他們當中相當多的人寫的是分層架構。從我的看法來說，分層是不錯。但是如果是我自己寫的話，我會從架構的選擇來說起。那麼應用程式的架構就有可能不選擇分層的架構，而選擇其他架構。另外我會從整個系統的角度來寫，即從硬體和軟體兩個角度來思考一個系統。

　　這些都是我的一些建議，希望對您有所協助。

 

簡介

 

　　大型asp.net應用要考慮如何服務眾多的訪問者，同時還要保證每個訪問者都獲得高品質的服務。需要面對不同語言的使用者；需要保證安全性；應用系統的伸縮性也是很強的，當伺服器叢集有點不足以擔負壓力時，可以向伺服器叢集中加入更多的伺服器來增加整個應用系統的服務能力。伺服器的可用性也會要求很高，一年的下線時間是很少的。伺服器的災難備份也是很好的，即使現在的機房遭受毀滅性打擊，也有災難備份可以恢複服務。伺服器上跑的asp.net應用是可擴充的，具有很好的可擴充性，同時具有良好的可維護性。本系列文章將談談大型asp.net應用系統架構的諸多方面。本篇將談到架構的選擇。

 

架構的選擇

 

架構的選擇與應用程式的類型有關。這裡說的是asp.net應用，那麼Client-Server的架構就很顯然排除了。剩下：

基於組件的架構

應用可以按組件劃分，不用組件實現不同功能和邏輯，組件之間的介面規範有很好的定義。某些組件可以重用。

分層Layered的架構

應用被劃分成了堆疊在一起的若干層，每一層完成特定的服務和功能，與其上下層介面，各層之間是調用被調用的關係。在最上面的層只有調用下面的一層，在中間的層則兼有調用和被調用。在最下面的層則是僅供上面的層調用。通常劃分成UI層，商務邏輯層，資料層等，並且通常多個層都部署在同一台伺服器上。

 

訊息匯流排型的架構

應用程式按照預定義的格式來收發訊息。有一個訊息佇列和訊息儲存，分發處理的任務。相關訊息的事件被程式處理。支援不同的系統平台。訊息匯流排裡面有若干定義好的訊息流程，訊息匯流排同各系統平台交換資料，支援不同的格式。將訊息交由不同的處理常式處理。

Model, View, Controller(MVC)架構

使用者互動的處理與UI顯示分離

使用者互動的處理和UI顯示與資料分離

3Tier/N Tier的架構

Tier可以譯成排。以與Layer(層)有所區別。將應用程式劃分成一系列的服務，包括UI, Business(商業邏輯), 資料等服務。各Tier可部署在不同的伺服器上。類似於分層(layer)的架構。通常分層(layer)不跨機器的邊界，也即所有層(layer)都部署在一台伺服器上。Tier是要跨機器的邊界。各Tier之間用預定義的通訊協定來通訊，如WCF, Web service, 或者TCP/IP等。分層(layer)的各層(layer)之間的通訊都是通過該程式設計語言的引用和調用來實現的。所以是有區別的。

 

物件導向的架構

應用可以劃分成自給自足的可重用的對象集合，對象包含了資料和行為。各對象之間有訊息互動。

面向服務的架構

 應用使用一個功能是通過調用一個服務。在服務提供者和調用者之間有通訊合約和訊息，通訊合約定義了訊息的格式和通訊的方式。訊息則包含通訊的內容。面向服務的架構是“要求-回應”的工作模式。應用程式是以一種服務提供的，調用者需要向服務發送預定義好的請求訊息，服務才做出響應。

 

這些架構類型都可以用來開發asp.net應用。我們可以從其中選擇架構類型的組合來，比如：分層Layered的架構 + 面向服務的架構。MVC架構 + 訊息匯流排型架構。具體的選則，取決於應用程式的要求。現在說一下如何選架構：

如果

• 有若干現成組件，比如以前系統的ActiveX組件或者.net的組件
• 應用程式足夠簡單而不需要分層的架構，通過調用這些組件就可完成大部分工作
• 不同語言開發的組件需要結合在一起，如ASP.net需要調用VB寫的COM+的組件
• 應用程式需要支援外掛程式技術，可以動態切換組件，例如用.net反射技術實現的外掛程式技術

那麼我們可以選擇基於組件的架構。

如果

• 應用程式比較複雜，不同的功能需要不同的層來各司其職，如資料訪問，商務邏輯，表現等。
• 有比較複雜的商務邏輯和流程。

那麼我們可以選擇分層的架構。

如果

• 有若干已有系統並且這些系統之間有特定的互動
• 需要讓一個系統與外部的其他系統互動
• 不同平台上的系統相互之間進行互動

那麼我們可以選擇訊息匯流排型的架構

如果

• 要獲得分離的UI視圖和處理邏輯
• 要UI視圖和處理邏輯與資料存放區分離

那麼我們可以選擇Model,View,Controller(MVC)架構

如果

• 應用全部在內部網裡
• 應用在互連網上，同時商務邏輯需要暴露給公眾使用
• 商務邏輯足夠複雜，需要專門的伺服器來供應商務邏輯服務。
• 應用程式比較複雜，不同的功能分布在不同的伺服器上，每一種功能，都可能是由一組伺服器來提供。

那麼我們可以選擇3 Tier/N Tier架構

如果

• 相關商業領域有足夠多的現實對象(這些對象通常是相關商務人員口中的名詞)，並且這些對象之間有互動
• 應用比較複雜，需要更多的抽象
• 對象的資料和行為都需要封裝以利重用
• 有足夠的資源來做深入的物件導向分析，如時間，人力等。

那麼我們可以選擇物件導向的架構。

如果

• 應用需要支援平台無關性
• 多個應用程式的功能放進一個單一的介面來提供
• 採用要求-回應模式運行
• 需要開發軟體加服務(Software plus service)，軟體即服務(Software as a service)類型的應用，或者雲端式計算的應用

那麼我們可以選擇面向服務的架構。

 

針對目前的情境：大型ASP.NET應用，那麼它最基本的需求可能是這樣的：

同時訪問的使用者將會是相當多的，比如幾千個，上萬個。

7x24小時都有大量使用者訪問

某些地方需要使用者登入以擷取一些需要授權才能獲得的資訊

 

我們可能選擇的架構組合可能是這樣的：

3Tier/N Tier的架構

Model, View, Controller(MVC)架構結合3Tier/N Tier的架構

3Tier/N Tier的架構結合面向服務的架構

3Tier/N Tier的架構結合物件導向的架構

當然也有可能是其他的組合。

　　分層Layered的架構不適合大型的ASP.NET應用。分層Layered的架構通常將UI層，商務邏輯，資料訪問層都部署在同一台伺服器上，首先一台伺服器不能負擔眾多的使用者，還有複雜的商務邏輯不是一台伺服器能全部擔負的。所以分層Layered的架構不適合大型的ASP.NET應用。小型的ASP.NET應用才適合分層Layered的架構。

　　基於組件的架構也不適合大型ASP.NET應用。通常來說大型的ASP.NET應用都是相當複雜的，它的UI介面，商務邏輯，資料都是複雜的。不會簡單到調用幾個控制項就完成了大部分的工作，大型的ASP.NET應用的每一個Tier排，都需要眾多的伺服器來分擔壓力，基於組件的架構的分布式能力有限，所以基於組件的架構是通常不會在大型ASP.NET應用裡考慮的，除非是有若干個重要的控制項，並且要考慮整合多個程式設計語言的控制項時，才會考慮基於組件的架構。而且是在某個局部使用，即需要與其他架構一起結合起來用。

　　訊息匯流排型架構可以在某些情境下參與大型ASP.NET應用的開發。通常是需要將多個系統平台整合在一起的時候。訊息匯流排型的架構需要結合其他的架構來共同構造ASP.NET應用。

　　MVC架構關注的更多的是UI，使用者互動的控制以及資料存取的分離。通常不能單獨去構造一個大型的ASP.NET架構。需要結合3Tier/N Tier架構來共同構造大型ASP.NET的架構。MVC架構在UI還有使用者互動上有固定的模式，所以可以在UI這一塊應用MVC的架構，當涉及到MVC中的模型Model時，就可以擴充到3 Tier/N Tier的架構。即在訪問模型Model時，就去訪問另外一個伺服器上的商務邏輯和資料存放區。這個可以用來表示：

　　物件導向的架構是更多地關注應用裡面的物件導向分析，設計等過程產生出來的結果。這個結果體現了現實世界中的對象之間的互動作用。物件導向的架構需要結合其他架構如3 Tier/N Tier架構來共同構造ASP.NET應用程式的架構。

　　面向服務的架構是在特定情境下需要的。即上面所說的，多個功能作為一項服務，提供一個統一的UI給外界使用者。大型ASP.NET應用中通常需要將商務邏輯提供給公眾訪問。這時就可以採用面向服務的架構。面向服務的架構也需結合其他架構如3 Tier/N Tier架構來共同構造ASP.NET應用程式的架構。

 　　3 Tier/N Tier架構對於大型ASP.NET應用來說是必須的。它的每一Tier排都由若干伺服器組成。只有這樣才可以服務眾多的使用者。如上面的圖所示，UI調用商務邏輯時得跨越機器的邊界，調用另外一台伺服器上的商務邏輯服務介面。

 

結束語

 

　　架構的選擇需要根據不同架構的特點和應用程式的需求來進行選擇，有時候需要用多個架構的組合才足以滿足一個複雜應用的需求。設計者需要根據實際情況來決定合適的架構選擇。

 

接下來將展開談談3 Tier/N Tier架構......