关于大型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/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应用程序的架构。

Tier/N Tier架构对于大型ASP.NET应用来说是必须的。它的每一Tier排都由若干服务器组成。只有这样才可以服务众多的用户。如上面的图所示，UI调用商务逻辑时得跨越机器的边界，调用另外一台服务器上的商务逻辑服务接口。

结束语

架构的选择需要根据不同架构的特点和应用程序的需求来进行选择，有时候需要用多个架构的组合才足以满足一个复杂应用的需求。设计者需要根据实际情况来决定合适的架构选择。

接下来将展开谈谈3 Tier/N Tier架构......

第二篇：asp.net系统时间-ASP.NET校友录系统.

asp.net 系统时间-ASP.NET校友录系统

前言

Internet已经成为人们生活、工作、学习越来越离不开的平台脚丫论文网Web技术已经不在局限于单纯地提供信息服务，代写论文而是日益成为1个操作平台，为用户提供强大的服务功能。例如网上电子商务、社会信息数据库等。网络实现了远程通讯，人们能够通过计算机网络进行电子邮件的发送，召开网络会议，网上购物，甚至坐在家里就可以上大学（网上教育）。网络有巨大的潜力待我们去开发与探索。因此，基于B/S体系架构创建这个校友网站，紧跟行业发展，满足人们生活、学习的需要。

校友录名为“校友录”或者“同学录”，其实不只是局限于同学这个圈子，朋友、同学、同事、老师与亲人等等都可以。它的目标受众是组织，只要是1个社会组织或者群体，不管大小都可以在网上申请1个校友录。用户人群的范围扩大到学生、同事、企业、家庭、军队、企事业单位的部门等等。因为每1个人都从属于1定的组织或团体，所以每1位网民都有成为校友录用户的可能。这就为在校或已毕业的广大校友们提供1份交流思想的场所，通过提供完善的校友录服务和规范校友录的管理，建立起校友间的沟通渠道，以达到增进校友之间、校友与母校之间的感情，方便校友联系的目的，从而增强学校的凝聚力。

只要加入了班级或者某1团体的校友录，且你已经被批准成为这个校友录团体中的1员，你就可以享受着传者和受者的基本等同待遇。在校友录内部，传者和受者是没有界限的，在信息交流的过程中，传者和受者的角色是互换的，用户既是传者又是受者，在信息发布和接受方面是对等的，都可以自由地发表言论、上传图片、班级聊天等等交流活动。也可以通过此网站与朋友联系，并且还能够创建学校和班级等功能。系统中班级管理为必不可少的模块项，主要是为了安全有效地存储和管理登录网站的用户的信息，赋予管理员特定的权限，可以对用户进行分类，添加，删除，修改等，方便网站的管理与维护。

第三篇：系统架构设计师岗位职责

1.负责相关产品的架构设计工作，以及产品间的接口设计及管理。

2.负责指导产品的高层设计，参与重要或高风险模块的设计，控制高层设计的质量。

3.负责或参与公司外部和内部技术规范的制定。

4.负责向相关组织提供关键技术支持。

5.负责在公司内部进行组织领域内的技术知识传递。

6.负责或参与各项研发过程的技术评审工作。

7.与其他部门进行协调、沟通，保证开发与设计相符。

8.负责相关请求的技术分析；负责制订相关的技术解决方案。

9.组织实施技术可行性验证及技术选型工作。

第四篇：系统架构设计师考试心得

系统架构设计师http://

系统架构设计师考试心得

去年参加了系统架构设计师的考试，考试还算比较顺利，顺利通过了国家分数线，获得了资格证书。除去考试不说，在准备考试的这段时间里了解了一下架构设计的主要工作，和做架构设计的理论知识和一些成熟的架构方案，对自己以后的实际工作有很大的帮助。下面总结一下我的备考经验。

【前期准备】

花了一个月的时间基本就是学习基础知识，其实好多大学的课程都已经学习过了，无奈毕业以后就基本不怎么看书了，忘了很多，不过比起从头来学还是轻松了很多，O(∩_∩)O哈哈~。

参考书籍：

