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

1  大型企业信息系统的架构设计 SD2C-2009 演讲文字整理 2010-5 2  前言    这是我在 CSDN SD2C 2009上所做的《大型企业信息系统架构设计》的演讲 的文字整理，这次演讲内容实际上很多，单纯看 PPT难以全部了解，而我又没 有时间写很多篇博客去系统性地介绍我在这方面的观点。好在 CSDN对此次讲 课内容有录音，我就此想出了一个偷懒的办法：把我的演讲内容直接整理成文 字，除了方便阅读而做一些字面上的调整之外，力求保持原样，因此有些地方 看着并不那么顺畅，也不可能像文章那样严谨，只求把我当时所讲的内容忠实 反映出来，供大家参考。  由于平时很忙，整理工作做了几页就中断了，后来多亏博文视点的编辑卢 鸫翔以及其他人接过了这个工作，替我做了整理。我最后根据录音做了一遍校 对，基本上是保持了原貌。现在再看里面的部分内容，有些显得太简略，由于 时间限制，没有展开讨论，恐怕说的不是那么清楚。还有一些内容，根据我的 最新研究已经已经有了较大的调整，不过为了保持原样，也就不进行任何修改 了。总之就是分享一下我的观点，抛砖引玉吧。  补充：随着看到文档的人越来越多，也有了很多和意见，其中最主要的一 条可能是说这个文档的覆盖面太大，因此很多地方并没有认真论述，结论未免 太直接。因此我需要在这里将背景简单说明一下。由于我好几次答应 CSDN进 行相关讲座，但是最终都由于各种事情没能实现。2009 年底终于有机会，因此 作为第一次演讲，希望将这个领域的相关思考与实践全面描述一下，所以内容 上务必求全，而没有展开论述（毕竟只有 1小时时间）。未来有机会，一定会 针对相关主 题 快递公司问题件快递公司问题件货款处理关于圆的周长面积重点题型关于解方程组的题及答案关于南海问题 进行深入讨论，无论是讲座、博客还是其他形式。      3  1. 标题    今天讲的主要内容是“大型企业信息系统的架构设计”，从标题来看，这 个概念主要分为三个部分：第一个是“企业信息系统”，我们首先要给这个概 念做个界定；第二个呢，是核心问题，也就是我们要做“架构设计”；第三呢， 我们还要强调一下“大型”系统的架构设计，看看有什么特殊的地方。 2. 内容提要   大型企业信息系统架构设计 SD2C 大型企业信息系统的架构设计 2009年10月 tenderice@gmail.com http://edge.javaeye.com（blog） http://www.softecture.com（建设中） 4    今天的主要内容大概分四个部分，第一部分就是我刚才说的，企业信息系 统有什么特点，要简单介绍一下。中间两个部分大致是讲一下架构设计的内容， 包括一些方法论的介绍，也包括我们简单做一些探索性的工作。最后呢，我们 回到这个“大”字上，就是系统足够大的时候，架构设计的要点到底在什么地 方。现在互联网的时代来临了，大家都知道互联网系统处理的数据量一般都比 较大。我们要看一看，企业信息系统“大”的时候，是不是和互联网系统有共 同的特点，还是说有可能是完全不同的东西。 3. 企业信息系统特点   大型企业信息系统架构设计 SD2C 内容提要 企业信息系统特点 信息系统架构设计方法论 软件架构本质探索 大型、复杂系统架构设计要点 5    好，首先讲一下企业信息系统的特点，这一部分只有这一张幻灯片。企业信 息系统的特点，从本质上来讲，有两个角度：首先是受限于企业的环境，其次 是服务于企业的目标。从这两个宏观的角度来讲，其实互联网的系统也是一样 的：互联网的系统，总也要受制于互联网这个环境，也要服务于企业在互联网 上经营的目标。那么他们的区别在什么地方呢，我们来仔细看一下。  首先，我们讲企业的外部环境——因为环境一般分为外部环境和内部环境， 说到外部环境呢，大家知道这个吧：“PEST 分析法”，这是企业外部环境的一 个重要分析法。这是四个词的缩写：政治、经济、社会和技术，也就是 political、 economical、social 和 technological。这四个方面呢，也就是一个企业在整个社 会当中，以及在整个国际化的时代当中所面临的外部环境，等会儿我会举几个 例子和大家说一下。外部环境应该说是对企业十分重要的，因为一个企业的发 展不可能脱离它所在的外部环境。下面再说内部环境，内部环境就是企业本身 内部的构成，比如说：它的 制度 关于办公室下班关闭电源制度矿山事故隐患举报和奖励制度制度下载人事管理制度doc盘点制度下载 、它的人员、它曾经的发展历史以及它现在所 拥有的资源等等。这两个环境对于企业来说应该说是决定性的因素，既然如此， 对于企业信息系统而言也是决定性的因素。比如说，大家有没有听说过 SWOT 分析法，相信有人知道，SWOT 分析法是研究企业发展战略的一个重要分析手 段，实际上就是从企业的外部环境和内部环境两个角度来分析企业的发展战略。  大型企业信息系统架构设计 SD2C 企业信息系统特点 受限于企业环境 – 外部环境：PEST – 内部环境：制度、人员、历史、资源… – 例子： • 敏感词过滤 • 用户可以用脚投票吗？ 服务于企业目标 – 效益、成本、风险、时间、… – 例子： • 开发活动本身是目标的组成部分 • 功能的可替代性 风险 效率 成本 6  等一下都我会讲到，那就是对于企业发展有决定性影响的因素，当然都是对企 业的信息系统有决定性影响的因素。  现在我来举个两个简单的例子：首先，互联网的领域内大家可能都知道这个 词：“敏感词过滤”。敏感词过滤可能是有一定我们中国特色的东西，因为这 是受到我们国内政治环境的影响，这就是我们所讲的外部环境中的第一个—— “P”。大家可能会看到，敏感词过滤也许是我们中国特色，也许西方国家不会 有。我想说的是，整个互联网的环境，在他初创的时候，都是很宽松的，包括 我们国内也一样，所以没有敏感词过滤的这个情况。随着互联网发展的越来越 快呢，类似于敏感词过滤这种情况，也就是受到政治因素影响的这种情况，会 越来越多。而作为企业的信息系统，由于很早，几十年以来就一直存在和发展， 因此实际上很早就开始受到政治因素的影响，这一点我们后面还会讲到。这个 例子中，如果我们构造一个搜索引擎，大家可能都知道 Map‐Reduce 这种架构， 但是如果要一个“带敏感词过滤功能的 Map‐Reduce 架构”，应该怎么做呢？ 比如说你是在哪一个阶段进行敏感词过滤呢？这里就是想说明，实际上包括敏 感词过滤这样的政治因素，都有可能对你的信息系统的架构产生非常直接的影 响，这是一个例子。  第二个例子呢，不知道大家有没有听说过，在互联网上，“用户可以用脚投 票”。也就是说你的网站、软件做的不好，用户的体验不好，他就不来用了， 就去别的网站了。但是，我们想一下，在一个企业内部的信息系统会发生这种 情况么？如果有一个财务软件做的不好，企业的会计人员能说我不用这个财务 软件，我用自己家里拿来一个财务软件来给公司记账么？这是不可能的。那么 这说明什么问题呢？我这里是要说明，“用户”这个概念，对于不同类型的信 息系统而言，差别是非常大的。对于一个互联网信息系统而言，用户实际上属 于这个信息系统的外部环境，也就是它的社会环境。而对于一个企业信息系统 而言，用户实际上是企业内部人员这样一个内部环境。所以我们大家应该知道， 当你建设一个信息系统的时候，如果你没有把这些重要的因素搞清楚，你连你 的用户是内部环境还是外部环境都没有搞清楚的情况下，你设计的信息系统， 肯定会出现很大的偏差。好，这些就是我们所讲的，受限于企业环境这样一个 要素。  7  下面呢，我们是要讲“服务于企业的目标”。我们大家都知道，企业建设信 息系统，无非就是那么几个目的，提高效益、降低成本、控制风险等等，其实 就是这样一些目的。那么我们刚才已经说了，互联网的信息系统，它建设的目 的，可能和这个就差别很大，比如说我宣传一个概念，吸引用户，然后我可以 拿到 VC，在创业板上市等等。这个途径，和企业建设信息系统的目标，差别是 非常大的，在这种情况下，如果我们不足够了解企业建设一个信息系统的目标， 我们往往会陷入一种唯技术论状况，就是把这个系统建设得很漂亮、很完美、 实现了我作为架构师或者作为程序开发者自己的目标，而没有去贴近企业的目 标。  我这里举两个例子，首先是对于企业信息系统而言，开发活动本身也是这个 企业的目标的一个组成部分，我想这点大家很容易理解。我们刚才举的例子是 说，如果我们建立一个互联网的信息系统，可能它的投资方并不是很关心你这 个系统的团队怎么样建设、怎么样开发、采用的工具是什么、管理 流程 快递问题件怎么处理流程河南自建厂房流程下载关于规范招聘需求审批流程制作流程表下载邮件下载流程设计 是什么， 他只是关心你最后做出来的网站的效果，以及你吸引的用户数。但是对于企业 来讲，因为开发活动对于它的目标产生重要的影响，所以他会把开发活动本身 也纳入他的效益、成本、风险的考虑当中，所以就会对你的开发活动产生非常 直接的控制和影响。也就是说他必须管理你的团队是什么样、你采用的开发工 具是什么样、你采用的方法是什么、架构是什么。比如有人说（后面我会举个 例子），现在 ROR 很流行，两三年、三四年了，现在应该说已经足够成熟了， 那么我想用 ROR 来开发一个企业信息系统可不可以呢？其实首先你就问一问甲 方可不可以就行了，如果他不同意，你就不要想用了。当然，后面我们还会看 到，还有很多其他因素决定你可不可以用 ROR 来开发企业信息系统。  第二个例子我想讲一下“功能的可替代性”，这一点也是企业信息系统和互 联网系统的一个很大的差别。什么叫功能的可替代性呢，就是回到我们企业的 目标，我们建设一个系统无非是为了达到这些个目标。那么，这些目标是不是 每一个细节都可以用程序这种东西来帮助我们实现呢？通常是不一定的，有时 候我们会看到，有很多的所谓系统的需求或者功能，我们要用程序开发出来， 其困难程度比我们直接定一个规则，让人采用手工的方式实现，要大得多，因 为有些工作并不是很适合于用计算机来做的。这些内容如果你不分析出来的话， 8  最后简单来说，你会把自己搞死，就是因为你一定要拿计算机去做那些不适合 用计算机来做的事，因为用户会给你提出来，说这是我的需求。所以在这方面 你必须进行分析，有些工作是完全可以用非信息系统的形态来实现的。这对于 我们信息系统的整体架构是有非常重要的意义的，因为经常你会忽视掉这一点， 在这种情况下，你会由于为了实现一个很难于实现的系统功能，而破坏了你整 个的系统架构。而实际上这个功能，我们把它孤立除去，根本不用信息系统来 实现，这种做法是完全可行的。互联网的信息系统普遍而言不具有这样的特点， 原因就是因为——回到我们刚才说的那一点——互联网系统的用户与你之间没 有任何直接的联系，他们只能通过浏览器，通过网络访问你的系统，你不可能 为他们提供一个不通过你网站系统实现的功能，你提供不了，但在企业中是可 以的。  所以，大家看我这一张幻灯片讲的很长（我这一部分只有这一页 PPT），就 是为了说明，影响企业信息系统的这些因素，我们需要认识到足够清楚，以及 他们与互联网信息系统之间有什么区别。这些内容在后面我所要讲的企业信息 系统架构设计当中都会有体现。  4. 架构设计方法论概览  9  下面我简单介绍一下信息系统架构设计的方法论，为什么要介绍方法论呢， 这里就要进入到架构设计领域的特点了。刚才我们说到了，要做企业信息系统 的架构设计，最关键是要理解企业的内部环境和外部环境，以及企业的目标。 但是从另一方面说，架构设计这个领域，在这二三十年内，越来越成为一个专 业的领域。也就是说，已经有很多人做了大量的工作，构建出了一些架构设计 的体系，目的就是为了抽象出架构设计这个领域当中（毕竟还是有）很多的客 观规律，有很多前人经验的总结。孔子说：“学而不思则罔，思而不学则殆”， 刚才我们讲的那些东西，实际上是“思”的过程，就是让大家反思/思考一下， 企业的信息系统到底有什么特点。但是光想不学是不行的，我们还是要看一下， 别人的方法论，在架构设计领域到底抽象出了哪些共性的东西，这些东西都应 该是我们在架构设计过程中可以用到的。下面简单说一下（这部分不是我讲的 重点，因为时间也不太够），这五个方法论应该说都是目前比较有名的方法论：  DODAF，这是美国国防部主导的架构体系，MODAF 是英国国防部主导的架 构体系，从名字上也能看出来与 DODAF 有一定关系，从 DODAF 借鉴了很多东 西，然后自己进行了一些构造。TOGAF，这是 OpenGroup 的架构体系，相当于 是一个国际标准化组织的架构体系。Zachman  Enterprise  Framework，这是一位 老先生，Zachman 先生创立的一个架构体系，也有二十多年的历史了。中间这 个图呢，是 4+1，不知道有多少人了解这个体系，熟悉 UML、Usecase 等等与  大型企业信息系统架构设计 SD2C 架构设计方法论概览DoDAF（Department of Defense Architectural Framework） TOGAF（The Open Group Architecture Framework ） MODAF（Ministry of Defence Architectural Framework） ZACHMAN Enterprise Framework The 4+1 View Model of Architecture 10  RUP 相关的体系的人可能会了解得比较多一点。这五个架构体系我想大家可以 看出来，有两个是国防部的，一个是国际组织的，一个是个人或者说企业的， 还有一个是领域专家（Kruchten）的，应该说这五个体系还是有一定代表性的。 从这里我们就可以看出来，很多的人，无论是机构、国际组织、公司、个人等 等，都有自己的架构方法论。这里就是简单介绍一下，后面主要对两个架构方 法论做一下介绍。  5. Zachman  企业架构（  5W1H  ）  首先是 Zachman 的企业架构，我简单列了一下，就是 5W1H。（字体可能比 较小，大家下来看 PPT 就可以了）。5W1H 这种模型，我想大家都听说过，不 仅仅是企业架构，就是 What、Who、Where、When、Why、How 等等，这样 的形态在所有领域的分析模型中都可能会用到。这样的一个体系，它的主要特 点是什么呢，我这里没有时间详细地介绍其中每一个点的内容，主要是让大家 形成一个印象，后面还会用到：这样一个体系的特点，是它非常适合于分析— —非常适合于分析企业信息系统架构的方方面面。这个我想大家应该比较容易 理解，任何一个领域内，这种 nW1H 的方法，都是一个非常有效的分析方法，  大型企业信息系统架构设计 SD2C What How Where Who When Why Scope List of things important to the enterprise List of processes the enterprise performs List of locations where the enterprise operates List of organizational units List of business events / cycles List of business goals / strategies Strategists Business Entity relationship diagram (including m:m, n-ary, attributed relationships) Business process model (physical data flow diagram) Logistics network (nodes and links) Organization chart, with roles; skill sets; security issues. Business master schedule Business plan Executive Leaders System Data model (converged entities, fully normalized) Essential Data flow diagram; application architecture Distributed system architecture Human interface architecture (roles, data, access) Dependency diagram, entity life history (process structure) Business rule model Architects Technology Data architecture (tables and columns); map to legacy data System design: structure chart, pseudo- code System architecture (hardware, software types) User interface (how the system will behave); security design "Control flow" diagram (control structure) Business rule design Engineers Component Data design (denormalized), physical storage design Detailed Program Design Network architecture Screens, security architecture (who can see what?) Timing definitions Rule specification in program logic Technicians Operations Converted data Executableprograms Communications facilities Trained people Business events Enforced rules Workers Inventory Process Network Organization Timing Motivation Zachman 企业架构（5W1H） 11  因为用它可以把方方面面的要素都列出来。大家不要忘了我们一开始讲的内容， 也就是影响企业信息系统架构的重要因素——内部环境、外部环境、目标，都 在这里有体现。  比如说我们看到头一行（纵向的内容我们等会儿再讲）：What：List  of  things——你这个企业是做什么的；How：List  of  Processes——如何做。比如说 一个银行和一个保险公司，他们做什么这一点上就肯定是不一样的。进一步而 言，如何做，这又是业务流程方面的问题，比如说同样是银行，或者同样是政 府，也没有两个流程完全一样的。Where——地理位置，比如说我是一家在中 关村某一个写字楼上有一个小办公室的公司，和我是全国范围内有三万六千个 网点的银行，他们的信息系统有可能一样么？不可能。Who——人员，或者角 色，就是这个企业有多少参与信息系统使用或者建设的人。When——时间，就 是说这个企业的业务以及信息系统有没有比较鲜明的时间特征，这个我们可以 等会儿再讲。Why——就是终极的，企业的目标，也就是你的企业为什么要做 这些事情，以及要这么做的原始驱动力是什么。所以这样一些维度就很有利于 分析我们前面所说的企业的内部环境、外部环境等等因素和目标。  那么再看纵向，纵向实际上是一个层次化的结构，就是从宏观一直到微观。 Scope 是最粗线条的，我们看到这六个点都是“List”，你只要把要点列出来就 可以。再下面就细化了，Business，业务层面的，比如说你有什么样的实体、什 么样的业务流程。再往下呢，系统层面，你的数据模型是什么。再往下是技术 层面，如何构造这些数据。再往下到组件层面；再往下到执行层面。由于纵向 是一个层次化的结构，横向是一个角度的结构，有了这样一个矩阵的结构，就 可以把企业信息系统的方方面面全都列在这里。这就符合了我们前面所说的， 你要决定一个企业信息系统的架构的时候，必须所要考虑的全部因素都在这里。  顺便强调一点，就是反过来说，这个框架适合于分析，适合于列出所有必要 的内容，但是并不一定适合于设计。我们可以看到，所有的地方都是说企业信 息系统应该有什么、有什么，但是怎么做，没有列出来，这是这个框架的特点。  12  6. Zachman  企业架构  这里是一个中文版的内容，中文不是我翻译的，但我看了应该没什么问题。 再简单说一句，就是 Zachman架构有一个网站，也就是这个公司的网站，这个 架构从 87 年开始（演讲中是 85 年，应该是记错了），到现在二十多年的历史 了。这个公司本身也提供架构师的培训和认证，我不是给他们做广告，因为我 和他们一点关系也没有。我想强调的一点是，这个架构经过二十多年的变迁和 他最初的时候也是有很大差异了。我这里也就顺便提出来，因为前两天也有人 问到，架构设计到底应该是什么样的规律，是不是可以完全形式化。从这个架 构体系也可以看出来，二十多年来它一直在变，可以说最近十几年每年都会推 出一个新版本。也就是说架构设计实际上没有绝对的一定之规。大家有兴趣可 以去这个网站看一下，为什么我要贴这个网站呢，我不是要给他做广告，是因 为这个网站有一个好的地方，网站上就有这个矩阵的一个图，每一个点都是可 以用鼠标点进去的，里面会有对相关概念的解释，大家可以通过这个形式去简 单学习一下，看看企业架构设计都要考虑哪些因素。  7. 4+1视图模型   大型企业信息系统架构设计 SD2C Zachman 企业架构 数据（什么） 功能（怎样） 网络（哪里） 角色（谁） 时间（何时） 动机（为何） 目标范围 列出对业务至关重要的元素 列出业务执行 的流程 列出与业务运营 有关的地域分布 要求 列出对业务重 要的组织部门 列出对业务重 要的事件及时 间周期 列出企业目标、 战略 业务模型 实体关系图（包括 M: M关系、N-ary 关系、归因关系） 业务流程模型 （物理数据流 程图） 物流网络（节点 和链接） 基于角色的组 织层次图， 包 括相关技能规 定、 安全保障 问题。 业务主进度表 业务计划 信息系统 模型 数据模型（聚合体 、完全规格化） 关键数据流程 图、 应用架构 分布系统架构 人机界面架构 （角色、数据 、入口） 相依关系图、 数据实体生命 历程（流程结 构） 业务标准模型 技术模型 数据架构（数据库 中的 表格 关于规范使用各类表格的通知入职表格免费下载关于主播时间做一个表格详细英语字母大小写表格下载简历表格模板下载 列表及属 性）、 遗产数据 图 系统设计： 结 构图、伪代码 系统架构（硬件 、软件类型） 用户界面（系 统如何工作） 、 安全设计 “控制流”图 （控制结构） 业务标准设计 详细展现 数据设计（反向规 格化）、物理存储 器设计 详细程序设计 网络架构 屏显、安全机 构（不同种类 数据源的开放 设定） 时间、周期定 义 程序逻辑的角色 说明 功能系统 转化后的数据 可执行程序 通信设备 受训的人员 企业业务 强制标准 http://www.zachmaninternational.com 13  下面一个，4+1 视图模型。有多少人知道的？这个我们可能不会将的太多。 这是 Philippe Kruchten 发明的，搞 UML 的人可能都知道。4+1 视图模型把系 统分为 5 个视图，Logical View 一般来讲是逻辑视图，Development View 是开 发视图（程序员、管理者关心怎么开发这个系统），Process View 是过程视图， 因为我们在系统当中会关心一些之行流程、性能、稳定性这样一些内容， Physical View 是最终的物理实现，包括软硬件，包括网络。中间的 Scenario View 是贯穿这四个视图最重要的，以前叫 Use-Case View，即通过 Use-Case 这 样需求分析的方法。这个理论是通过 Scenarios（场景）的分析，就可以分析 出来逻辑视图、开发视图是怎么样的，过程视图和物理视图是什么样的，这就 是它的一个重要思路。 8. 4+1视图模型矩阵形态   大型企业信息系统架构设计 SD2C 4+1视图模型 14  它也有一个矩阵形态，我们看到它横向有五个视图，纵向是每个视图中包 含的元素。Components 是它里边包含的实体；Connectors 是它们之间的关系和 连接；Containers 是实体的大范畴，比如说这些 class 的归类；Stakeholder 呢，做过 Use-Case 的可能都知道，现在普遍翻译成涉众，也就是会有哪些人参 与其中，或者有哪些系统参与其中；Concerns 就是关注点，比如说功能、性能。 最后还有一个 Tool support，就是在这样一个视图当中，我可以用什么工具进 行设计。这个视图我就不仔细讲了，还是给大家留一个印象，就是跟刚才那个 Zachman 视图比较起来，这样的一个视图很适合于做设计，刚才那个模型很适 合于做分析。这是因为它把每一个视图中的关键点都列出来了，这是它重要的 一个价值。 因为这两个视图后面我还会一个重要的结合点来讲，所以这边短时间先讲 到这样，大家先留下刚才那两个印象，一个是分析，一个是设计。 9. 不同架构方法论关系   大型企业信息系统架构设计 SD2C 4+1视图模型 View Logical Process Development Physical Scenarios Components Class Task Module,Subsystem Node Step, Scripts Connectors association, inheritance, containment Rendez-vous, Message, broadcast, RPC, etc. compilation dependency, “with” clause, “include” Communication medium, LAN, WAN, bus, etc. Containers Class category Process Subsystem(library) Physical subsystem Web Stakeholders End-user System designer, integrator Developer, manager System designer End-user, developer Concerns Functionality Performance, availability, S/W fault- tolerance, integrity Organization, reuse, portability, lineof-product Scalability, performance, availability Understand- ability Tool support Rose UNAS/SALEDADS Apex, SoDA UNAS, Openview DADS Rose 15  这个地方我简单地过一下，我们知道刚才大家看了五个方法论，实际上其 中我们只讲了两个。我们知道这些方法论之间应该还是有一定的关系，因为我 们不可以想象说这个世界上有五个甚至十个架构方法论（实际上十几、二十个 至少还是有的），如果它们之间都是完全相互隔绝的，任何两个方法论之间都 没有相互关系的话，那么根据这些不同的方法论设计出的信息系统，最后难道 完全不是一个东西吗，应该不可能。所以说这些架构方法论之间必然是有一定 关系的。我们这里简单说一下，这是一个 DODAF 和 Zachman 方法论的一个映射 表，从颜色的角度大家可以看到，DODAF 里面有 3 个主要的 view，和 Zachman 之间的 6 个维度有一定的映射关系，浅蓝的底色代表它的 operational view， 黄颜色的底色代表它的 system view。 这块就是想和大家简单说一下，因为这一节我们就是简单介绍一下架构方 法论。当然在这里我和大家分享一个我个人的观点：为什么刚才我没有讲像 MODAF 这样一个框架？实际上这样一个架构方法论在国际上是非常知名的，不 过我要跟大家说一句话：“珍惜生命，远离国防部”。为什么要这样说，因为 大家做企业信息系统做多了，可能会反思：我们知道像美国国防部实际上它在 整个软件开发体系做了很大贡献，占有很重要的地位。比如 CMM，是它和卡耐 基·梅隆合作，等于它委托卡耐基梅隆来做。MODAF 又是它自己设计的，像这 样一个东西，在我们整个的软件开发体系中起着重要的作用，但是我要跟大家  大型企业信息系统架构设计 SD2C 不同架构方法论关系（例） 16  说的是，最好大家不要总想去使用美国国防部的这一套东西。因为它所设计出 来的东西是具有鲜明的个性的东西——简单地来说就是一句话，世界上只有一 个美国国防部，对不对？总不会有两个美国国防部。但是，这世界上有多少企 业呢？我们要服务于一个领域的企业，我们去用世界上只有一个人或者一个客 户在使用的架构或者开发模型，大家觉得会合适吗？肯定不合适，我只能这么 跟大家说。这个话就说到这里，大家可以自己回去再考虑这个问题。 10. 架构方法的确立  刚才我们实际上讲了两个主要的部分，一个是企业信息系统的架构，信息 系统的特点；一个是一些架构方法论。我这里想讲的是，我们作为一个架构师， 我们要设计一个企业信息系统最主要的考虑点是哪两个入口：第一，我们首先 要将影响企业信息系统的各种因素都纳入考虑范畴。我们刚才所说的领域，这 是最重要的。我们经常这么讲，我做银行的信息系统的设计，我知道银行这个 业务的领域，我就是做再多年，我的架构功夫再深，我换到一个完全不同的领 域，制药业，电力企业，真的能够做好架构设计吗？我相信大家都觉得可能性 不大，至少我告诉大家我认为应该是不可能的。不要以为架构设计真的想那些  大型企业信息系统架构设计 SD2C 架构方法的确立 将影响企业信息系统的各种因素纳入考虑范畴 – 领域（业务） – 环境（内部、外部） – 目标、动机 – 时间 – … 以信息系统自身规律及特点作为依据 – 数据、功能 – 逻辑/物理 – 技术体系（JavaEE、.NET、…） – 开发方法论（敏捷、瀑布、…） – … 17  方法论那样可以完全的抽象出来，作为一个客观的领域，这是不可能的。领域 还是最终决定架构的根本因素。那么包括环境，包括目标、动机、时间、后面 都会讲到。 再有一个当然就是信息系统的自身规律，这也是一个依据。我们大家都知 道 dijkstra 的名言：“算法+数据结构=程序设计”。设计系统架构的时候能不 考虑数据和功能的架构吗？同样的，我们现在越来越多的分层方式，决定我们 每一点都可有能分为逻辑的架构和物理的架构，包括技术体系是 JavaEE 还 是.NET…。如果你作为一个有 15 年经验的 JavaEE 架构师，你说我在什么都不 考虑的情况下，我就可以转为.Net 的架构师吗？不可以。这就说明技术体系对 架构还是有一定决定的因素，包括开发的方法论都是一样，这一点在后面还会 详细地讲到：选择什么样的开发手段，对架构设计而言是很重要的。大家可能 都会认为说以往我们所宣传的架构都像那些 view 一样，都像是系统一些静态的 东西，其实不是这样的，你设计出的架构再好，开发不出来，你没有人，没有 足够水平的人，没有足够的方法可以保证你这个架构开发出来，也是没用的。 我这里多讲两句，举一个例子：鸟巢，大家都知道，架构这个词最早就是从建 筑业来的。大家知道吗，鸟巢它的每一根梁都是斜的，没有直的梁，可是我们 想一想，我们作为一个工人，作为一个建筑工人，我们平时怎么干活？是不是 最主要的就是两种，一个就是站着干活，一个是躺着干活。站着干活就是上下 左右，我从左到右系一根条，从上到下钉一排钉子。躺着干活是水平面的，就 是这样。所以鸟巢就面临一个最大的问题，它每一根梁都是斜的，没有衡平竖 直，那么工人怎么干活呢？就是因为这一点，所以在鸟巢这个图形设计出来之 后，很多的专家都认为鸟巢做不出来，就说这个架构设计本身就不合理：这个 不合理的因素完全不来自于它的承重结构和形态，而是来自于它没法施工。没 法施工的架构当然也就是个不合理的架构。这很明显。但是最终鸟巢还是做出 来了，为什么？没法施工只是你在某种形态下觉得施工的成本过高而已。我们 国家有钱，为了搞奥运会什么都可以做，最后大家知道吧，在电视上看过，工 人吊一根吊带，一个梁是 30 度的，人就斜成 30 度，不又成了上下左右了吗。 所以说，实际上一个架构设计，它跟你最后能不能做出来是很有关系的。如果 我们再突破一点，不是鸟巢，是什么蚁巢蜂巢，也许就真做不出来了。真做不 18  出来，那它就是不合理的。但鸟巢从某种意义上来说还是合理的架构，什么样 的一个合理架构呢？它是你还能够承担这个开发的成本，那它就还是合理的。 所以这样就还是回到我们刚才所说的，为什么我会强调开发的重要性呢？因为 在企业信息系统当中，开发活动本身是企业整体活动的一个部分。它也要控制 成本，也要收回效益和控制风险。所以我们一定要考虑在设计架构的时候， （顺便说只能说一句，因为我们现在讲互联网信息系统的时候，大家普遍都在 讲大数据量，多处理，实际上不是这样，而是说在企业当中，你有多少钱干多 少事。）你设计的架构必须要满足你的目标，这就是我讲的架构方法的确立。 11. 软件架构本质探索  其实我刚才所讲的那些主要还是在讲企业信息系统的特点，介绍了两个方 法论，主要是为了反映我刚才介绍企业信息系统特点的思路。后面我们将看到 这两个方法论怎么用。刚才我说了，今天主要讲三个主题，已经讲了两个了。 信息系统的特点，然后架构方法论和架构设计的介绍。中间必须岔开一条道， 来讲讲我对软件架构本质的探索。为什么要讲这个，因为在后面讲到大型的信 息系统的时候，不可避免的要考虑到一个问题：软件架构的本质是什么？如果  大型企业信息系统架构设计 SD2C 内容提要 企业信息系统特点 信息系统架构设计方法论 软件架构本质探索 大型、复杂系统架构设计要点 19  你不抓住本质的话，大型信息系统的设计普遍会出现偏差。 12. 引子：WideFinder  我先简单讲个例子，我不知道有多少人知道 WideFinder 这个例子（不知道 邓草原有没有在讲 scala 的时候讲到过？）。其实很简单，就是说在一个网站 的日志，如记录了谁在哪个时候访问了哪个 url。这些日志下来每天可能有 500M？1 个 G，2 个 G，都有可能，取决于你网站访问量的大小。那么你想知道 的一件事，就是在我这个网站当中哪一个 url 点击最多。比如在一个新闻网站， 如果我知道哪个 url 是点得最多的，那我就知道哪条新闻看的人最多。就是这 么一个原始的驱动力。那么它的解决是什么呢？WideFinder 的原始的解决有一 个 Ruby 的代码，大家看右边这段代码，从一个大型网站的日志当中，找到访问 最多的 10 个某种形态的 url，并且把它倒排序打印出来。我说的这句话就是这 段代码实现的功能。 我不知道大家对 Ruby 熟不熟，我就不介绍这个内容了，我就告诉大家，一 共 13 行代码，还有 2 个空行和 3 个 end，还有 2 个声明语句，也就是说这段代 码真正有效的内容也就是这么 5-6 行。那么这个代码有什么样的好处呢？就是 我刚才所说的那句话，从一个大型网站的日志当中，找到访问最多的 10 个某种  大型企业信息系统架构设计 SD2C 引子：WideFinder 问题 –找到weblog中top 10 URL 解决 –代码:Ruby –特性： • 代码如此简洁，几 乎不会出现错误 （ Beautiful Code ） • 顺序执行，没有明 显的架构特征 20  形态的 url，并且把它逆序的排列出来。实际上就是这段代码所做的事情。也 就是说，这段代码和我所描述的我想要达到的目标几乎是一一对应的：对于每 一行进行一个判断，如果看到它是这个 url，就对针对这个 url 的 count 加 1。 然后做个排序和打印，就是这样。它的好处是什么呢？代码如此简洁，几乎不 会出现什么错误。这就是我们平常所说的 Beautiful Code。不知道大家有没有 看过 Beautiful Code 这本 书 关于书的成语关于读书的排比句社区图书漂流公约怎么写关于读书的小报汉书pdf ，这就是那本书的头一个例子。那么这样一段代码， 我想大家会同意说它没有什么架构可言，从第一句话执行到最后一句话，整个 代码就结束了。 13. WideFinder（续）  为什么要举这个例子呢？我是为了给大家看另外一个事情。这个实现是 Erlang 实现的一个版本，功能是完全一样的。而且是我们这次的讲师邓草原实 现的一个版本。为什么会有这个实现呢？它的一个本质的原因是希望提高分析 的速度。因为我有一颗 8 核 16 个线程的 cpu，我希望能够提高处理这个文本和 最后打印出结果的速度，所以他就做了这样的一个程序。大家可以看到右边这 个程序是 Erlang 的程序，实际上也就是 100 来行，而且还包含了很多各种各样 的具体算法实现。所以实际“有效”的代码也并不多，但它的体系结构是这个 样子的：就是说我首先要采用把这个文件分而治之的办法，我把这样一个很大  大型企业信息系统架构设计 SD2C WideFinder（续） Erlang实现（邓草原） – 源起：充分利用系统资源（8C/16T CPU），提升处理速度 (sn, 1stLineHead,  lastLineEnd ) (sn, 1stLineHead,  lastLineEnd ) Split to n parts Split  to  lines Split  to  lines Split  to  lines Search & Put  count to Dict Search & Put  count to Dict Search & Put  count to Dict Merge dicts Sort & Print result (sn,  1stLine, lastLine) * may not  complete Merge to one line  & search 21  的文件，如 1 个 G 或 10 个 G，把它切成 10 块，然后对每一块进行我刚才所说 的搜索 url，并且把它计数。那所有的这些计数最后还要合并，因为是分开执 行的，合并完了再排序再打印。那么右边这里面还有一个小的异常情况需要处 理，就是说我们要把文件分块的话，它不一定每一块都是整行，而我的 url 搜 索是要针对整行来进行的。那怎么办呢？我切成 10 块的话，我得把每一块的头 和尾上那些半行的东西找个单独的线程把它们拼起来，然后再进行搜索，然后 再跟这里的结果一起进行合并。所以大家看到，虽然是这么一个小的程序，但 它已经明显地体现出了一个架构的特征。大家可以同意这一点吗？我们不能说 它是一个架构，因为这程序实在太小，但是它很明显有个架构的特征。 14. 架构分析  好，那我们就来分析一下——因为我们想要探讨软件架构的本质——为什 么会有这种情况的发生？首先我们用一个很不精确的分析——因为对每一个架 构都有很多内容，我们没法做到意义分析。我们就借用 Zachman 的一个方法， 分析一下产生这个原因的影响和现象。也就是说从一个 Ruby 的 beautiful 的代 码到这个 Erlang 的架构的代码，产生这个状况的原因是什么？我们刚才说了  大型企业信息系统架构设计 SD2C 架构分析 系统 What How Where Who When Motivation Beautiful Code 网站日志 Top 10 URL 日志文本 搜索 Local N/A Daily（？）用合适的语言进行 简洁的实现 Cao Yuan 网站日志 Top 10 URL 日志文本 搜索 Local N/A Daily（？）用合适的语言，充 分利用多核CPU提 升处理速度 系统 Logical Process Development Physical Scenario Beautiful Code 一段顺序执 行的代码 顺序执行 Ruby：循环、正则表 达式、dict、Sort Single- core 日志分析 Cao Yuan 主控、分割、 拼接、合并 多线程/进 程并发 receive/end. erlang:spawn_xxx Multi- core 日志分析 Zachman： 4+1： 22  Zachman 是适合分析的一种框架，我这里就简单说一下，大家下去有兴趣可以 看或者讨论。实际上我们可以看到，最终我们要实现的 5 个要素都没变，唯一 变化的是 motivation，也就是动机/意图。就说我们的动机变了，本来我们可 能想说就这样一个小程序，我们用一个 beautiful 的 code 去实现，这样的话看 的人也容易懂，将来也好修改。后面不行了，我受到时间的压力，我希望提高 速度，另外我也有好的机器。所以其实在几乎所有要素没有变的情况下， motivation 变了，导致我们整个信息系统的架构产生变化。这个 motivation 是什么呢？主要就是一条——提高速度。 下面我们再用 4+1 的方法来分析一下。我们可以看到 4+1 跟上面这个正好 反过来。它几乎所有的形态都变了。这就可以看出来，我们刚才所说的 4+1 是 一个很适合设计的框架，很适合去分析信息系统内部的设计。既然这两个程序 差别这么大，那么它们内部所包含的内容当然完全不同。这一点我就不多讲了， 逻辑的视图，执行的视图，开发的视图和物理的视图都是不一样的。但是有一 点是比较一样的，什么东西比较一样呢，就是 Scenario。要做的场景一样，都 是拿来一个文件，对他进行分析，打印出结果。那这说明什么问题呢？场景并 不足以决定我们架构的设计。这就是我为什么说 4+1 这个视图在架构这个领域 也不足以完全指导我们进行架构的设计，因为它所强调的是通过场景的分析得 出结果和内容，那么如果场景的分析不足以导致一些内容的话，那么这样设计 出的架构还是有一定的不足之处。 15. 软件架构的本质  23  这里就来到了本次演讲的一个重点了，就是软件架构的本质：软件架构从 本质上来讲实际上是解决信息系统全局性的时间问题，这是软件架构的最核心 的本质。大家回想一下刚才的那个小例子，实际上说软件架构在绝大部分情况 下来讲是一种被迫的行为：如果我不是为了加快处理的速度，我何必要搞这么 复杂的程序呢？beautiful code 一共才有 13 行，还有 4 个空行，3 个 end，有 效的代码只有 5 行，谁都看得懂。如果我一个信息系统，哪怕就算是有 1 万个 功能点，我每个功能点都能像 beautiful code 那样写出来它就实现了用户的目 标，它们之间相互没有任何关系，如果那样子的话，我还需要架构吗？肯定不 需要。 好，回到这个话题，也就是说，就我们刚才这个例子问题出现在哪？我时 间解决不了，我要速度，我用 beautiful code 做不到，我就必须要想办法，那 么于是就设计出刚才那样一个小的“架构”来，就可以把这个问题解决掉。 当然这里我要强调一点，刚才我是举了一个例子说明了这件事，我的这句 话这个软件架构的本质可不是从这个例子中分析出来的，如果是那样的话，那 太可笑了。你搞了一个 WideFinder 的例子，你就说你理解了软件架构的本质了， 就是全局性的时间问题，那就太可笑了。这样一个结论，顺便说一下，是我长 大型企业信息系统架构设计 SD2C 软件架构的本质 解决信息系统全局性的时间问题 及时性 适时性 持久性 开发 功能点开发/ 维护速度 开发进度 可维护性 运行 系统性能 时间准确性 系统容量、扩 充能力 验证 执行速度、对 环境的依赖性 合适的时间完 成 验证目标与验 证时间的关系 Usually, time is of the essence when designing system architectures — Philippe Kruchten 24  期以来对于软件开发的总体过程做了一个全面的语义学的分析，最后得出的一 个结论。这个话题太大了，我今天就不讲了。 我还是直接讲主题，全局性的时间问题都有哪些？这是很重要的。大家可 能可以从刚才的那个例子可以看到，和大家的直觉一样，普遍来讲要提升性能， 我需要一个好的架构，这点大家在直觉上都应该是一致的。那么我告诉大家， 系统的性能在于架构的这种作用当中，也就是 1/9 的作用。就是在运行的及时 性，及时性就是快，in time，在某一个时间范围之内就把它做完。适时性就是 我们所说的 on time，就是准确，就是如果我要在 0 点 0 分 0 秒要做一件事， 要触发一个事件，我必须要准确。持久性，lasting，就是随着时间迁移，我的 信息系统还能不能满足我的需要。这是时间的 3个维度。 那么我们说全局性的时间问题，都有哪些全局，哪些角度呢？3 个角度。 系统软件的开发、系统的运行，这两点大家很容易理解。系统的验证，这点大 家以前接触的可能不是很多，我今天也没有时间讲，但我有一点要讲，就是这 个维度就是我所说的要对于软件开发总体过程要做一个深入的语义学的分析， 才能够得出这 3 个维度。总之我们不讨论这个问题，我们暂且就承认，全局性 的时间问题，就是这 9 个点。我这里标出颜色的这几个点，性能，开发进度， 可维护性，这是我们大家接触比较多的。像这样的一些内容，如时间准确性是 很典型的，在一个小的系统当中时间准确性不是很重要，而在一个大型复杂的 系统中时间准确性是十分重要的。这里我没法再去讲太多内容，大家要有这样 的一个概念，后面我会用到一些内容来做一些分析。我这里最后讲一句话， Philippe Kruchten，就是我刚才说的 4+1 模型的创始人，他就是讲：Usually, time is of the essence when designing system architectures。他这句话 实际上表意是说，时间是架构设计的本质，和我这个上边呼应起来了（总算也 不是完全我一个人在这里“独孤求败”）。他这么讲，是出现在一篇文章中， 他讲的这个内容从语境上来看，实际上是主要讲开发领域的角度。也就是说设 计架构的时候时间很重要，那么实际上我是因为做了一个这么架构的分析，我 把架构时间维度扩充到了 9 个，这 9 个维度都是对于信息系统非常重要的维度， 这些内容都是要通过架构来保障的。 25  16. 大型、复杂系统架构设计要点