关于大型asp.net应用系统的架构-架构的选择

几年在.net方面的工作经历，让我长久以来(有几年了)想写关于大型asp.net应用系统架构文章的念头。之前和同事们聊天的时候说的都是一些思维片段，其中的想法不尽完美，聊完天再细心想想，一些主意就逐渐清晰了。现在终于付诸行动了，将一些想到的主意与大家一路探讨，也算是对曩昔几年在ASP.NET方面的一个总结。这对我来说也是一个学习过程。

博客园有不少同仁在写系统架构或者企业应用架构方面的文章，我看过其中一些。就我看过的这些文章，我发现他们当中相当多的人写的是分层架构。从我的看法来说，分层是不错。但是假如是我自己写的话，我会从架构的选择来说起。那么应用程序的架构就有可能不选择分层的架构，而选择其他架构。另外我会从整个系统的角度来写，即从硬件和软件两个角度来思考一个系统。

这些都是我的一些建议，希望对您有所帮助。

简介

大型asp.net应用要考虑如何服务众多的访问者，同时还要保证每个访问者都获得高质量的服务。需要面对不同语言的用户；需要保证安全性；应用系统的伸缩性也是很强的，当服务器集群有点不足以担负压力时，可以向服务器集群中加入更多的服务器来增添整个应用系统的服务能力。服务器的可用性也会要求很高，一年的下线时间是很少的。服务器的灾难备份也是很好的，即使现在的机房遭受毁灭性袭击，也有灾难备份可以恢复服务。服务器上跑的asp.net应用是可扩展的，具有很好的可扩展性，同时具有的可维护性。本系列文章将谈谈大型asp.net应用系统架构的诸多方面。本篇将谈到架构的选择。

架构的选择

架构的选择与应用程序的类型有关。这里说的是asp.net应用，那么Client-Server的架构就很显然排除了。剩下：

基于组件的架构

应用可以按组件划分，不用组件实现不同功能和逻辑，组件之间的接口规范有很好的定义。某些组件可以重用。

分层Layered的架构

应用被划分成了堆叠在一路的若干层，每一层完成特定的服务和功能，与其上下层接口，各层之间是调用被调用的关系。在上面的层只有调用下面的一层，在中心的层则兼有调用和被调用。在下面的层则是仅供上面的层调用。通常划分成UI层，商务逻辑层，数据层等，并且通常多个层都部署在统一台服务器上。

新闻总线型的架构

应用程序按照预定义的格式来收发新闻。有一个新闻队列和新闻存储，分发处理的义务。相关新闻的事件被程序处理。支撑不同的系统平台。新闻总线里面有若干定义好的新闻流，新闻总线同各系统平台交换数据，支撑不同的格式。将新闻交由不同的处理程序处理。