关于大型asp.net应用系统的架构.docx

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

第一篇：关于大型asp.net应用系统的架构关于大型asp.net应用系统的架构前言最近几年在.net方面的工作经历，让我长久以来(有几年了)想写关于大型asp.net应用系统架构文章的念头。之前和同事们聊天的时候说的都是一些思维片段，其中的想法不尽完善，聊完天再仔细想想，一些主意就逐渐清晰了。现在终于付诸行动了，将一些想到的主意与大家一起探讨，也算是对过去几年在ASP.NET方面的一个总结。这对我来说也是一个学习过程。博客园有不少同仁在写系统架构或者企业应用架构方面的文章，我看过其中一些。就我看过的这些文章，我发现他们当中相当多的人写的是分层架构。从我的看法来说，分层是不错。但是如果是我自己写的话，我会从架构的选择来说起。那么应用程序的架构就有可能不选择分层的架构，而选择其他架构。另外我会从整个系统的角度来写，即从硬件和软件两个角度来思考一个系统。这些都是我的一些建议，希望对您有所帮助。简介大型asp.net应用要考虑如何服务众多的访问者，同时还要保证每个访问者都获得高质量的服务。需要面对不同语言的用户；需要保证安全性；应用系统的伸缩性也是很强的，当服务器集群有点不足以担负压力时，可以向服务器集群中加入更多的服务器来增加整个应用系统的服务能力。服务器的可用性也会要求很高，一年的下线时间是很少的。服务器的灾难备份也是很好的，即使现在的机房遭受毁灭性打击，也有灾难备份可以恢复服务。服务器上跑的asp.net应用是可扩展的，具有很好的可扩展性，同时具有良好的可维护性。本系列文章将谈谈大型asp.net应用系统架构的诸多方面。本篇将谈到架构的选择。架构的选择架构的选择与应用程序的类型有关。这里说的是asp.net应用，那么Client-Server的架构就很显然排除了。剩下：基于组件的架构应用可以按组件划分，不用组件实现不同功能和逻辑，组件之间的接口规范有很好的定义。某些组件可以重用。分层Layered的架构应用被划分成了堆叠在一起的若干层，每一层完成特定的服务和功能，与其上下层接口，各层之间是调用被调用的关系。在最上面的层只有调用下面的一层，在中间的层则兼有调用和被调用。在最下面的层则是仅供上面的层调用。通常划分成UI层，商务逻辑层，数据层等，并且通常多个层都部署在同一台服务器上。消息总线型的架构应用程序按照预定义的格式来收发消息。有一个消息队列和消息存储，分发处理的任务。相关消息的事件被程序处理。支持不同的系统平台。消息总线里面有若干定义好的消息流，消息总线同各系统平台交换数据，支持不同的格式。将消息交由不同的处理程序处理。Model,View,Controller(MVC)架构用户交互的处理与UI显示分离用户交互的处理和UI显示与数据分离3Tier/NTier的架构Tier可以译成排。以与Layer(层)有所区别。将应用程序划分成一系列的服务，包括UI,Business(商业逻辑),数据等服务。各Tier可部署在不同的服务器上。类似于分层(layer)的架构。通常分层(layer)不跨机器的边界，也即所有层(layer)都部署在一台服务器上。Tier是要跨机器的边界。各Tier之间用预定义的通信协议来通信，如WCF,Webservice,或者TCP/IP等。分层(layer)的各层(layer)之间的通信都是通过该编程语言的引用和调用来实现的。所以是有区别的。面向对象的架构应用可以划分成自给自足的可重用的对象集合，对象包含了数据和行为。各对象之间有消息交互。面向服务的架构应用使用一个功能是通过调用一个服务。在服务提供者和调用者之间有通信合同和消息，通信合同定义了消息的格式和通信的方式。消息则包含通信的内容。面向服务的架构是“请求-响应”的工作模式。应用程序是以一种服务提供的，调用者需要向服务发送预定义好的请求消息，服务才做出响应。这些架构类型都可以用来开发asp.net应用。我们可以从其中选择架构类型的组合来，比如：分层Layered的架构+面向服务的架构。MVC架构+消息总线型架构。具体的选则，取决于应用程序的要求。现在说一下如何选架构：如果有若干现成组件，比如以前系统的ActiveX组件或者.net的组件应用程序足够简单而不需要分层的架构，通过调用这些组件就可完成大部分工作不同语言开发的组件需要结合在一起，如ASP.net需要调用VB写的COM+的组件应用程序需要支持插件技术，可以动态切换组件，例如用.net反射技术实现的插件技术那么我们可以选择基于组件的架构。如果应用程序比较复杂，不同的功能需要不同的层来各司其职，如数据访问，商务逻辑，表现等。有比较复杂的商务逻辑和流程。那么我们可以选择分层的架构。如果有若干已有系统并且这些系统之间有特定的交互需要让一个系统与外部的其他系统交互不同