《系统架构设计师考试全程指导》和《系统架构设计师教程》这两本书基础知识基本上涵盖齐全了，后一本书可以粗略看一次，了解一下架构设计师需要的主要背景理论知识，前一本书推荐看两次，第一次算是过一下主要的理论知识点，能记住多少算多少，第二次顺便做一下课后的习题，实际上题目也没几道，每个章节也才不到20道题目，便于加深理解，同时重点记忆一些关键的知识点。

【中期准备】

10月份到11月份这一个月基本上就是熟悉考试的题型，了解一下考试题目是什么样子的，主要考什么，哪些是重点，案例分析题目怎么解答等等。

参考书籍：

《系统架构设计师考试考点突破、案例分析、试题实战一本通》和《系统架构设计师考试历年试题分析与解答》可以看一下历年的考题，相信大家考试也都不少了，最具有参考价值的题目仍旧是历年的真题，虽说系统架构师自从09年

系统架构设计师http://

才开始，但是通过本书试着做一些题目，了解一下历年考过的知识，和简答题目的方法，尤其是下午的案例分析题，难度相对比较高，可以重点学习一下回答这类题目的方法。

【后期准备】

11月份，考试前夕，这段时间主要是知识总结和准备论文方面的工作。架构知识涉及面太广，不可能面面俱到，所有的知识都非常熟悉，必要的背景知识相信通过前段时间的学习，基本也就OK了，现在重点是论文设计了。一来，论文的字数比较多，2个小时的考试时间，写3000字的论文，还要扣除包括审题，概要什么的时间花费，练习练习动手写作能力还是非常重要的。如果提前能练练手的话，相信语言的组织了，字迹的工整程度了，都能提高不少。二来，选择自己在近两年时间内做过的印象最深的一个项目，从项目的整体角度考虑，需求分析了，架构设计了，软件测试了，认为能够以宏观角度概括的，都可以整理一下，这都是用来写作的素材。三来，就是细化自己在项目中所做的工作，不要泛泛而谈，举实例出来，提出解决方案，这就是论文的论据。

其实论文这块，题目本身比较灵活，结合自己的实际项目经验来写，相对来说容易许多，内容也不会显得太空洞。同时可以网上参考一下历年的优秀论文，了解一下开头怎么写，中间内容怎么写，结尾怎么写，使文章读起来整体有一气呵成的感觉，免得写的不着边际，跑题了。

【总结】

总的来说，基础知识还是要花大工夫的，毕竟涉及的知识面比较广泛，操作系统了，网络了，数据库了，信息系统了，软件架构设计了，知识产权了等等。有些是了解的，有些是要重点掌握的，在复习基础知识的时候可以归类记忆。

系统架构设计师http://

再者，要多了解一下当前互联网产业的热门技术，毕竟做架构设计工作也是与时俱进的，现在都有好多的成熟架构解决方案，平时多了解和积累一些。

最后，也最重要，在实际的项目中把所积累的知识运用一下，不仅对自己做设计工作有好处，同时对考试来说，案例分析和论文设计也就比较容易上手了，不然的话，那就真是纸上谈兵了。考试的时候无从下手，不容易答题。

这算是自己考架构设计师的一点心得体会，难免有不足之处，相信大家只要认真准备了，考试还是比较容易过的，重要的是自己在工作中做架构设计的时候也能得心应手，灵活做设计，最后也预祝大家都能考个好成绩！！

第五篇：系统架构设计师的主要职责

系统架构设计师的主要职责

职责：

1)

业务需求系统分析，提出技术研究及可行性报告;

2)

结合需求设计高扩展性、高性能、安全、稳定、可靠的应用系统

;

3)

可以通过配置实现业务需求的变化，跟踪并研究___并应用于产品

;

4)

指导研发工程师的产品开发和技术研究工作，解决各类技术疑难问题，形成良好的研发氛围，提升团队整体技术水平。

5)

管理与指导研发团队，负责产品研发计划制定与执行;

任职要求：

1)

___年以上Java开发经验，___年以上架构设计经验;

2)

能对分布式常用技术进行合理应用，解决问题;

3)

精通网络编程，熟悉HTTP，TCP/IP协议;

4)

对数据库的基本理论和内部实现机制有深刻的理解，能够熟练应用MySQL/NoSQL数据库，有实际大数据量的数据库设计经验;

5)

熟悉缓存技术，网站优化，服务器优化，集群技术处理、网站负载均衡、系统性能调优等软件编程高级技术;

6)

