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

博客園有不少同仁在寫系統架構或者企業應用架構方面的文章，我看過其中一些。就我看過的這些文章，我發現他們當中相當多的人寫的是分層架構。從我的看法來說，分層是不錯。但是假如是我自己寫的話，我會從架構的選擇來說起。那么應用程序的架構就有可能不選擇分層的架構，而選擇其他架構。另外我會從整個系統的角度來寫，即從硬件和軟件兩個角度來思考一個系統。

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

簡介

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

架構的選擇

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

基于組件的架構

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

分層Layered的架構

應用被劃分成了堆疊在一路的若干層，每一層完成特定的服務和功能，與其上下層接口，各層之間是調用被調用的關系。在上面的層只有調用下面的一層，在中心的層則兼有調用和被調用。在下面的層則是僅供上面的層調用。通常劃分成UI層，商務邏輯層，數據層等，并且通常多個層都部署在統一臺服務器上。

新聞總線型的架構

應用程序按照預定義的格式來收發新聞。有一個新聞隊列和新聞存儲，分發處理的義務。相關新聞的事件被程序處理。支撐不同的系統平臺。新聞總線里面有若干定義好的新聞流，新聞總線同各系統平臺交換數據，支撐不同的格式。將新聞交由不同的處理程序處理。