下载

1下载券

加入VIP
  • 专属下载特权
  • 现金文档折扣购买
  • VIP免费专区
  • 千万文档免费下载

上传资料

关闭

关闭

关闭

封号提示

内容

首页 大型企业信息系统的架构设计

大型企业信息系统的架构设计.pdf

大型企业信息系统的架构设计

泽西
2013-11-29 0人阅读 举报 0 0 暂无简介

简介:本文档为《大型企业信息系统的架构设计pdf》,可适用于IT/计算机领域

 大型企业信息系统的架构设计SDC演讲文字整理 前言  这是我在CSDN SDC 上所做的《大型企业信息系统架构设计》的演讲的文字整理这次演讲内容实际上很多单纯看PPT难以全部了解而我又没有时间写很多篇博客去系统性地介绍我在这方面的观点。好在CSDN对此次讲课内容有录音我就此想出了一个偷懒的办法:把我的演讲内容直接整理成文字除了方便阅读而做一些字面上的调整之外力求保持原样因此有些地方看着并不那么顺畅也不可能像文章那样严谨只求把我当时所讲的内容忠实反映出来供大家参考。 由于平时很忙整理工作做了几页就中断了后来多亏博文视点的编辑卢鸫翔以及其他人接过了这个工作替我做了整理。我最后根据录音做了一遍校对基本上是保持了原貌。现在再看里面的部分内容有些显得太简略由于时间限制没有展开讨论恐怕说的不是那么清楚。还有一些内容根据我的最新研究已经已经有了较大的调整不过为了保持原样也就不进行任何修改了。总之就是分享一下我的观点抛砖引玉吧。 补充:随着看到文档的人越来越多也有了很多和意见其中最主要的一条可能是说这个文档的覆盖面太大因此很多地方并没有认真论述结论未免太直接。因此我需要在这里将背景简单说明一下。由于我好几次答应CSDN进行相关讲座但是最终都由于各种事情没能实现。年底终于有机会因此作为第一次演讲希望将这个领域的相关思考与实践全面描述一下所以内容上务必求全而没有展开论述(毕竟只有小时时间)。未来有机会一定会针对相关主题进行深入讨论无论是讲座、博客还是其他形式。    标题  今天讲的主要内容是“大型企业信息系统的架构设计”从标题来看这个概念主要分为三个部分:第一个是“企业信息系统”我们首先要给这个概念做个界定第二个呢是核心问题也就是我们要做“架构设计”第三呢我们还要强调一下“大型”系统的架构设计看看有什么特殊的地方。内容提要  大型企业信息系统架构设计SDC大型企业信息系统的架构设计年月tendericegmailcomhttp:edgejavaeyecom(blog)http:wwwsoftecturecom(建设中)  今天的主要内容大概分四个部分第一部分就是我刚才说的企业信息系统有什么特点要简单介绍一下。中间两个部分大致是讲一下架构设计的内容包括一些方法论的介绍也包括我们简单做一些探索性的工作。最后呢我们回到这个“大”字上就是系统足够大的时候架构设计的要点到底在什么地方。现在互联网的时代来临了大家都知道互联网系统处理的数据量一般都比较大。我们要看一看企业信息系统“大”的时候是不是和互联网系统有共同的特点还是说有可能是完全不同的东西。企业信息系统特点  大型企业信息系统架构设计SDC内容提要企业信息系统特点信息系统架构设计方法论软件架构本质探索大型、复杂系统架构设计要点  好首先讲一下企业信息系统的特点这一部分只有这一张幻灯片。企业信息系统的特点从本质上来讲有两个角度:首先是受限于企业的环境其次是服务于企业的目标。从这两个宏观的角度来讲其实互联网的系统也是一样的:互联网的系统总也要受制于互联网这个环境也要服务于企业在互联网上经营的目标。那么他们的区别在什么地方呢我们来仔细看一下。 首先我们讲企业的外部环境因为环境一般分为外部环境和内部环境说到外部环境呢大家知道这个吧:“PEST分析法”这是企业外部环境的一个重要分析法。这是四个词的缩写:政治、经济、社会和技术也就是political、economical、social和technological。这四个方面呢也就是一个企业在整个社会当中以及在整个国际化的时代当中所面临的外部环境等会儿我会举几个例子和大家说一下。外部环境应该说是对企业十分重要的因为一个企业的发展不可能脱离它所在的外部环境。下面再说内部环境内部环境就是企业本身内部的构成比如说:它的制度、它的人员、它曾经的发展历史以及它现在所拥有的资源等等。这两个环境对于企业来说应该说是决定性的因素既然如此对于企业信息系统而言也是决定性的因素。比如说大家有没有听说过SWOT分析法相信有人知道SWOT分析法是研究企业发展战略的一个重要分析手段实际上就是从企业的外部环境和内部环境两个角度来分析企业的发展战略。 大型企业信息系统架构设计SDC企业信息系统特点受限于企业环境–外部环境:PEST–内部环境:制度、人员、历史、资源…–例子:•敏感词过滤•用户可以用脚投票吗?服务于企业目标–效益、成本、风险、时间、…–例子:•开发活动本身是目标的组成部分•功能的可替代性风险效率成本 等一下都我会讲到那就是对于企业发展有决定性影响的因素当然都是对企业的信息系统有决定性影响的因素。 现在我来举个两个简单的例子:首先互联网的领域内大家可能都知道这个词:“敏感词过滤”。敏感词过滤可能是有一定我们中国特色的东西因为这是受到我们国内政治环境的影响这就是我们所讲的外部环境中的第一个“P”。大家可能会看到敏感词过滤也许是我们中国特色也许西方国家不会有。我想说的是整个互联网的环境在他初创的时候都是很宽松的包括我们国内也一样所以没有敏感词过滤的这个情况。随着互联网发展的越来越快呢类似于敏感词过滤这种情况也就是受到政治因素影响的这种情况会越来越多。而作为企业的信息系统由于很早几十年以来就一直存在和发展因此实际上很早就开始受到政治因素的影响这一点我们后面还会讲到。这个例子中如果我们构造一个搜索引擎大家可能都知道Map‐Reduce这种架构但是如果要一个“带敏感词过滤功能的Map‐Reduce架构”应该怎么做呢?比如说你是在哪一个阶段进行敏感词过滤呢?这里就是想说明实际上包括敏感词过滤这样的政治因素都有可能对你的信息系统的架构产生非常直接的影响这是一个例子。 第二个例子呢不知道大家有没有听说过在互联网上“用户可以用脚投票”。也就是说你的网站、软件做的不好用户的体验不好他就不来用了就去别的网站了。但是我们想一下在一个企业内部的信息系统会发生这种情况么?如果有一个财务软件做的不好企业的会计人员能说我不用这个财务软件我用自己家里拿来一个财务软件来给公司记账么?这是不可能的。那么这说明什么问题呢?我这里是要说明“用户”这个概念对于不同类型的信息系统而言差别是非常大的。对于一个互联网信息系统而言用户实际上属于这个信息系统的外部环境也就是它的社会环境。而对于一个企业信息系统而言用户实际上是企业内部人员这样一个内部环境。所以我们大家应该知道当你建设一个信息系统的时候如果你没有把这些重要的因素搞清楚你连你的用户是内部环境还是外部环境都没有搞清楚的情况下你设计的信息系统肯定会出现很大的偏差。好这些就是我们所讲的受限于企业环境这样一个要素。  下面呢我们是要讲“服务于企业的目标”。我们大家都知道企业建设信息系统无非就是那么几个目的提高效益、降低成本、控制风险等等其实就是这样一些目的。那么我们刚才已经说了互联网的信息系统它建设的目的可能和这个就差别很大比如说我宣传一个概念吸引用户然后我可以拿到VC在创业板上市等等。这个途径和企业建设信息系统的目标差别是非常大的在这种情况下如果我们不足够了解企业建设一个信息系统的目标我们往往会陷入一种唯技术论状况就是把这个系统建设得很漂亮、很完美、实现了我作为架构师或者作为程序开发者自己的目标而没有去贴近企业的目标。 我这里举两个例子首先是对于企业信息系统而言开发活动本身也是这个企业的目标的一个组成部分我想这点大家很容易理解。我们刚才举的例子是说如果我们建立一个互联网的信息系统可能它的投资方并不是很关心你这个系统的团队怎么样建设、怎么样开发、采用的工具是什么、管理流程是什么他只是关心你最后做出来的网站的效果以及你吸引的用户数。但是对于企业来讲因为开发活动对于它的目标产生重要的影响所以他会把开发活动本身也纳入他的效益、成本、风险的考虑当中所以就会对你的开发活动产生非常直接的控制和影响。也就是说他必须管理你的团队是什么样、你采用的开发工具是什么样、你采用的方法是什么、架构是什么。比如有人说(后面我会举个例子)现在ROR很流行两三年、三四年了现在应该说已经足够成熟了那么我想用ROR来开发一个企业信息系统可不可以呢?其实首先你就问一问甲方可不可以就行了如果他不同意你就不要想用了。当然后面我们还会看到还有很多其他因素决定你可不可以用ROR来开发企业信息系统。 第二个例子我想讲一下“功能的可替代性”这一点也是企业信息系统和互联网系统的一个很大的差别。什么叫功能的可替代性呢就是回到我们企业的目标我们建设一个系统无非是为了达到这些个目标。那么这些目标是不是每一个细节都可以用程序这种东西来帮助我们实现呢?通常是不一定的有时候我们会看到有很多的所谓系统的需求或者功能我们要用程序开发出来其困难程度比我们直接定一个规则让人采用手工的方式实现要大得多因为有些工作并不是很适合于用计算机来做的。这些内容如果你不分析出来的话 最后简单来说你会把自己搞死就是因为你一定要拿计算机去做那些不适合用计算机来做的事因为用户会给你提出来说这是我的需求。所以在这方面你必须进行分析有些工作是完全可以用非信息系统的形态来实现的。这对于我们信息系统的整体架构是有非常重要的意义的因为经常你会忽视掉这一点在这种情况下你会由于为了实现一个很难于实现的系统功能而破坏了你整个的系统架构。而实际上这个功能我们把它孤立除去根本不用信息系统来实现这种做法是完全可行的。互联网的信息系统普遍而言不具有这样的特点原因就是因为回到我们刚才说的那一点互联网系统的用户与你之间没有任何直接的联系他们只能通过浏览器通过网络访问你的系统你不可能为他们提供一个不通过你网站系统实现的功能你提供不了但在企业中是可以的。 所以大家看我这一张幻灯片讲的很长(我这一部分只有这一页PPT)就是为了说明影响企业信息系统的这些因素我们需要认识到足够清楚以及他们与互联网信息系统之间有什么区别。这些内容在后面我所要讲的企业信息系统架构设计当中都会有体现。 架构设计方法论概览  下面我简单介绍一下信息系统架构设计的方法论为什么要介绍方法论呢这里就要进入到架构设计领域的特点了。刚才我们说到了要做企业信息系统的架构设计最关键是要理解企业的内部环境和外部环境以及企业的目标。但是从另一方面说架构设计这个领域在这二三十年内越来越成为一个专业的领域。也就是说已经有很多人做了大量的工作构建出了一些架构设计的体系目的就是为了抽象出架构设计这个领域当中(毕竟还是有)很多的客观规律有很多前人经验的总结。孔子说:“学而不思则罔思而不学则殆”刚才我们讲的那些东西实际上是“思”的过程就是让大家反思思考一下企业的信息系统到底有什么特点。但是光想不学是不行的我们还是要看一下别人的方法论在架构设计领域到底抽象出了哪些共性的东西这些东西都应该是我们在架构设计过程中可以用到的。下面简单说一下(这部分不是我讲的重点因为时间也不太够)这五个方法论应该说都是目前比较有名的方法论: DODAF这是美国国防部主导的架构体系MODAF是英国国防部主导的架构体系从名字上也能看出来与DODAF有一定关系从DODAF借鉴了很多东西然后自己进行了一些构造。TOGAF这是OpenGroup的架构体系相当于是一个国际标准化组织的架构体系。Zachman Enterprise Framework这是一位老先生Zachman先生创立的一个架构体系也有二十多年的历史了。中间这个图呢是不知道有多少人了解这个体系熟悉UML、Usecase等等与 大型企业信息系统架构设计SDC架构设计方法论概览DoDAF(DepartmentofDefenseArchitecturalFramework)TOGAF(TheOpenGroupArchitectureFramework)MODAF(MinistryofDefenceArchitecturalFramework)ZACHMANEnterpriseFrameworkTheViewModelofArchitecture RUP相关的体系的人可能会了解得比较多一点。这五个架构体系我想大家可以看出来有两个是国防部的一个是国际组织的一个是个人或者说企业的还有一个是领域专家(Kruchten)的应该说这五个体系还是有一定代表性的。从这里我们就可以看出来很多的人无论是机构、国际组织、公司、个人等等都有自己的架构方法论。这里就是简单介绍一下后面主要对两个架构方法论做一下介绍。 Zachman 企业架构( WH ) 首先是Zachman的企业架构我简单列了一下就是WH。(字体可能比较小大家下来看PPT就可以了)。WH这种模型我想大家都听说过不仅仅是企业架构就是What、Who、Where、When、Why、How等等这样的形态在所有领域的分析模型中都可能会用到。这样的一个体系它的主要特点是什么呢我这里没有时间详细地介绍其中每一个点的内容主要是让大家形成一个印象后面还会用到:这样一个体系的特点是它非常适合于分析非常适合于分析企业信息系统架构的方方面面。这个我想大家应该比较容易理解任何一个领域内这种nWH的方法都是一个非常有效的分析方法 大型企业信息系统架构设计SDCWhatHowWhereWhoWhenWhyScopeListofthingsimportanttotheenterpriseListofprocessestheenterpriseperformsListoflocationswheretheenterpriseoperatesListoforganizationalunitsListofbusinesseventscyclesListofbusinessgoalsstrategiesStrategistsBusinessEntityrelationshipdiagram(includingm:m,nary,attributedrelationships)Businessprocessmodel(physicaldataflowdiagram)Logisticsnetwork(nodesandlinks)Organizationchart,withrolesskillsetssecurityissuesBusinessmasterscheduleBusinessplanExecutiveLeadersSystemDatamodel(convergedentities,fullynormalized)EssentialDataflowdiagramapplicationarchitectureDistributedsystemarchitectureHumaninterfacearchitecture(roles,data,access)Dependencydiagram,entitylifehistory(processstructure)BusinessrulemodelArchitectsTechnologyDataarchitecture(tablesandcolumns)maptolegacydataSystemdesign:structurechart,pseudocodeSystemarchitecture(hardware,softwaretypes)Userinterface(howthesystemwillbehave)securitydesign"Controlflow"diagram(controlstructure)BusinessruledesignEngineersComponentDatadesign(denormalized),physicalstoragedesignDetailedProgramDesignNetworkarchitectureScreens,securityarchitecture(whocanseewhat)TimingdefinitionsRulespecificationinprogramlogicTechniciansOperationsConverteddataExecutableprogramsCommunicationsfacilitiesTrainedpeopleBusinesseventsEnforcedrulesWorkersInventoryProcessNetworkOrganizationTimingMotivationZachman企业架构(WH) 因为用它可以把方方面面的要素都列出来。大家不要忘了我们一开始讲的内容也就是影响企业信息系统架构的重要因素内部环境、外部环境、目标都在这里有体现。 比如说我们看到头一行(纵向的内容我们等会儿再讲):What:List of things你这个企业是做什么的How:List of Processes如何做。比如说一个银行和一个保险公司他们做什么这一点上就肯定是不一样的。进一步而言如何做这又是业务流程方面的问题比如说同样是银行或者同样是政府也没有两个流程完全一样的。Where地理位置比如说我是一家在中关村某一个写字楼上有一个小办公室的公司和我是全国范围内有三万六千个网点的银行他们的信息系统有可能一样么?不可能。Who人员或者角色就是这个企业有多少参与信息系统使用或者建设的人。When时间就是说这个企业的业务以及信息系统有没有比较鲜明的时间特征这个我们可以等会儿再讲。Why就是终极的企业的目标也就是你的企业为什么要做这些事情以及要这么做的原始驱动力是什么。所以这样一些维度就很有利于分析我们前面所说的企业的内部环境、外部环境等等因素和目标。 那么再看纵向纵向实际上是一个层次化的结构就是从宏观一直到微观。Scope是最粗线条的我们看到这六个点都是“List”你只要把要点列出来就可以。再下面就细化了Business业务层面的比如说你有什么样的实体、什么样的业务流程。再往下呢系统层面你的数据模型是什么。再往下是技术层面如何构造这些数据。再往下到组件层面再往下到执行层面。由于纵向是一个层次化的结构横向是一个角度的结构有了这样一个矩阵的结构就可以把企业信息系统的方方面面全都列在这里。这就符合了我们前面所说的你要决定一个企业信息系统的架构的时候必须所要考虑的全部因素都在这里。 顺便强调一点就是反过来说这个框架适合于分析适合于列出所有必要的内容但是并不一定适合于设计。我们可以看到所有的地方都是说企业信息系统应该有什么、有什么但是怎么做没有列出来这是这个框架的特点。  Zachman 企业架构 这里是一个中文版的内容中文不是我翻译的但我看了应该没什么问题。再简单说一句就是Zachman架构有一个网站也就是这个公司的网站这个架构从年开始(演讲中是年应该是记错了)到现在二十多年的历史了。这个公司本身也提供架构师的培训和认证我不是给他们做广告因为我和他们一点关系也没有。我想强调的一点是这个架构经过二十多年的变迁和他最初的时候也是有很大差异了。我这里也就顺便提出来因为前两天也有人问到架构设计到底应该是什么样的规律是不是可以完全形式化。从这个架构体系也可以看出来二十多年来它一直在变可以说最近十几年每年都会推出一个新版本。也就是说架构设计实际上没有绝对的一定之规。大家有兴趣可以去这个网站看一下为什么我要贴这个网站呢我不是要给他做广告是因为这个网站有一个好的地方网站上就有这个矩阵的一个图每一个点都是可以用鼠标点进去的里面会有对相关概念的解释大家可以通过这个形式去简单学习一下看看企业架构设计都要考虑哪些因素。 视图模型  大型企业信息系统架构设计SDCZachman企业架构数据(什么)功能(怎样)网络(哪里)角色(谁)时间(何时)动机(为何)目标范围列出对业务至关重要的元素列出业务执行的流程列出与业务运营有关的地域分布要求列出对业务重要的组织部门列出对业务重要的事件及时间周期列出企业目标、战略业务模型实体关系图(包括M:M关系、Nary关系、归因关系)业务流程模型(物理数据流程图)物流网络(节点和链接)基于角色的组织层次图包括相关技能规定、安全保障问题。业务主进度表业务计划信息系统模型数据模型(聚合体、完全规格化)关键数据流程图、应用架构分布系统架构人机界面架构(角色、数据、入口)相依关系图、数据实体生命历程(流程结构)业务标准模型技术模型数据架构(数据库中的表格列表及属性)、遗产数据图系统设计:结构图、伪代码系统架构(硬件、软件类型)用户界面(系统如何工作)、安全设计“控制流”图(控制结构)业务标准设计详细展现数据设计(反向规格化)、物理存储器设计详细程序设计网络架构屏显、安全机构(不同种类数据源的开放设定)时间、周期定义程序逻辑的角色说明功能系统转化后的数据可执行程序通信设备受训的人员企业业务强制标准http:wwwzachmaninternationalcom 下面一个视图模型。有多少人知道的?这个我们可能不会将的太多。这是PhilippeKruchten发明的搞UML的人可能都知道。视图模型把系统分为个视图LogicalView一般来讲是逻辑视图DevelopmentView是开发视图(程序员、管理者关心怎么开发这个系统)ProcessView是过程视图因为我们在系统当中会关心一些之行流程、性能、稳定性这样一些内容PhysicalView是最终的物理实现包括软硬件包括网络。中间的ScenarioView是贯穿这四个视图最重要的以前叫UseCaseView即通过UseCase这样需求分析的方法。这个理论是通过Scenarios(场景)的分析就可以分析出来逻辑视图、开发视图是怎么样的过程视图和物理视图是什么样的这就是它的一个重要思路。视图模型矩阵形态  大型企业信息系统架构设计SDC视图模型 它也有一个矩阵形态我们看到它横向有五个视图纵向是每个视图中包含的元素。Components是它里边包含的实体Connectors是它们之间的关系和连接Containers是实体的大范畴比如说这些class的归类Stakeholder呢做过UseCase的可能都知道现在普遍翻译成涉众也就是会有哪些人参与其中或者有哪些系统参与其中Concerns就是关注点比如说功能、性能。最后还有一个Toolsupport就是在这样一个视图当中我可以用什么工具进行设计。这个视图我就不仔细讲了还是给大家留一个印象就是跟刚才那个Zachman视图比较起来这样的一个视图很适合于做设计刚才那个模型很适合于做分析。这是因为它把每一个视图中的关键点都列出来了这是它重要的一个价值。因为这两个视图后面我还会一个重要的结合点来讲所以这边短时间先讲到这样大家先留下刚才那两个印象一个是分析一个是设计。不同架构方法论关系  大型企业信息系统架构设计SDC视图模型ViewLogicalProcessDevelopmentPhysicalScenariosComponentsClassTaskModule,SubsystemNodeStep,ScriptsConnectorsassociation,inheritance,containmentRendezvous,Message,broadcast,RPC,etccompilationdependency,“with”clause,“include”Communicationmedium,LAN,WAN,bus,etcContainersClasscategoryProcessSubsystem(library)PhysicalsubsystemWebStakeholdersEnduserSystemdesigner,integratorDeveloper,managerSystemdesignerEnduser,developerConcernsFunctionalityPerformance,availability,SWfaulttolerance,integrityOrganization,reuse,portability,lineofproductScalability,performance,availabilityUnderstandabilityToolsupportRoseUNASSALEDADSApex,SoDAUNAS,OpenviewDADSRose 这个地方我简单地过一下我们知道刚才大家看了五个方法论实际上其中我们只讲了两个。我们知道这些方法论之间应该还是有一定的关系因为我们不可以想象说这个世界上有五个甚至十个架构方法论(实际上十几、二十个至少还是有的)如果它们之间都是完全相互隔绝的任何两个方法论之间都没有相互关系的话那么根据这些不同的方法论设计出的信息系统最后难道完全不是一个东西吗应该不可能。所以说这些架构方法论之间必然是有一定关系的。我们这里简单说一下这是一个DODAF和Zachman方法论的一个映射表从颜色的角度大家可以看到DODAF里面有个主要的view和Zachman之间的个维度有一定的映射关系浅蓝的底色代表它的operationalview黄颜色的底色代表它的systemview。这块就是想和大家简单说一下因为这一节我们就是简单介绍一下架构方法论。当然在这里我和大家分享一个我个人的观点:为什么刚才我没有讲像MODAF这样一个框架?实际上这样一个架构方法论在国际上是非常知名的不过我要跟大家说一句话:“珍惜生命远离国防部”。为什么要这样说因为大家做企业信息系统做多了可能会反思:我们知道像美国国防部实际上它在整个软件开发体系做了很大贡献占有很重要的地位。比如CMM是它和卡耐基·梅隆合作等于它委托卡耐基梅隆来做。MODAF又是它自己设计的像这样一个东西在我们整个的软件开发体系中起着重要的作用但是我要跟大家 大型企业信息系统架构设计SDC不同架构方法论关系(例) 说的是最好大家不要总想去使用美国国防部的这一套东西。因为它所设计出来的东西是具有鲜明的个性的东西简单地来说就是一句话世界上只有一个美国国防部对不对?总不会有两个美国国防部。但是这世界上有多少企业呢?我们要服务于一个领域的企业我们去用世界上只有一个人或者一个客户在使用的架构或者开发模型大家觉得会合适吗?肯定不合适我只能这么跟大家说。这个话就说到这里大家可以自己回去再考虑这个问题。架构方法的确立 刚才我们实际上讲了两个主要的部分一个是企业信息系统的架构信息系统的特点一个是一些架构方法论。我这里想讲的是我们作为一个架构师我们要设计一个企业信息系统最主要的考虑点是哪两个入口:第一我们首先要将影响企业信息系统的各种因素都纳入考虑范畴。我们刚才所说的领域这是最重要的。我们经常这么讲我做银行的信息系统的设计我知道银行这个业务的领域我就是做再多年我的架构功夫再深我换到一个完全不同的领域制药业电力企业真的能够做好架构设计吗?我相信大家都觉得可能性不大至少我告诉大家我认为应该是不可能的。不要以为架构设计真的想那些 大型企业信息系统架构设计SDC架构方法的确立将影响企业信息系统的各种因素纳入考虑范畴–领域(业务)–环境(内部、外部)–目标、动机–时间–…以信息系统自身规律及特点作为依据–数据、功能–逻辑物理–技术体系(JavaEE、NET、…)–开发方法论(敏捷、瀑布、…)–… 方法论那样可以完全的抽象出来作为一个客观的领域这是不可能的。领域还是最终决定架构的根本因素。那么包括环境包括目标、动机、时间、后面都会讲到。再有一个当然就是信息系统的自身规律这也是一个依据。我们大家都知道dijkstra的名言:“算法数据结构=程序设计”。设计系统架构的时候能不考虑数据和功能的架构吗?同样的我们现在越来越多的分层方式决定我们每一点都可有能分为逻辑的架构和物理的架构包括技术体系是JavaEE还是NET…。如果你作为一个有年经验的JavaEE架构师你说我在什么都不考虑的情况下我就可以转为Net的架构师吗?不可以。这就说明技术体系对架构还是有一定决定的因素包括开发的方法论都是一样这一点在后面还会详细地讲到:选择什么样的开发手段对架构设计而言是很重要的。大家可能都会认为说以往我们所宣传的架构都像那些view一样都像是系统一些静态的东西其实不是这样的你设计出的架构再好开发不出来你没有人没有足够水平的人没有足够的方法可以保证你这个架构开发出来也是没用的。我这里多讲两句举一个例子:鸟巢大家都知道架构这个词最早就是从建筑业来的。大家知道吗鸟巢它的每一根梁都是斜的没有直的梁可是我们想一想我们作为一个工人作为一个建筑工人我们平时怎么干活?是不是最主要的就是两种一个就是站着干活一个是躺着干活。站着干活就是上下左右我从左到右系一根条从上到下钉一排钉子。躺着干活是水平面的就是这样。所以鸟巢就面临一个最大的问题它每一根梁都是斜的没有衡平竖直那么工人怎么干活呢?就是因为这一点所以在鸟巢这个图形设计出来之后很多的专家都认为鸟巢做不出来就说这个架构设计本身就不合理:这个不合理的因素完全不来自于它的承重结构和形态而是来自于它没法施工。没法施工的架构当然也就是个不合理的架构。这很明显。但是最终鸟巢还是做出来了为什么?没法施工只是你在某种形态下觉得施工的成本过高而已。我们国家有钱为了搞奥运会什么都可以做最后大家知道吧在电视上看过工人吊一根吊带一个梁是度的人就斜成度不又成了上下左右了吗。所以说实际上一个架构设计它跟你最后能不能做出来是很有关系的。如果我们再突破一点不是鸟巢是什么蚁巢蜂巢也许就真做不出来了。真做不 出来那它就是不合理的。但鸟巢从某种意义上来说还是合理的架构什么样的一个合理架构呢?它是你还能够承担这个开发的成本那它就还是合理的。所以这样就还是回到我们刚才所说的为什么我会强调开发的重要性呢?因为在企业信息系统当中开发活动本身是企业整体活动的一个部分。它也要控制成本也要收回效益和控制风险。所以我们一定要考虑在设计架构的时候(顺便说只能说一句因为我们现在讲互联网信息系统的时候大家普遍都在讲大数据量多处理实际上不是这样而是说在企业当中你有多少钱干多少事。)你设计的架构必须要满足你的目标这就是我讲的架构方法的确立。软件架构本质探索 其实我刚才所讲的那些主要还是在讲企业信息系统的特点介绍了两个方法论主要是为了反映我刚才介绍企业信息系统特点的思路。后面我们将看到这两个方法论怎么用。刚才我说了今天主要讲三个主题已经讲了两个了。信息系统的特点然后架构方法论和架构设计的介绍。中间必须岔开一条道来讲讲我对软件架构本质的探索。为什么要讲这个因为在后面讲到大型的信息系统的时候不可避免的要考虑到一个问题:软件架构的本质是什么?如果 大型企业信息系统架构设计SDC内容提要企业信息系统特点信息系统架构设计方法论软件架构本质探索大型、复杂系统架构设计要点 你不抓住本质的话大型信息系统的设计普遍会出现偏差。引子:WideFinder 我先简单讲个例子我不知道有多少人知道WideFinder这个例子(不知道邓草原有没有在讲scala的时候讲到过?)。其实很简单就是说在一个网站的日志如记录了谁在哪个时候访问了哪个url。这些日志下来每天可能有M?个G个G都有可能取决于你网站访问量的大小。那么你想知道的一件事就是在我这个网站当中哪一个url点击最多。比如在一个新闻网站如果我知道哪个url是点得最多的那我就知道哪条新闻看的人最多。就是这么一个原始的驱动力。那么它的解决是什么呢?WideFinder的原始的解决有一个Ruby的代码大家看右边这段代码从一个大型网站的日志当中找到访问最多的个某种形态的url并且把它倒排序打印出来。我说的这句话就是这段代码实现的功能。我不知道大家对Ruby熟不熟我就不介绍这个内容了我就告诉大家一共行代码还有个空行和个end还有个声明语句也就是说这段代码真正有效的内容也就是这么行。那么这个代码有什么样的好处呢?就是我刚才所说的那句话从一个大型网站的日志当中找到访问最多的个某种 大型企业信息系统架构设计SDC引子:WideFinder问题–找到weblog中topURL解决–代码:Ruby–特性:•代码如此简洁几乎不会出现错误(BeautifulCode)•顺序执行没有明显的架构特征 形态的url并且把它逆序的排列出来。实际上就是这段代码所做的事情。也就是说这段代码和我所描述的我想要达到的目标几乎是一一对应的:对于每一行进行一个判断如果看到它是这个url就对针对这个url的count加。然后做个排序和打印就是这样。它的好处是什么呢?代码如此简洁几乎不会出现什么错误。这就是我们平常所说的BeautifulCode。不知道大家有没有看过BeautifulCode这本书这就是那本书的头一个例子。那么这样一段代码我想大家会同意说它没有什么架构可言从第一句话执行到最后一句话整个代码就结束了。WideFinder(续) 为什么要举这个例子呢?我是为了给大家看另外一个事情。这个实现是Erlang实现的一个版本功能是完全一样的。而且是我们这次的讲师邓草原实现的一个版本。为什么会有这个实现呢?它的一个本质的原因是希望提高分析的速度。因为我有一颗核个线程的cpu我希望能够提高处理这个文本和最后打印出结果的速度所以他就做了这样的一个程序。大家可以看到右边这个程序是Erlang的程序实际上也就是来行而且还包含了很多各种各样的具体算法实现。所以实际“有效”的代码也并不多但它的体系结构是这个样子的:就是说我首先要采用把这个文件分而治之的办法我把这样一个很大 大型企业信息系统架构设计SDCWideFinder(续)Erlang实现(邓草原)–源起:充分利用系统资源(CTCPU)提升处理速度(sn, stLineHead, lastLineEnd)(sn, stLineHead, lastLineEnd)Split to n partsSplit to linesSplit to linesSplit to linesSearch Put countto DictSearch Put countto DictSearch Put countto DictMerge dictsSort  Print result(sn, stLine, lastLine)* may not completeMerge to one line  search 的文件如个G或个G把它切成块然后对每一块进行我刚才所说的搜索url并且把它计数。那所有的这些计数最后还要合并因为是分开执行的合并完了再排序再打印。那么右边这里面还有一个小的异常情况需要处理就是说我们要把文件分块的话它不一定每一块都是整行而我的url搜索是要针对整行来进行的。那怎么办呢?我切成块的话我得把每一块的头和尾上那些半行的东西找个单独的线程把它们拼起来然后再进行搜索然后再跟这里的结果一起进行合并。所以大家看到虽然是这么一个小的程序但它已经明显地体现出了一个架构的特征。大家可以同意这一点吗?我们不能说它是一个架构因为这程序实在太小但是它很明显有个架构的特征。架构分析 好那我们就来分析一下因为我们想要探讨软件架构的本质为什么会有这种情况的发生?首先我们用一个很不精确的分析因为对每一个架构都有很多内容我们没法做到意义分析。我们就借用Zachman的一个方法分析一下产生这个原因的影响和现象。也就是说从一个Ruby的beautiful的代码到这个Erlang的架构的代码产生这个状况的原因是什么?我们刚才说了 大型企业信息系统架构设计SDC架构分析系统WhatHowWhereWhoWhenMotivationBeautifulCode网站日志TopURL日志文本搜索LocalNADaily(?)用合适的语言进行简洁的实现CaoYuan网站日志TopURL日志文本搜索LocalNADaily(?)用合适的语言充分利用多核CPU提升处理速度系统LogicalProcessDevelopmentPhysicalScenarioBeautifulCode一段顺序执行的代码顺序执行Ruby:循环、正则表达式、dict、SortSinglecore日志分析CaoYuan主控、分割、拼接、合并多线程进程并发receiveenderlang:spawnxxxMulticore日志分析Zachman:: Zachman是适合分析的一种框架我这里就简单说一下大家下去有兴趣可以看或者讨论。实际上我们可以看到最终我们要实现的个要素都没变唯一变化的是motivation也就是动机意图。就说我们的动机变了本来我们可能想说就这样一个小程序我们用一个beautiful的code去实现这样的话看的人也容易懂将来也好修改。后面不行了我受到时间的压力我希望提高速度另外我也有好的机器。所以其实在几乎所有要素没有变的情况下motivation变了导致我们整个信息系统的架构产生变化。这个motivation是什么呢?主要就是一条提高速度。下面我们再用的方法来分析一下。我们可以看到跟上面这个正好反过来。它几乎所有的形态都变了。这就可以看出来我们刚才所说的是一个很适合设计的框架很适合去分析信息系统内部的设计。既然这两个程序差别这么大那么它们内部所包含的内容当然完全不同。这一点我就不多讲了逻辑的视图执行的视图开发的视图和物理的视图都是不一样的。但是有一点是比较一样的什么东西比较一样呢就是Scenario。要做的场景一样都是拿来一个文件对他进行分析打印出结果。那这说明什么问题呢?场景并不足以决定我们架构的设计。这就是我为什么说这个视图在架构这个领域也不足以完全指导我们进行架构的设计因为它所强调的是通过场景的分析得出结果和内容那么如果场景的分析不足以导致一些内容的话那么这样设计出的架构还是有一定的不足之处。软件架构的本质  这里就来到了本次演讲的一个重点了就是软件架构的本质:软件架构从本质上来讲实际上是解决信息系统全局性的时间问题这是软件架构的最核心的本质。大家回想一下刚才的那个小例子实际上说软件架构在绝大部分情况下来讲是一种被迫的行为:如果我不是为了加快处理的速度我何必要搞这么复杂的程序呢?beautifulcode一共才有行还有个空行个end有效的代码只有行谁都看得懂。如果我一个信息系统哪怕就算是有万个功能点我每个功能点都能像beautifulcode那样写出来它就实现了用户的目标它们之间相互没有任何关系如果那样子的话我还需要架构吗?肯定不需要。好回到这个话题也就是说就我们刚才这个例子问题出现在哪?我时间解决不了我要速度我用beautifulcode做不到我就必须要想办法那么于是就设计出刚才那样一个小的“架构”来就可以把这个问题解决掉。当然这里我要强调一点刚才我是举了一个例子说明了这件事我的这句话这个软件架构的本质可不是从这个例子中分析出来的如果是那样的话那太可笑了。你搞了一个WideFinder的例子你就说你理解了软件架构的本质了就是全局性的时间问题那就太可笑了。这样一个结论顺便说一下是我长大型企业信息系统架构设计SDC软件架构的本质解决信息系统全局性的时间问题及时性适时性持久性开发功能点开发维护速度开发进度可维护性运行系统性能时间准确性系统容量、扩充能力验证执行速度、对环境的依赖性合适的时间完成验证目标与验证时间的关系Usually,timeisoftheessencewhendesigningsystemarchitecturesPhilippeKruchten 期以来对于软件开发的总体过程做了一个全面的语义学的分析最后得出的一个结论。这个话题太大了我今天就不讲了。我还是直接讲主题全局性的时间问题都有哪些?这是很重要的。大家可能可以从刚才的那个例子可以看到和大家的直觉一样普遍来讲要提升性能我需要一个好的架构这点大家在直觉上都应该是一致的。那么我告诉大家系统的性能在于架构的这种作用当中也就是的作用。就是在运行的及时性及时性就是快intime在某一个时间范围之内就把它做完。适时性就是我们所说的ontime就是准确就是如果我要在点分秒要做一件事要触发一个事件我必须要准确。持久性lasting就是随着时间迁移我的信息系统还能不能满足我的需要。这是时间的个维度。那么我们说全局性的时间问题都有哪些全局哪些角度呢?个角度。系统软件的开发、系统的运行这两点大家很容易理解。系统的验证这点大家以前接触的可能不是很多我今天也没有时间讲但我有一点要讲就是这个维度就是我所说的要对于软件开发总体过程要做一个深入的语义学的分析才能够得出这个维度。总之我们不讨论这个问题我们暂且就承认全局性的时间问题就是这个点。我这里标出颜色的这几个点性能开发进度可维护性这是我们大家接触比较多的。像这样的一些内容如时间准确性是很典型的在一个小的系统当中时间准确性不是很重要而在一个大型复杂的系统中时间准确性是十分重要的。这里我没法再去讲太多内容大家要有这样的一个概念后面我会用到一些内容来做一些分析。我这里最后讲一句话PhilippeKruchten就是我刚才说的模型的创始人他就是讲:Usually,timeisoftheessencewhendesigningsystemarchitectures。他这句话实际上表意是说时间是架构设计的本质和我这个上边呼应起来了(总算也不是完全我一个人在这里“独孤求败”)。他这么讲是出现在一篇文章中他讲的这个内容从语境上来看实际上是主要讲开发领域的角度。也就是说设计架构的时候时间很重要那么实际上我是因为做了一个这么架构的分析我把架构时间维度扩充到了个这个维度都是对于信息系统非常重要的维度这些内容都是要通过架构来保障的。 大型、复杂系统架构设计要点 

用户评价(0)

关闭

新课改视野下建构高中语文教学实验成果报告(32KB)

抱歉,积分不足下载失败,请稍后再试!

提示

试读已结束,如需要继续阅读或者下载,敬请购买!

文档小程序码

使用微信“扫一扫”扫码寻找文档

1

打开微信

2

扫描小程序码

3

发布寻找信息

4

等待寻找结果

我知道了
评分:

/43

大型企业信息系统的架构设计

VIP

在线
客服

免费
邮箱

爱问共享资料服务号

扫描关注领取更多福利