良好的逻辑思维能力，熟悉业务抽象和数据模型设计，具有很强的分析问题和解决问题的能力。

7)

有大型互联网项目(作为技术总负责或核心领域负责人)的架构设计和技术管理的成功经验。在相关公司担任过___人以上开发团队技术主管者优先。

系统架构设计师的主要职责2

职责：

1、负责公司产品数据库的规划、建模、设计和管理，数据库相关模块的设计研发工作;

2、按进度计划要求准时完成开发任务，及时编制程序开发文档，制定数据库监控策略,备份策略,容灾策略;

3、数据库日常监控、维护、备份和恢复;探查系统潜在的问题和可能的性能瓶颈,并进行优化;

4、制定数据库技术方案，分库分表策略，数据迁移方案，SQL优化

;

任职资格：

1、计算机、电子工程、机械、通信等理工科相关专业;

2、大专以上学历，条件优秀者可以适当放宽;

3、对从事软件开发等相关工作具有浓厚兴趣;

4、善于沟通和协调，具有高度团队合作精神;主动学习新知识的能力;具有高度的敬业精神、创新精神和开拓意识;精力充沛，能够承受较大的工作压力;

系统架构设计师的主要职责3

职责：

1、负责质量管控系统后台架构开发、优化、重构

2、参与各分站检测软件开发、设计、优化及升级

3、参与项目管理、进行业务需求分析、需求细化、功能落实、系统架构、模块建模、数据库设计

4、与部门人员进行必要的技术分享、统一目前公司软件开发架构

要求：

1、三年以上及具有大数据设计、系统架构相关经验

2、精通C#，熟悉

MVC

或

ASP.NET

进行Web开发

3、精通SQL

数据库

系统架构设计师的主要职责4

职责：

1、负责公司产品设计、研发、实施、管理;

2、负责公司产品关键技术架构的制定和相关新技术的研究工作;

3、负责带领团队实现产品目标，保障公司产品开发、上线、维护及其他项目高质量顺利执行;

4、负责团队的管理，重大技术决策和技术方案的制定，并培养提升整个团队的质量技能;

5、负责整体产品技术队伍建设，做好人员配置与协调，有效地监控项目进展，对员工进行考核、培训;

6、紧密配合公司的业务发展，组织团队完成技术任务;

7、带领团队进行技术语言和技术难点攻关。

任职要求：

1、大专以上学历，计算机相关专业;

2、三年以上知名互联网行业工作经验(ERP或管理软件)领域，___年以上工作经验，带领研发团队;

3、有大型产品的设计和开发经验，具备优秀的编程能力、管理能力，对计算机语言有十分深入的了解;

4、精通智慧警务业务系统的架构设计、系统分析、软件实现、性能优化及系统安全;

5、对AI技术有深刻理解和实现能力，有丰富的项目管理经验、产品研发经验;

6、具备敏锐准确的洞察力和缜密的逻辑思维、能够把握行业业务发展动向和关键技术发展趋势;

7、具备良好合作态度及团队精神，富有工作激情、创造力和责任感;

系统架构设计师的主要职责5

职责：

1.作为大数据平台架构师，负责规划设计大数据基础平台及研究相关技术;

2.负责海量数据采集、处理及存储、应用方案的技术选型及架构实现;

3.负责海量数据分析/查询、分布式存储、流式/实时计算等应用层架构搭建及核心代码实现;

4.负责大数据技术应用的技术难点攻关、技术发展研究。

任职要求：

___本科及以上学历，数学或计算机相关专业毕业，具有扎实的计算机基础理论知识;

2.计算机领域五年以上工作经验，___年以上hadoop项目设计及研发经验;

3.熟悉hive、hbase、storm、mahout、flume、ElasticSearch、Spark、Kafka等，具备实际项目设计或开发经验;

4.熟悉大规模数据挖掘、机器学习、自然语言处理、分布式计算中一项或多项技术，并具备多年的实际工作经验;

5.熟悉主流关系型数据库(Oracle、MySql)、NoSql数据库，熟悉pl/sql编程;

___对技术充满热情且具有钻研精神，对新技术以及行业动向保持敏感性;

7.具有较强的执行力，高度的责任感、很强的学习、沟通能力，能够在高压下高效工作;

8.有物流、快递、电子商务行业经验者优先。