系统架构师高级学习资料汇总.docx
《系统架构师高级学习资料汇总.docx》由会员分享,可在线阅读,更多相关《系统架构师高级学习资料汇总.docx(85页珍藏版)》请在冰豆网上搜索。
系统架构师高级学习资料汇总
.Net下企业应用系统架构构建心得
在开始架构设计之前,需要了解一下架构是什么,按照IEEE标准的定义是:
Architecture是一个系统的基本组织,它蕴含于系统的组件中、组件之间的相互关系中、组件与环境的相互关系中、以及呈现于其设计和演进的原则中。
(Theembodiedfundamentalorganizationofasysteminitscomponents,theirrelationshipstoeachother,andtotheenvironment,andtheprinciplesguidingitsdesignandevolution.[IEEEStd1471-2000])
一句话,架构就是软件产品的骨架,这个骨架把组件、环境纳入其中,使之能有效得发挥它们的技能。
从架构、技术和需求的关系来看。
一个软件产品包含了需求和技术,而架构同样是要包括需求和技术的,只是它没有全包全括这个需求和技术,应该是一些整体性的需求,尤其是一些非功能性的需求。
如果在构建架构的时候,架构设计人员根本不了解企业使用的目标软件的整体需求,企业使用目标系统的整体环境,那指望架构适用显然有点强求。
架构的重要性是不言自明的:
l)从需求、技术和架构的关系看,架构是软件产品的骨架
2)从软件过程上看,架构处在需求即将完成,实现开始之前,是一个承上启下的关键点
3)从技术上来看,架构是整体设计,包含了软件需要用到的各项技术
4)架构决定开发过程,方法和工具,这一点都不夸张,架构决定了软件的规模,技术。
很自然就觉得了资源的需求以及如何配置这些资源来进行开发
5)架构影响软件产品的成本,包括开发成本,测试,实施和维护成本架构实际上是软件的一部分,同样都需要遵循软件设计中要考虑的设计原则。
但是,架构由于是前期设计,整体设计,又具有其需要强调的地方:
6)明确目标,切合需求(实用决定一切)
7)可扩展性
8)易用性和易维护性平衡艺术,易用性就要求系统不能过于负杂,而易维护性就要求可扩展性和灵活性,就要求系统不能太过简单,这就要权衡这两个性能方面的考虑。
9)安全性,架构的安全并不是说把架构的代码放到一个地方加密,是在架构设计中考虑软件的安全性能,这个在先期考虑是相对重要的。
l0)稳健性,架构设计时需要纳入考虑的要素有:
l1)ApplicationInfrastructure,应用的基础架构,也可以说是架构是建立在什么平台上的,比如windows2003+.Netframework1.1,当然并不是就这么简单,下面会有具体的讲解。
l2)Management,架构设计中要考虑用户对软件的管理方面的考虑,比如用户对性能监控的要求,用户要对软件执行各个环节的执行效率统计等等。
l3)Security,安全性是在什么地方都要考虑的,不光是软件开发。
l4)Storage,存储,面对一个企业级的应用而言,对存储的要求是要特别注意的。
l5)Network,网络拓扑结构,以及企业对网络的要求层级,数据传输要求等等。
在了解了软件架构的这些本本上的东西,那么我们来搭个应用看看。
以我碰到的项目为例,当然一些技术是可通用的,但这个是一个个案,不代表适用您的项目,只求交流。
先交待一下,假设:
1.系统是建立在微软的架构基础上的,MicrosoftSystemArchitecture(MSA)
2.它是一个B/S的N-Tier架构
3.同时它是一个企业级应用系统,信息平台
在考虑使用N-Tier的过程中,由于系统中没有涉及到要使用跨平台的应用,在可预见的将来也不会有,所以就把WebService拿掉了。
WebService从3年前就开始用,但是几个问题还是没有解决:
1.WebService从接口继承,如果两个或者两个以上的Webservice同时从相同的接口继承,由于WebService的自描述性,每个WebService都重新生成接类,就成了两个不同的类。
2.WebService本身不能被继承,同样由自描述性搞的。
3.WebService要真正做到跨平台那就需要做到跨语言,从Java到C#的转化时数据类型转化是相当麻烦的,基本类型之间就有很大问题,如byte,sbyte(C#)中,当Java中根本就没有sbyte。
早在一年半前曾用相异平台做了一个应用系统,为了处理这个数据类型转化,我曾想去掉WebService。
4.WebService方法不能重载,这个很恐怖。
5.WebService的安全问题。
尽管WebService有其种种好处,连现在的网格都开始醉心于它,更不用说SOA了,本身就是以WebService为核心展开的。
但是,WebService到底能走向哪里?
在开始架构设计之前,需要了解一下架构是什么,按照IEEE标准的定义是:
Architecture是一个系统的基本组织,它蕴含于系统的组件中、组件之间的相互关系中、组件与环境的相互关系中、以及呈现于其设计和演进的原则中。
(Theembodiedfundamentalorganizationofasysteminitscomponents,theirrelationshipstoeachother,andtotheenvironment,andtheprinciplesguidingitsdesignandevolution.[IEEEStd1471-2000])
一句话,架构就是软件产品的骨架,这个骨架把组件、环境纳入其中,使之能有效得发挥它们的技能。
从架构、技术和需求的关系来看。
一个软件产品包含了需求和技术,而架构同样是要包括需求和技术的,只是它没有全包全括这个需求和技术,应该是一些整体性的需求,尤其是一些非功能性的需求。
如果在构建架构的时候,架构设计人员根本不了解企业使用的目标软件的整体需求,企业使用目标系统的整体环境,那指望架构适用显然有点强求。
具体的了解一下这个层的关系,以及构建架构时上文提到的需要涉及到的问题。
1.PresentationTier
表示层分层两层,UIComponents可以直接看作是HTML,UIProcess这里不是MVC,而是code-behind类。
在表示层,就我所碰到需要处理的问题有:
l)MVC(Model-Views-Controller)
A下是否需要使用MVC一直是一个有争议的问题。
A的特点是事件驱动与Code-behind,Code-behind本身就可以理解是MVC中的Controller,但是没有体现MVC的好处来,微软缺乏双向赋值的考虑。
UIP(UserInterfaceProcessApplicationBlock)是微软社区里的一个开源项目。
严格说来它只是一个管页面流转,不是一个MVC的框架。
M是一个比较轻量级的框架,简单实现了MVC,但是也有其缺陷,而且比较老了。
还有Castle的框架,Spring还没有完整推出。
2)国际化
如果是一个多语言的企业应用,那就需要国际化支持,.Net提供了很好的国际化支持。
3)页面元素格式统一转化与验证
比如日期形式从“yyyy-mm-dd”需要转化成“yyyy/mm/dd”,如果没有一个统一配置的地方,那页面就要伤筋动骨了。
4)安全,在后面的安全节有介绍,这里先按下不提
2.WebService
这里不再说了,已经去掉了。
3.BusinessTier
Business层是应用系统的核心,包括体现用户的商业运算逻辑的BusinessLogic;还有保障BusinessLogic运算安全和完整性的事务,日志,安全验证,性能管理等辅助逻辑。
在设计BusinessTier的时候要考虑的问题有:
l)可扩展性
i.将接口进行到底
在Business实现层之上,建议抽出一个接口层,遵循一般原则提倡接口编程,BusinessComponents都从一个或者一个以上接口继承,在调用代码中调用类工厂产生实例,在代用代码中建议不要使用此类的new操作符。
ii.设计模式的应用
适当应用模式,可以增加程序的灵活性,可扩展性。
(在设计中经常用到Factory,Adapter,Singleton,Decorate,Command,Template等模式,建议可以重点了解一下这些模式。
有时间可以详读GOF的设计模式)Example:
从Business结构,划分为CRUD(增查改删,称为“四架马车”)和其它具体业务实现的Components,这里用Decorate模式,简单实现一个继承的过程,如果你要继承两个基类,可以考虑使用此模式,当然,即使不继承基类,用Interface+Adapter同样可以实现多继承。
2)区分业务逻辑
所谓区分业务逻辑实际上在上面的描述中已有提及,大致上可以分为两类,一类是商业业务逻辑,一类则是软件功能性逻辑,起辅助保障上述逻辑用,如事务,日志,安全验证等。
第二类的使用频率高,实现又是非常类同的,如果提取出来,那复用价值是很高的。
这种区分早有定义,把抽出来的部分称之为CrossCut或者叫Aspect。
这个就是AOP在事务,日志,安全验证方面的应用。
先来看一下CrossCut(Aspect)的结构表示图:
3)MS组件、服务的是应用
这里的服务和组件主要是讲是在Applicationinfrastructure中的元素,如COM+,MSMQ,IIS,AD等等。
这里常用到的两种COM+和MSMQ。
i.COM+
如果应用系统需要使用分布式事务,或者的确希望把组件编程一个服务,那么就可以使用COM+,当然这也造成部署的不方便。
ii.MSMQ
消息队列,主要使用于异步处理。
比如,在业务处理过程中要发一封邮件,如果采用消息队列来做,不管当前的邮件服务忙,还是根本就不能工作,用户可以转回来处理其它业务而不必等待。
4.DataAccessTier
数据访问层,是用来隔离系统访问不同的数据媒体或者系统外服务(比如,其它系统的WebService等)用的。
l)将接口进行到底
2)or-Mapping,ORMapping所带来的好处这里就不多说了。
我们先来谈一下下面的几个概念。
i.DomainModel&TableModule
根据MartinFlower的定义DomainModel:
Anobjectmodelofthedomainthatincorporatesbothbehavioranddata.
-RichDomainModel:
是上面的这种定义
-AnemicDomainModel:
这种方式方法和Data是分别在不同的类里实现的,OR-Mapping就是建立在这种方式上的。
ii.NHibernate
NHibernate是OR-Mapping的一种实现,是一个比较齐整的框架,是从Java的Hibernate转过来的。
当然.Net下还有其它的OR-Mapping实现,如G
iii.SqlMapper&IBatis.Net
SqlMapper为DomainModel和TableModule两种方式一个折中方案,它可以以面向对象的方式直接处理自定义数据实体对象,同时可以根据与数据源与业务实体的映射关系执行手写的Sql语句,这样完全使得我们可以针对具体数据源做优化,对于复杂操作同样可以胜任。
IBatis.Net是SqlMapper的实现。
3)or-Mapping与复杂查询的问题
OR-Mapping带来的好处是在CU,D方面还可以,毕竟大批量的删除一般不会经常出现,但是R方面就是一个实实在在的问题,面对复杂查询的执行效率也是一个问题。
蹩脚的解决方案是两条线,R这方面采用TableModule这种方式来,而CUD才用对象。
5.CommomTier
是系统性能、检测、跟踪用的,有些可以采用AOP来解决,如计数等。
三.企业级应用
企业级应用一般的特点是数据量大,交互操作要求高,在线用户量比较大,用户地理分布较广。
这就要求我们在设计架构是要考虑其安全性,数据存储要求,集群,与其它应用交互。
l)安全性
安全性是一个多角度多方位的立体式问题,应用体统的安全性,是与其它安全性一起才构建起来。
一般安全分成几个层级:
1.网络安全性
-网络服务的安全,如http,ftp,mail
2.操作系统安全性
-访问控制表(ACL)安全控制,主要通过组、用户权限控制完成
-网络访问安全控制,在域模式下
3.数据安全性
-数据库系统安全
-数据访问权限安全
-数据加密
-数据备份
4.应用系统安全性
-A的安全性
-安全通信
对于上面列举的一些安全层次,有些是在系统的使用过程中要注意的问题,并非在架构设计时能做到的,但是,可以做为输入项来构建一套安全的系统。
下面主要来讲一下如何用A来构建安全的系统。
1.A安全性
-ASP.NET身份验证,包括Windows、表单、Passport和无身份验证
-ASP.NET授权,包括URL授权、文件授权、主体权限需求和.NET角色
-标识和主体,主要是通过编程方式来进行(标识和主体对象必须实现IIdentity和IPrincipal接口。
这些接口在System.Security.Principal名称空间内定义)
2.在采用windows验证时,A可以在IIS上配置一些安全选项。
3.安全通信
-Internet协议安全(IPsec)
IPSec提供传输级安全通信解决方案,可以用于保护两台计算机之间传送的数据安全。
VPN也是在这个协议基础上构建的。
-安全套接字(SSL)
这通常用于保护浏览器和Web服务器之间的通道安全。
结合IIS和证书,就可以配置https协议使用。
-远程调用(RPC)加密
分布式COM(DCOM)使用的RPC协议提供了一个身份验证级别(数据包保密性),它对客户端和服务器之间传送的每个数据包都进行加密。
2)存储
企业级应用级的存储特点是I/O访问要求高,数据容错性要求高。
所以,就有可能使用比较高端的存储设备以满足存储要求,硬件不是软件系统架构的内容,但是Raid等使用却是软件架构必需考虑的。
3)集群
同存储要求一样,对于一个大型的应用来说,大访问量,分布式数据应用,就可能需要使用集群。
对于分布式数据库的需要使用数据库集群,可采用数据库系统本身得到解决。
对于分布式部署需要应用服务器集群,这在代码实现上就要先期考虑到Session在分布式部署环境下的同步问题。
4)与其它应用交互
在设计架构时,还要考虑与其它系统的交互。
1.使用其它系统的接口
2.与原有系统的整合
3.开放接口,供其它系统使用
2009年软件架构师必须了解的十个新领域
在云计算、社会化媒体等新技术风起云涌之下,软件架构将往何处去?
著名的Web2.0观察家DionHichcliffe认为,2009年将是软件架构的大变革之年。
传统的n层架构、SOA、编译型语言、关系型数据库等等都将在2009年开始向新的替代品转换。
也许,喜欢2.0这个字眼的Dion心里实际上是在想说软件架构2.0了吧。
他的blog列出了十个软件架构师必须了解的新领域:
云计算(比如AmazonEC2)
非关系型数据库(比如CouchDB,AmazonSimpleDB)
下一代分布式计算(Hadoop)
面向Web的架构(WOA)
Mashup(混搭)
开放API(【按】原文是OpenSupplyChainsviaAPIs)
动态语言(【按】还包括了Erlang?
)
社会化计算
群众外包(Crowdsourcing)与用户制作(【按】)
新的应用模型(【按】似指Widget、Gadget这些)
虽然这篇文章在TheServerSide上很被实干的程序员和技术人员们嘲笑了一番,但我倒是认为,如果能多了解一些这种比较宏观的前瞻,结合自己的实际思考一下,是非常有益的。
当年我的同行O'Reilly出版公司(现在已经改名媒体公司了)的老板TimO'Reilly最早创造Web2.0这个名词的时候,还不是有很多人骂他空谈?
可是如今呢,从Web开始,2.0已经席卷社会各个层面,政府2.0、企业2.0甚至教育2.0都已经有人提出来了。
软件架构2.0?
我看很多方面变成主流,将是迟早的事情。
2010年下半年系统架构设计师考试试题分析
本次考试是系统架构设计师开考以来的第2次考试,从形式上来看,系统架构设计师的考试风格已趋于稳定。
这表现在上午考试各科目知识点分布稳定。
案例分析维持1道必答题+4选2模式,论文维持4选1模式。
1.信息系统综合知识试题
在本次考试中,值得特别注意的是:
在嵌入式系统部分,开始考查到硬件基础的一些知识点,这是在考纲中没有做要求的部分,已超纲。
但依据软考的传统出题风格,这属于正常现象。
2.案例分析与设计试题
试题一
试题一仍然为必答题。
本题是一道架构设计方面的试题,考查的内容是常见架构风格的选用。
问题1考查架构风格的基本概念与主程序-子程序、管道-过滤器的特点。
这一空属于送分题,难度较低。
问题2考查主程序-子程序和管道-过滤器优缺点对比。
这两种风格的优缺点包括多个方向的很多内容,但要应对该题,并不需要我们面面俱到的把每一个细节记清楚。
只要了解两者的核心思想即可。
具体的优缺点可以看《软件体系结构原理、方法与实践》(张友生,清华大学出版社)。
问题3是补充架构设计示意图。
其实这个图要表现出来的,无非就是利用管道-过滤器架构,需要处理的信息的操作有哪些,按什么顺序排列。
试题二
试题二为一道软件系统数据架构建模的问题。
实际上是考的分布式数据库。
问题1考查数据架构的基本思想,也就是要说明集成式数据库与分布式数据库的优缺点。
问题2考查分布式数据库的设计。
其中涉及到单点故障的概念,单点故障是指系统中由于某一处的故障,导致整个系统不能正常运行(注意:
并不是系统的每一处出错,都会影响到整体故障的,有时只是局部功能的丧失)。
例如平时我们局域网中的交换机出现故障,就会导致整个局域网无法通信,这就是一个单点故障。
在进行设计时,单点故障的识别,就是看这一点出错,会不会导致全局问题。
然后针对此处进行相应的改进措施,如做局部热备之类的。
问题3考查考生的实际设计经验,可扩展性是设计任何系统时需要考虑的一个因素。
试题三
试题三为一道嵌入式系统的试题。
嵌入式的试题通常都是大段的题干说明加多个图表,在有限的时间下,很少有人选该方面的试题,因为看完试题就要花费不少的时间,所以嵌入式的试题一般只有本身是做嵌入式相关开发的考生在选答。
本题以汽车电子基础软件开发为背景。
问题1中给出了两种开发流程,要求考生指出更为合理的,其实选择的依据已经列在问题中了,即“尽量满足并发、可多次迭代的特性”。
问题2需要从层次化的上下层调用关系来答题。
问题3要求考生有相关的应用经验。
试题四
试题四为一道系统设计与开发工具集成的问题。
其中涉及到ESB的功能特点以及设计模式的相关知识。
ESB是SOA的一种实现方式,目前SOA作为一企业应用集成的架构,越来越受人们的关注,所以也是系统架构设计师与系统分析师考查的一个热点。
本题中,第1问要求考生说明ESB的主要功能,同时要结合题目给出的信息说明为什么选用ESB架构,这实际上就是让考生分析ESB的优缺点。
第2问涉及到集成中具体的一些问题解决,这其实是我们在进行架构设计或系统集成时经常采用的方法。
即根据一系列的需求,说明解决方案,再通过对这些解决方案的整合,形成架构,或作为架构评审的一些依据。
第3问考查设计模式,设计模式的级别低于架构模式,用于解决系统中的一些局部设计问题。
关于设计模式,我们需要掌握设计模式的应用场合、作用、结构。
详细内容请参看《系统架构设计师教程(第2版)》(张友生,王勇,电子工业出版社)。
试题五
试题五考查的是系统可靠性问题。
可靠性是软件质量属性中非常重要的一个,无论是进行系统架构设计还是架构评估,它都是一个核心指标。
所以这个知识点也是架构考查的重点,上次考试它以论文题形式出现,本次考试中,案例、论文各有一道是可靠性方向的。
可靠性技术通常包括:
可靠性的计算、检错技术和容错技术,本题中,这三个方面都涉及到了。
问题1要求解释可靠度与失效率,这是纯概念题,难度较低。
问题2要求解释动态冗余和N版本程序设计技术,这两种技术即可用于提高软件的可靠性,也可用于提高软件的可靠性。
至于可靠度计算,我们只需要了解两种最基本的,即串联可靠度计算与并联可靠度计算,然后把两者结合起来,就可以解决串并联混合的复杂可靠度计算。
如本题的第2个计算,就是属于先并后串的模式。
问题3考查检错技术,该技术用于检查系统出错状态,以便采用容错技术来对已发生的错误进行修正,以达到容错的目标。
3.系统架构设计文试题
试题一 论软件的静态演化和动态演化及其应用
本题考查的知识点是软件演化。
一个软件系统开发完毕正式投入使用之后,如果需求发生变化,或者要将该系统移植到另一个环境运行,且新环境的需求也有相应的变化时,就要对软件进行修改,这就是软件演化。
软件演化是一个程序不断调节以满足新的软件需求的过程,也就是对一个已有软件不断进行修改、补充、完善以适用新需求和环境变化的过程。
由于软件演化一词并不多见,所以难倒了很多考生。
其实换一种讲法,可能大家就倍感亲切了--“软件升级”,其实演化的本质就是在升级。
既然是升级,静态演化与动态演化是怎么回事也就好理解了,即升级时是否停止系统的运行。
所以如果有了上面的基础概念理解,写该论文的方向也就明晰了。
试题二 论数据挖掘技术的应用
本题考查数据挖掘技术的应用。
其实从应用的角度,或者从商业的角度来看,数据挖掘这一词在业内出现的频度已不如以前那么高了。
因为数据挖掘通常是不独立进行的,它涉及到数据源的获取问题,即先要建立一个数据仓库,再从中“挖”数据。
这其实就是我们经常看到的是“BI”--商业智能。
商业智能我们可以理解为是:
数据仓库+数据挖掘。
这也就确定了本文的项目背景。
文章最好是把这一层关系讲清楚,写商业智能的项目,如果没有项目经验,直接杜撰出数据挖掘项目来写文章,风险会很高,很容易让人看出文章的“做假”行为。
除此以外,文章可按传统的写法组织内容。
即按问答方式组织文章的主体脉络,并加入项目信息,同时做好承上启下的句子进行段落衔接。
对此,相信希赛教育的学员会有更深的体会。
关于数据挖掘技术的详细内容请参看《系统架构设计师考试全程指导》(张友生,王勇,清华大学出版社)。
试题三 论大规