系统架构与设计V1.1讲解

SYSTEM ARCHITECTURE AND DESIGN 2 目录 常用的软软件架构风风格及适用情况分析 SOA 及分层层架构设计设计 架构设计实设计实 践 常用的软件架构风格及适用情况分析 4 软件架构 软件框架 常见的架构风格 5 软件架构概论 系统架构是一个软件系统从整体到部分的最高层次的划分。 一个系统通常是由元件组成的，而这些元件如何形成、相互之间 如何发生作用，则是关于这个系统本身结构的重要信息。 详细地说，就是要包括架构元件（Architecture Component）、联 结器（Connector）、任务流（Task-flow）。所谓架构元素，也 就是组成系统的核心“砖瓦“，而联结器则描述这些元件之间通讯的 路径、通讯的机制、通讯的预期结果，任务流则描述系统如何使 用这些元件和联结器完成某一项需求。 6 建造一个系统所作出的最高层次的、以后难以更改的，商业的和 技术的决定。 在建造一个系统之前会有很多的重要决定需要事先作出，而一旦 系统开始进行详细设计甚至建造，这些决定就很难更改甚至无法 更改。显然，这样的决定必定是有关系统设计成败的最重要决定 ，必须经过慎重的研究和考察。 7 架构的目标 可靠性（Reliable）： 软件系统对于用户的商业经营和管理来说极为重要，因此软件 系统必须非常可靠。 安全性（Secure） ： 软件系统所承担的交易的商业价值极高，系统的安全性非常重 要。 可伸缩性（Scalable） ： 软件必须能够在用户的使用率、用户的数目增加很快的情况下 ，保持合理的性能。只有这样，才能适应用户的市场扩展得可 能性。 8 架构的目标 可定制化（Customizable） ： 同样的一套软件，可以根据客户群的不同和市场需求的变化进 行调整。 可扩展性（Extensible）： 在新技术出现的时候，一个软件系统应当允许导入新技术，从 而对现有系统进行功能和性能的扩展 可维护性（Maintainable）： 软件系统的维护包括两方面，一是排除现有的错误，二是将新 的软件需求反映到现有系统中去。一个易于维护的系统可以有 效地降低技术支持的花费。 9 客户体验（Customer Experience）： 软件系统必须易于使用。 市场时机（Time to Market）： 软件用户要面临同业竞争，软件提供商也要面临同业竞争。以 最快的速度争夺市场先机非常重要。 10 架构的种类 根据我们关注的角度不同，可以将架构分成三种： 逻辑架构 物理架构 系统架构 11 逻辑架构 软件系统中元件之间的关系，比如用户界面，数据库，外部系统 接口，商业逻辑元件等等。 12 物理架构 软件元件是怎样放到硬件上的 下图描述了一个分布于北京和上海的分布式系统的物理架构，图 中所有的元件都是物理设备，包括网络分流器、代理服务器、 WEB服务器、应用服务器、报表服务器、整合服务器、存储服务 器、主机等等。 13 系统架构 系统的非功能性特征，如可扩展性、可靠性、强壮性、灵活性、 性能等。 系统架构的设计要求具备软件和硬件的功能和性能的过硬知识， 这一工作是架构设计工作中最困难的工作。 14 架构的两要素 元件划分和设计决定。 逻辑元件： 一个软件系统中的元件首先是逻辑元件。这些逻辑元件如何放 到硬件上，以及这些元件如何为整个系统的可扩展性、可靠性 、强壮性、灵活性、性能等做出贡献，是非常重要的信息。 设计决定： 进行软件设计需要做出的决定中，必然会包括逻辑结构、物理 结构，以及它们如何影响到系统的所有非功能性特征。这些决 定中会有很多是一旦作出，就很难更改的。 基于数据库的系统架构： 一般有多少个数据表，就会有多少页的架构设计文档。比如一 个中等的数据库应用系统通常含有一百个左右的数据表，这样 的一个系统设计通常需要有一百页左右的架构设计文档。 15 软件框架 什么是框架 框架与架构的区别 常见的框架 16 框架 什么是框架？ 框架，即framework。是某种应用的半成品，就是一组组件， 供选用完成自己的系统。简单说就是使用别人搭好的舞台，你 来做表演。而且，框架一般是成熟的，不断升级的软件。 框架与架构的区别？ 并无明确的定义，但一般从层的观点看，认为框架是底层的， 接近系统的。软件开发者在其上构建自己的软件架构，开发自 己的应用程序。 17 为什么要用框架 因为软件系统发展到今天已经很复杂了，特别是服务器端软件， 设计到的知识，内容，问题太多。在某些方面使用成熟的框架， 可以避免重复做已有的基础工作，而只需要集中精力完成系统的 业务逻辑设计。 框架一般是成熟，稳健的，可以处理系统很多细节问题，比如， 事务，安全性，数据流控制等问题。 框架一般都经过很多人使用，所以结构很好，所以扩展性也很好 ，而且它是不断升级的，使用框架的开发者可以直接享受别人升 级代码带来的好处。 框架一般处在低层应用平台（如J2EE）和高层业务逻辑之间的中 间层。 18 常见的框架 常见的JAVA框架 常见的.Net框架 其它基于C+的框架 19 常见的JAVA框架 EJB Struts Spring Hibernate IBatis JSF 20 不同层次的模式 架构模式或风格(Architectural Pattern) 设计模式(Design Pattern) 代码模式(Coding Pattern) 21 区别：在于三种不同的模式存在于它们各自的抽象层次和具体层 次。 架构模式是一个系统的高层次策略，涉及到大尺度的组件以及整 体性质。架构模式的好坏可以影响到总体布局和框架性结构。 设计模式是中等尺度的结构策略。这些中等尺度的结构实现了一 些大尺度组件的行为和它们之间的关系。模式的好坏不会影响到 系统的总体布局和总体框架。设计模式定义出子系统或组件的微 观结构。 代码模式是特定的范例和与特定语言有关的编程技巧。代码模式 的好坏会影响到一个中等尺度组件的内部、外部的结构或行为的 底层细节，但不会影响到一个部件或子系统的中等尺度的结构， 更不会影响到系统的总体布局和大尺度框架。 22 几种典型的架构模式 系统软件 分层(Layer) 管道和过滤器(Pipes and Filters) 黑板(Blackboard) 开发分布式软件 经纪人(Broker) 客户/服务器（Client/Server） 点对点（Peer to Peer） 交互软件 模型-视图-控制器（Model-View-Controller） 显示-抽象-控制（Presentation-Abstraction-COntrol） 23 其它 面向对象风格(ADT) 基于消息广播且面向图形用户界面的Chiron2风格 基于事件的隐式调用风格(Event-based, Implicit Invocation) 24 分层(Layer) 从不同的层次来观察系统，处理不同层次问题的对象被封装到不 同的层中。 软件为什么要分层？ 为了实现“高内聚、低耦合”。把问题划分开来各个解决，易于 控制，易于延展，易于分配资源 面向对象的、基于模块化的组件设计需要能够方便地修改应用程 序的各个部分。完成这一目标的一种好方法就是在层上工作，将 一个应用程序的主要功能分离到不同的层或者级中。 25 分层模型 从本质上讲，层代表了一个应用程序主要的功能。一般地， 我们将应用程序功能分为三个方面，对应3层架构模式。它 们是数据层（data layer）、商务层（business layer）和表 示层（presentation layer）。 数据层：包含数据存储和与它交互的组件或服务。这些组件 和服务在功能上和中间层相互独立（尽管在物理上不必一定 相互独立-它们可以在同一台服务器上）。 中间层：包括一个或者多个组件服务，它们应用商务规则、 实现应用程序逻辑并完成应用程序运行所需要的数据处理。 作为这个过程的一部分，中间层负责处理来自数据存储或者 发送给数据存储的数据。 26 表示层：从中间层获得信息并显示给用户。该层同时也负责 和用户进行交互，比较返回的信息并将信息回送给中间层进 行处理。 数据层从数据库中获得较为原始的数据，商务层把数据转换 成符合商务规则的有意义的信息，表示层把信息转换成对于 用户有意义的内容。 这种分层设计方式很有用，因为每一层都可以独立地修改。 我们可以修改商务层，不断地从数据层接受相同的数据，并 把这些数据传递到表示层，而不用担心出现歧义。我们也可 以修改表示层，使得对于站点外观的修改不必改动下面的商 务层逻辑。 27 管道和过滤器（Pipes and Filters） 管道和过滤器架构模式是为处理数据流的系统提供的一种模式。 它是由过滤器和管道组成的.每个处理步骤都被封装在一个过滤器 组件中，数据通过相邻过滤器之间的管道进行传输。每个过滤器 可以单独修改，功能单一，并且它们之间的顺序可以进行配置。 28 一个著名的例子是传统的编译器。传统的编译器一直被认为是一 种管道系统，在该系统中，一个阶段（包括词法分析、语法分析 、语义分析和代码生成）的输出是另一个阶段的输入。 29 问题： 一个必须处理或转换输入数据流的系统。把这样的系统作为单个 组件实现是不容易的： 系统必须由几个开发人员同时进行协作开发，整个系统任务自 然就被分解为几个处理阶段，而且需求很容易变动。因此你就 要通过替换或重新排序处理步骤来为将来的灵活性作规划。通 过加入这样的灵活性，采用现有处理组件构建是可以办到的。 系统的设计尤其是处理步骤的内部连接，必须考虑以下因素： 未来系统的升级通过替换某些处理步骤，或重组步骤。 不同的语境中小的处理步骤要比大的组件更易于重用。 不相连的处理步骤不可共享信息。 存在不同的输入数据源，可以用多种方式输出或存放最终结果 。 30 解决方案与结构 管道和过滤器体系架构模式把系统任务分成为几个独立的处理步 骤。这些步骤采用通过系统的数据流连接。一个步骤的输出是下 一个步骤的输入。每个处理步骤由一个过滤器组件实现，它处理 或者转化数据，并且系统的输入可以是多种数据源。 这种体系架构模式具有许多特性： 过滤器是独立运行的部件。也就是除了输入和输出外，每个过 滤器不受任何其他过滤器运行的影响。在设计上，过滤器之间 不共享任何状态信息。 独立性还表现在它对其处理的上游和下游连接的过滤器是“无知 “的.它的设计和使用不对与其连接的任何过滤器施加限制，唯 一关心的是其输入数据的，然后进行加工处理，最后产生数据 输出。 31 优点与缺点 优点： 结构简单：系统的行为是所有过滤器行为的简单复合。 系统易于维护和增强：增加新过滤器，替换旧过滤器。 支持复用：过滤器只同其输入、输出端口的数据相关。 各过滤器可以并发运行。 缺点： 容易导致批处理方式：每个过滤器从输入数据到输出数据的转 换是一个整体。转换通常不适合交互式的应用。 有时必须维护两个分离而又相关的流之间的对应关系。 同实现有关，过滤器之间的数据传输率较低，而且每个过滤器 都要作类似的数据打包和解包的工作。 32 黑板(Blackboard) 又称看板模式：在这种架构中，有两种不同的构件：一种是表示 当前状态中心数据结构；另一种是一种相互独立的构件，这些构 件对中心数据进行操作。这种架构主要用于数据库和人工智能系 统的开发。 模式识别、数据挖掘。 33 经纪人(Broker) 客户和服务器通过一个经纪人部件进行通信，经纪人负责协调客 户和服务器之间的操作，并且为客户和