淺析大型ASP.NET應(yīng)用系統(tǒng)的架構(gòu)選擇
前言
最近幾年在.NET方面的工作經(jīng)歷，讓我長(zhǎng)久以來(lái)(有幾年了)想寫關(guān)于大型ASP.NET應(yīng)用系統(tǒng)架構(gòu)文章的念頭。之前和同事們聊天的時(shí)候說(shuō)的都是一些思維片段，其中的想法不盡完善，聊完天再仔細(xì)想想，一些主意就逐漸清晰了。現(xiàn)在終于付諸行動(dòng)了，將一些想到的主意與大家一起探討，也算是對(duì)過(guò)去幾年在ASP.NET方面的一個(gè)總結(jié)。這對(duì)我來(lái)說(shuō)也是一個(gè)學(xué)習(xí)過(guò)程。
博客園有不少同仁在寫系統(tǒng)架構(gòu)或者企業(yè)應(yīng)用架構(gòu)方面的文章，我看過(guò)其中一些。就我看過(guò)的這些文章，我發(fā)現(xiàn)他們當(dāng)中相當(dāng)多的人寫的是分層架構(gòu)。從我的看法來(lái)說(shuō)，分層是不錯(cuò)。但是如果是我自己寫的話，我會(huì)從架構(gòu)的選擇來(lái)說(shuō)起。那么應(yīng)用程序的架構(gòu)就有可能不選擇分層的架構(gòu)，而選擇其他架構(gòu)。另外我會(huì)從整個(gè)系統(tǒng)的角度來(lái)寫，即從硬件和軟件兩個(gè)角度來(lái)思考一個(gè)系統(tǒng)。
這些都是我的一些建議，希望對(duì)您有所幫助。
簡(jiǎn)介
大型ASP.NET應(yīng)用要考慮如何服務(wù)眾多的訪問(wèn)者，同時(shí)還要保證每個(gè)訪問(wèn)者都獲得高質(zhì)量的服務(wù)。需要面對(duì)不同語(yǔ)言的用戶；需要保證安全性；應(yīng)用系統(tǒng)的伸縮性也是很強(qiáng)的，當(dāng)服務(wù)器集群有點(diǎn)不足以擔(dān)負(fù)壓力時(shí)，可以向服務(wù)器集群中加入更多的服務(wù)器來(lái)增加整個(gè)應(yīng)用系統(tǒng)的服務(wù)能力。服務(wù)器的可用性也會(huì)要求很高，一年的下線時(shí)間是很少的。服務(wù)器的災(zāi)難備份也是很好的，即使現(xiàn)在的機(jī)房遭受毀滅性打擊，也有災(zāi)難備份可以恢復(fù)服務(wù)。服務(wù)器上跑的ASP.NET應(yīng)用是可擴(kuò)展的，具有很好的可擴(kuò)展性，同時(shí)具有良好的可維護(hù)性。本系列文章將談?wù)劥笮虯SP.NET應(yīng)用系統(tǒng)架構(gòu)的諸多方面。本篇將談到架構(gòu)的選擇。
架構(gòu)的選擇
架構(gòu)的選擇與應(yīng)用程序的類型有關(guān)。這里說(shuō)的是ASP.NET應(yīng)用，那么Client-Server的架構(gòu)就很顯然排除了。剩下：
基于組件的架構(gòu)
應(yīng)用可以按組件劃分，不用組件實(shí)現(xiàn)不同功能和邏輯，組件之間的接口規(guī)范有很好的定義。某些組件可以重用。
分層Layered的架構(gòu)
應(yīng)用被劃分成了堆疊在一起的若干層，每一層完成特定的服務(wù)和功能，與其上下層接口，各層之間是調(diào)用被調(diào)用的關(guān)系。在最上面的層只有調(diào)用下面的一層，在中間的層則兼有調(diào)用和被調(diào)用。在最下面的層則是僅供上面的層調(diào)用。通常劃分成UI層，商務(wù)邏輯層，數(shù)據(jù)層等，并且通常多個(gè)層都部署在同一臺(tái)服務(wù)器上。
消息總線型的架構(gòu)
應(yīng)用程序按照預(yù)定義的格式來(lái)收發(fā)消息。有一個(gè)消息隊(duì)列和消息存儲(chǔ)，分發(fā)處理的任務(wù)。相關(guān)消息的事件被程序處理。支持不同的系統(tǒng)平臺(tái)。消息總線里面有若干定義好的消息流，消息總線同各系統(tǒng)平臺(tái)交換數(shù)據(jù)，支持不同的格式。將消息交由不同的處理程序處理。
Model, View, Controller(MVC)架構(gòu)
用戶交互的處理與UI顯示分離
用戶交互的處理和UI顯示與數(shù)據(jù)分離
3Tier/N Tier的架構(gòu)
Tier可以譯成排。以與Layer(層)有所區(qū)別。將應(yīng)用程序劃分成一系列的服務(wù)，包括UI, Business(商業(yè)邏輯), 數(shù)據(jù)等服務(wù)。各Tier可部署在不同的服務(wù)器上。類似于分層(layer)的架構(gòu)。通常分層(layer)不跨機(jī)器的邊界，也即所有層(layer)都部署在一臺(tái)服務(wù)器上。Tier是要跨機(jī)器的邊界。各Tier之間用預(yù)定義的通信協(xié)議來(lái)通信，如WCF, Web service, 或者TCP/IP等。分層(layer)的各層(layer)之間的通信都是通過(guò)該編程語(yǔ)言的引用和調(diào)用來(lái)實(shí)現(xiàn)的。所以是有區(qū)別的。
面向?qū)ο蟮募軜?gòu)
應(yīng)用可以劃分成自給自足的可重用的對(duì)象集合，對(duì)象包含了數(shù)據(jù)和行為。各對(duì)象之間有消息交互。
面向服務(wù)的架構(gòu)
應(yīng)用使用一個(gè)功能是通過(guò)調(diào)用一個(gè)服務(wù)。在服務(wù)提供者和調(diào)用者之間有通信合同和消息，通信合同定義了消息的格式和通信的方式。消息則包含通信的內(nèi)容。面向服務(wù)的架構(gòu)是“請(qǐng)求-響應(yīng)”的工作模式。應(yīng)用程序是以一種服務(wù)提供的，調(diào)用者需要向服務(wù)發(fā)送預(yù)定義好的請(qǐng)求消息，服務(wù)才做出響應(yīng)。
這些架構(gòu)類型都可以用來(lái)開發(fā)ASP.NET應(yīng)用。我們可以從其中選擇架構(gòu)類型的組合來(lái)，比如：分層Layered的架構(gòu) + 面向服務(wù)的架構(gòu)。MVC架構(gòu) + 消息總線型架構(gòu)。具體的選則，取決于應(yīng)用程序的要求?，F(xiàn)在說(shuō)一下如何選架構(gòu)：
如果
有若干現(xiàn)成組件，比如以前系統(tǒng)的ActiveX組件或者.NET的組件
應(yīng)用程序足夠簡(jiǎn)單而不需要分層的架構(gòu)，通過(guò)調(diào)用這些組件就可完成大部分工作
不同語(yǔ)言開發(fā)的組件需要結(jié)合在一起，如ASP.NET需要調(diào)用VB寫的COM+的組件
應(yīng)用程序需要支持插件技術(shù)，可以動(dòng)態(tài)切換組件，例如用.NET反射技術(shù)實(shí)現(xiàn)的插件技術(shù)
那么我們可以選擇基于組件的架構(gòu)。
如果
應(yīng)用程序比較復(fù)雜，不同的功能需要不同的層來(lái)各司其職，如數(shù)據(jù)訪問(wèn)，商務(wù)邏輯，表現(xiàn)等。
有比較復(fù)雜的商務(wù)邏輯和流程。
那么我們可以選擇分層的架構(gòu)。
如果
有若干已有系統(tǒng)并且這些系統(tǒng)之間有特定的交互
需要讓一個(gè)系統(tǒng)與外部的其他系統(tǒng)交互
不同平臺(tái)上的系統(tǒng)相互之間進(jìn)行交互
那么我們可以選擇消息總線型的架構(gòu)
如果
要獲得分離的UI視圖和處理邏輯
要UI視圖和處理邏輯與數(shù)據(jù)存儲(chǔ)分離
那么我們可以選擇Model,View,Controller(MVC)架構(gòu)
如果
應(yīng)用全部在內(nèi)部網(wǎng)里
應(yīng)用在互聯(lián)網(wǎng)上，同時(shí)商務(wù)邏輯需要暴露給公眾使用
商務(wù)邏輯足夠復(fù)雜，需要專門的服務(wù)器來(lái)提供商務(wù)邏輯服務(wù)。
應(yīng)用程序比較復(fù)雜，不同的功能分布在不同的服務(wù)器上，每一種功能，都可能是由一組服務(wù)器來(lái)提供。
那么我們可以選擇3 Tier/N Tier架構(gòu)
如果
相關(guān)商業(yè)領(lǐng)域有足夠多的現(xiàn)實(shí)對(duì)象(這些對(duì)象通常是相關(guān)商務(wù)人員口中的名詞)，并且這些對(duì)象之間有交互
應(yīng)用比較復(fù)雜，需要更多的抽象
對(duì)象的數(shù)據(jù)和行為都需要封裝以利重用
有足夠的資源來(lái)做深入的面向?qū)ο蠓治?，如時(shí)間，人力等。
那么我們可以選擇面向?qū)ο蟮募軜?gòu)。
如果
應(yīng)用需要支持平臺(tái)無(wú)關(guān)性
多個(gè)應(yīng)用程序的功能放進(jìn)一個(gè)單一的界面來(lái)提供
采用請(qǐng)求-響應(yīng)模式運(yùn)行
需要開發(fā)軟件加服務(wù)(Software plus service)，軟件即服務(wù)(Software as a service)類型的應(yīng)用，或者基于云計(jì)算的應(yīng)用
那么我們可以選擇面向服務(wù)的架構(gòu)。
針對(duì)目前的場(chǎng)景：大型ASP.NET應(yīng)用，那么它最基本的需求可能是這樣的：
同時(shí)訪問(wèn)的用戶將會(huì)是相當(dāng)多的，比如幾千個(gè)，上萬(wàn)個(gè)。
7x24小時(shí)都有大量用戶訪問(wèn)
某些地方需要用戶登錄以獲取一些需要授權(quán)才能獲得的信息
我們可能選擇的架構(gòu)組合可能是這樣的：
3Tier/N Tier的架構(gòu)
Model, View, Controller(MVC)架構(gòu)結(jié)合3Tier/N Tier的架構(gòu)
3Tier/N Tier的架構(gòu)結(jié)合面向服務(wù)的架構(gòu)
3Tier/N Tier的架構(gòu)結(jié)合面向?qū)ο蟮募軜?gòu)
當(dāng)然也有可能是其他的組合。
分層Layered的架構(gòu)不適合大型的ASP.NET應(yīng)用。分層Layered的架構(gòu)通常將UI層，商務(wù)邏輯，數(shù)據(jù)訪問(wèn)層都部署在同一臺(tái)服務(wù)器上，首先一臺(tái)服務(wù)器不能負(fù)擔(dān)眾多的用戶，還有復(fù)雜的商務(wù)邏輯不是一臺(tái)服務(wù)器能全部擔(dān)負(fù)的。所以分層Layered的架構(gòu)不適合大型的ASP.NET應(yīng)用。小型的ASP.NET應(yīng)用才適合分層Layered的架構(gòu)。
基于組件的架構(gòu)也不適合大型ASP.NET應(yīng)用。通常來(lái)說(shuō)大型的ASP.NET應(yīng)用都是相當(dāng)復(fù)雜的，它的UI界面，商務(wù)邏輯，數(shù)據(jù)都是復(fù)雜的。不會(huì)簡(jiǎn)單到調(diào)用幾個(gè)控件就完成了大部分的工作，大型的ASP.NET應(yīng)用的每一個(gè)Tier排，都需要眾多的服務(wù)器來(lái)分擔(dān)壓力，基于組件的架構(gòu)的分布式能力有限，所以基于組件的架構(gòu)是通常不會(huì)在大型ASP.NET應(yīng)用里考慮的，除非是有若干個(gè)重要的控件，并且要考慮集成多個(gè)編程語(yǔ)言的控件時(shí)，才會(huì)考慮基于組件的架構(gòu)。而且是在某個(gè)局部使用，即需要與其他架構(gòu)一起結(jié)合起來(lái)用。
消息總線型架構(gòu)可以在某些場(chǎng)景下參與大型ASP.NET應(yīng)用的開發(fā)。通常是需要將多個(gè)系統(tǒng)平臺(tái)整合在一起的時(shí)候。消息總線型的架構(gòu)需要結(jié)合其他的架構(gòu)來(lái)共同構(gòu)造ASP.NET應(yīng)用。
MVC架構(gòu)關(guān)注的更多的是UI，用戶交互的控制以及數(shù)據(jù)存取的分離。通常不能單獨(dú)去構(gòu)造一個(gè)大型的ASP.NET架構(gòu)。需要結(jié)合3Tier/N Tier架構(gòu)來(lái)共同構(gòu)造大型ASP.NET的架構(gòu)。MVC架構(gòu)在UI還有用戶交互上有固定的模式，所以可以在UI這一塊應(yīng)用MVC的架構(gòu)，當(dāng)涉及到MVC中的模型Model時(shí)，就可以擴(kuò)展到3 Tier/N Tier的架構(gòu)。即在訪問(wèn)模型Model時(shí)，就去訪問(wèn)另外一個(gè)服務(wù)器上的商務(wù)邏輯和數(shù)據(jù)存儲(chǔ)。這個(gè)可以用下圖來(lái)表示：
面向?qū)ο蟮募軜?gòu)是更多地關(guān)注應(yīng)用里面的面向?qū)ο蠓治?，設(shè)計(jì)等過(guò)程產(chǎn)生出來(lái)的結(jié)果。這個(gè)結(jié)果體現(xiàn)了現(xiàn)實(shí)世界中的對(duì)象之間的交互作用。面向?qū)ο蟮募軜?gòu)需要結(jié)合其他架構(gòu)如3 Tier/N Tier架構(gòu)來(lái)共同構(gòu)造ASP.NET應(yīng)用程序的架構(gòu)。
面向服務(wù)的架構(gòu)是在特定場(chǎng)景下需要的。即上面所說(shuō)的，多個(gè)功能作為一項(xiàng)服務(wù)，提供一個(gè)統(tǒng)一的UI給外界用戶。大型ASP.NET應(yīng)用中通常需要將商務(wù)邏輯提供給公眾訪問(wèn)。這時(shí)就可以采用面向服務(wù)的架構(gòu)。面向服務(wù)的架構(gòu)也需結(jié)合其他架構(gòu)如3 Tier/N Tier架構(gòu)來(lái)共同構(gòu)造ASP.NET應(yīng)用程序的架構(gòu)。
3 Tier/N Tier架構(gòu)對(duì)于大型ASP.NET應(yīng)用來(lái)說(shuō)是必須的。它的每一Tier排都由若干服務(wù)器組成。只有這樣才可以服務(wù)眾多的用戶。如上面的圖所示，UI調(diào)用商務(wù)邏輯時(shí)得跨越機(jī)器的邊界，調(diào)用另外一臺(tái)服務(wù)器上的商務(wù)邏輯服務(wù)接口。
結(jié)束語(yǔ)
架構(gòu)的選擇需要根據(jù)不同架構(gòu)的特點(diǎn)和應(yīng)用程序的需求來(lái)進(jìn)行選擇，有時(shí)候需要用多個(gè)架構(gòu)的組合才足以滿足一個(gè)復(fù)雜應(yīng)用的需求。設(shè)計(jì)者需要根據(jù)實(shí)際情況來(lái)決定合適的架構(gòu)選擇。
原文鏈接：http://www.cnblogs.com/mikelij/archive/2010/10/26/1856014.html
【編輯推薦】
- 詳解ASP.NET MVC 3 beta新特性
- ASP.NET MVC 3讓依賴注入實(shí)現(xiàn)得更簡(jiǎn)單
- 詳解ASP.NET MVC 3 beta新特性
- ASP.NET MVC 3新特性與NuPack功能詳解
- .NET開發(fā)人員應(yīng)該關(guān)注的七個(gè)開源項(xiàng)目
