软件架构与设计模式_2

1、软件架构与设计模式 曾令秋 博士、副教授 2014年4月 l 1. 软件架构 n 软件架构定义 n 架构设计方法与过程 n 软件架构的设计要点 l 2. 模式简介 n 模式的定义 n 模式的分类 l 3. 常用模式 n 从混沌到结构 n 分布式基础设施 n 事件多路分离和分派 n 接口分割 n 组件分割 l 4. 典型面向服务的架构SOA 2 目录目录 1. 软件架构 1.1 架构定义 l软件体系结构通常被称为架构，指可以预制和可重构的软件框架结构， Garlan l 基础结构架构师IA (Infrastructure Architect) 的工作是提炼和优化技术方面积累和沉淀 形成的基础性的

2、、公共的、可复用的框架和组件，这些是技术型公司传承下来的最宝 贵的财富; l 特定技术架构师TSA (Technology-Specific Architect)主要从事类似安全架构、存储架构 等专项技术的规划和设计工作; l 解决方案架构师SA (Solution Architect)的工作则专于解决方案的规划和设计，所谓解决 方案，就是把产品、技术或理论，不断地进行组合，来创造出满足用户需求的选择。 软件架构师基本上是EA+TSA+IA,是程序员向上发展的道路,系统架构师实际 上是SA+TSA，更着力于综合运用已有的产品和技术，来实现客户期望的需 求。 架构师分类架构师分类 8 1.2 架

3、构设计基本过程 概念化阶段概念化阶段 分析阶段分析阶段 架构设计阶段架构设计阶段 并行开发和测试阶段并行开发和测试阶段 验收与交互阶段验收与交互阶段 愿景 需求 架构 可执行系统 交付的系统 9 架构设计基本过程 分析阶段 需求分析 领域建模 确定关键需求 概念性架构设计 细化架构 验证架构 架构设计阶段 10 软件需求 l 需求 n 系统必须满足的情况或提供的能力. 可以直接来自客户需要, 也可 以来自合同,标准,规范或其他有正规约束力的文档 软件需求软件需求 功能需求功能需求 非功能需求非功能需求 质量属性质量属性 约束约束 运行期质量属性运行期质量属性 开发期质量属性开发期质量属性 11

4、 软件系统架构要素 l 它是一个软件系统从整体到部分的最高层次的划分。一个系统通常是由组件组成的， 而这些组件如何形成、相互之间如何发生作用，则是关于这个系统本身结构的重要信 息。系统包括架构组件、连接器、任务流。架构组件是组成系统的核心“砖瓦”，而 连接器则描述这些 组件之间通讯的路径、通讯的机制、通讯的预期结果，任务流则描 述系统如何使用这些组件和连接器完成某一项需求。 l 它是建造一个系统所作出的最高层次的、以后难以更改的，商业的和技术的决定。这 样的决定必定是有关系统设计成败的最重要决定，必须经过非常慎重的研究和考察。 在决定时，要考虑独特的架构风格和恰当的架构模式。 1.3 软件架构

5、的设计要素软件架构的设计要素 12 软件软件架构的目标架构的目标 l 可靠性（Reliable）。软件系统对于用户的商业经营和管理来说极为重要，因此软件 系统必须非常可靠。 l 安全性（Secure）。软件系统所承担的交易的商业价值极高，系统的安全性非 常重要。 l 可扩展性（Scalable）。软件必须能够在用户的使用率、用户的数目增加很快的情况 下，保持合理的性能，才能适应用户的市场扩展得可能性。 l 可定制化（Customizable）。同样的一套软件，可以根据客户群的不同和市场需求的 变化进行调整。 13 软件架构的目标 l 可延伸性（Extensible）。在新技术出现的时候，一个软

6、件系统应当允许导入新技术， 从而对现有系统进行功能和性能的扩展； l 可维护性（Maintainable）。软件系统的维护包括两方面：1。排除现有的错 误，2。将新的软件需求反映到现有系统中去。一个易于维护的系统可以有效 地降低技术支持的花费 l 客户体验（Customer Experience）。软件系统必须易于使用。 l 市场时机（Time to Market）。软件用户要面临同业竞争，软件提供商也要面 临同业竞争。以最快的速度争夺市场先机非常重要。 14 软件软件架构的种类架构的种类 软件系统的逻辑架构图 逻辑架构： 软件系统中元 件之间的关系， 比如用户界面， 数据库，外部 系统接口，

7、商 业逻辑元件， 等等 15 软件软件架构的种类架构的种类 物理架构： 软件元件是怎 样放到硬件上 的 软件系统的物理架构图 16 软件软件架构的种类架构的种类 l 系统架构系统架构：系统的非功能性特征，如可扩展性、可靠性、强壮性、灵活性、 性能等。 系统架构的设计要求架构师具备软件和硬件的功能和性能的过硬知识，是架 构设计工作中最为困难的工作。架构的两要素：元件划分和设计决定。 l 元件划分元件划分 一个软件系统中的元件首先是逻辑元件。这些逻辑元件如何放到硬件上，以 及这些元件如何为整个系统的可扩展性、可靠性、强壮性、灵活性、性能等 做出贡献，是非常重要的信息。 l 设计决定设计决定 进行软

8、件设计需要做出的决定中，必然会包括逻辑结构、物理结构，以及它 们如何影响到系统的所有非功能性特征。这些决定中会有很多是一旦作出， 就很难更改的。 17 视图可以表示系统的整体设计，但构架与以下几个具体方面相关： l模型的结构，即组织模式，例如分层。 l基本元素，即关键用例、主类、常用机制等，它们与模型中的各元素相对。 l几个关键场景，它们表示了整个系统的主要控制流程。 l记录模块度、可选特征、产品线状况的服务。 l构架视图在本质上是整体设计的抽象或简化，它们通过舍弃具体细节来突 出重要的特征。在考虑以下方面时，这些特征非常重要： n系统演进，即进入下一个开发周期。 n在产品线环境下复用构架或构

9、架的一部分。 n评估补充质量，例如性能、可用性、可移植性和安全性。 n向团队或分包商分配开发工作。 n决定是否包括市售构件。 n插入范围更广的系统。 构架重点构架重点 18 2. 模式 Pattern 19 模式简介 l要素 n背景 context n问题 problem n作用力 (约束) force n解决方案 solution 20 2.1 模式定义 lPOSA1的定义: nA pattern for software architecture describes a particular recurring design problem that arise in specific d

10、esign contexts, and presents a well-proven generic scheme for its solution. The solution scheme is specified by its constituent components, their relationships, and the ways in which they collaborate. 21 模式的特性 l 最佳实践的记录 n 更高一级的抽象 n 设计的公共词汇表 n 记录软件架构的工具 n 支持具有良好属性的软件构建 n 与项目细节, 实现方法, 编程语言无关 22 例子：简单的

11、模式Explicit Interface (显式接口) l 背景 n 软件架构工作的主要关注点之一: 有效恰当地表述组件接口 问题 一个组件代表一个自含的功能单位及其发布的使用契约. 客户可以使用它来建立自己的功能, 但是直接访问组 件的完全实现, 则会导致客户依赖组件的内部表示, 最终增加了应用程序内部的耦合度 作用力(force) 客户只能依赖组件发布的接口, 对实现的修改不能影响客户 客户不倚赖组件的地理位置 组件提供的方法对客户有意义, 能有效正确使用 将组件接口的声明与实现分离, 只对客户曝露组件接口, 同 时隐藏实现和位置 23 Method _B method _A Explic

12、it Interface (显式接口) method _B _imp method _A_ imp 客户客户 接口接口实现实现 多态分派 组件组件 24 误解与陷阱 l 企图将所有软件开发活动和工件变成模式 n 企图将每个新颖的和复杂的设计贴上模式的标签 n 将模式看成一些固定不变的事物: 如特定的类配置 n 将模式看作编码指南 n 有限或误解的模式词汇导致对给定问题使用了错误的模式 n 企望机械应用模式就可以得到精致的架构 25 误解与陷阱 n 企图在需要新思想的软件开发中使用现成模式 n 对模式如何起作用以及怎样起作用企望过高 n 企图完全基于自动化工具使用模式 n 将模式当作组件的简单集

13、合 n 认为基于模式的设计排斥或替代重构 26 2.2 模式分类 l 按粒度分类 n 架构, 设计, 惯用法 l 按效果好坏分类 n 模式, 反模式 l 按问题域(使用目的)分类 (以分布式计算为例) n 从混沌到结构 n 分布式基础设施 n 事件多路分离和分派 n 接口分割 n 组件分割 27 n 应用程序控制 n 并发 n 同步 n 对象交互 n 适配与扩展 n 模态(modal)行为 n 资源管理 (对象生命周期管理) n 数据库访问 3. 常用模式 28 常用模式 l 从混沌到结构 l 分布式基础设施 l 事件多路分离和分派 l 接口分割 l 组件分割 l 应用程序控制 l 并发 l

14、同步 l 对象交互 l 适配与扩展 l 模态(modal)行为 l 资源管理 l 数据库访问 29 3.1 从混沌到结构 30 3.1 从混沌到结构 l从混沌到结构 n将需求和约束转换为粗粒度的软件结构 各部分定义清晰,可操作 抽象与划分, 忽略细节 n关注 性能, 持续可用性 可扩展性, 可维护性 支持变化 31 3.1 从混沌到结构 l 领域建模 n满足应用领域的功能 性需求, 同时适应变化 功能属性 业务流程 业务算法选择 Domain Model 32 Domain Model (领域模型) l 背景 n 为应用建立初始结构 l 问题 需求和约束只是隐含了功能, 但还不能为应用提供直接

15、具体的开发结构 对系统范围和应用领域缺乏精确和合理的洞见, 会使实现成为一团烂泥,难于理解, 难于开发, 不易交付 l 作用力(force) 需求列表只是应用的问题域, 而不是解域, 需要映射为软件实体 建立一个模型建立一个模型, 定义系统的业务职责范围以及可能的变化定义系统的业务职责范围以及可能的变化: 模型元素是对应用领域的概念抽象模型元素是对应用领域的概念抽象, 它们的角色和交互反它们的角色和交互反 映了应用领域的工作流映了应用领域的工作流 33 从混沌到结构 l 分解领域模型 n 应用与环境怎样交互? n 应用怎样处理数据? n 应用支持什么变化? n 应用的预期生命周期如何? 34

16、Domain Model (领域模型) 内部划分 数据流处理数据驱动处理系统演进用户界面 变化 功能变化 远程通信 Domain Model Domain Object Pipes and Filters Shared Repository Blackboard Layers Database Access Layer Model-View- Controller Presentation Abstraction-Control Microkernel Reflection Broker Messaging Publisher- Subscriber 35 Layers (分层) l 背景 n

17、 必须支持系统的不同部分独立开发和演进 l 问题 l 由于受系统大小, 上市时间等需求约束, 需要考虑系统不同部分的独立开发和演进 l 如果系统架构不能清晰合理分离关注点, 则各部分的交互得不到很好的支持, 也不 能独立开发 l 作用力(force) l 如何寻求平衡,能够 l 合理划分系统, 使各部分可以独立开发和部署 l 不陷于细节的泥淖 对开发中的系统定义一个或多个层级对开发中的系统定义一个或多个层级, 每一层都具有清晰每一层都具有清晰 特定的职责特定的职责 36 Layers (分层) Function 1Function 1Function 1 Function AFunction

18、BFunction C Function XFunction YFunction Z 接口接口 实现实现 Layer 3 Layer 2 Layer 1 典型应用典型应用: TCP/IP等通信协议等通信协议 37 Layers (分层) l可沿不同维度指定分层的准则 n 抽象, 粒度, 硬件距离, 变化速度 l层数适当 l注意层中每个内聚的职责 l层内如何隔离变化 l控制和数据流可以在层间双向流动 l层间依赖关系是单向向下的: 下层不能依赖上层的功能 38 Layers :问题 层内分解接口和实现分离 连接 借口和实现 自底向上 层间通信 Layers 什么模式可以提供解决方案什么模式可以提供

19、解决方案? 39 Model-View-Controller (MVC) l 背景 n 要考虑应用的用户界面比领域功能变化快 l 问题 l 用户界面比应用的核心功能变化快, 但界面的变化不能对核心功能造成不良影响 l 作用力 l 用户界面的改变应该容易, 并局限于系统界面部分 l 界面显示的内容要与内部状态一致，能立即响应内部状态的变化 l 对支持多种skin外观的系统，每种skin的变化快慢不一样 将交互式系统划分为解耦的三部分：处理，输入和输将交互式系统划分为解耦的三部分：处理，输入和输 出通过某种变化传播机制保证三部分状态的一致出通过某种变化传播机制保证三部分状态的一致 40 Model

20、-View-Controller (MVC) display update do something update get data function 2 function1 data 1 data 2 data 3 notify User Interface Model View Controller 1. invoke 2. modify 3. start change notification 4. notify 5. update state Application Functionality 41 Presentation-Abstraction-Control (PAC) l 背景

21、 n 有时要考虑应用的不同功能职责需要不同范式的用户界面 l 问题 n 通过一种界面如表单,菜单,对话框等, 应用程序就可以提供人机交互, 但是有时候某 些应用程序需要对不同的功能提供不同范式的界面, 以达到最佳的操作性 l 作用力(force) n 比如在机器人控制系统中, 定义某项任务和控制机器人完成该任务需要不同的用户 界面, 但是必须保证所有的功能及其对应的用户界面内聚一致 n 某一界面的改变不能影响其对应的功能和其他功能-界面 n 某一功能实现的改变也不能影响其对应的界面和其他的功能-界面 将交互式应用划分为解耦的代理将交互式应用划分为解耦的代理agents层级结构层级结构: 一个顶

22、层根代理一个顶层根代理, 几个中间级代理几个中间级代理,以及许多底层代理以及许多底层代理. 每个代理完成应用的某项功能每个代理完成应用的某项功能, 并提供对应的用户界面并提供对应的用户界面 42 Presentation-Abstraction-Control (PAC) do something display mediate function_2 function_1 Presentation Control Abstraction do something display mediate function_2 function_1 do something display mediate

23、 function_2 function_1 do something display mediate function_2 function_1 do something display mediate function_2 function_1 协调协调 协调协调 协调协调协调协调 顶层顶层 PAC Agent 中间层中间层 PAC Agent 底层底层PAC Agent 43 MVC and PAC: 问题 用户界面分离 视图种类 控制器 种类 请求处理 用户界面分离 变化传播 模型划分 数据交换 OS/库 独立 变化传播 代理划分 数据交换 请求路由 控制设计 子系统设计Model-V

24、iew Controller Presentation Abstraction Control Domain Model 什么模式可以提供解决方案什么模式可以提供解决方案? 44 Microkernel (微内核) l 背景 n 设计支持不同部署环境下功能的可伸缩性和的适应性 l 问题 n 某些系统有多个版本, 每个版本或者提供不同的功能集, 或者在某一方面与前一版 本不同. 但是所有的版本应该基于共同的架构和核心功能 l 作用力(force) n 避免架构在不同版本间产生漂移, 使共享功能的开发和维护代价降到最小 n 应用的版本升级不需要修改系统, 或使修改降到最小 n 方便地提供针对不同界

25、面, 不同平台的版本, 以满足客户的环境 提供一个公用的最小的核心架构提供一个公用的最小的核心架构. 应用的不同版本通过一应用的不同版本通过一 种即插即用的基础设施种即插即用的基础设施, 在此架构上进行扩展在此架构上进行扩展. 45 Microkernel (微内核) route request register_ svr unregister_ svr function_1 function_2 function_3 display do something function_2 function_1 function_3 External Server (GUI) External Ser

26、ver (API) Microkernel Internal Server System User 46 Microkernel: 问题 标准和可选功能分离微内核以及内部服务器划分 微内核以及 内部服务器划分 数据交换 外部 服务器设计 微内核配置 请求路由 Microkernel Layers 什么模式可以提供解决方案什么模式可以提供解决方案? 47 Reflection (反射) l 背景 n 提供一种设计, 为预期之外变化的演进和集成做准备 问题 对长生命周期应用, 支持变化是可持续演进架构的关键. 但是通常很难预测什么会 变化以及什么时候发生变化. 作用力(force) 变化可能在任何

27、时候发生 变化可能在任何尺度上发生 对维护者隐藏变化的复杂性, 提供统一的机制支持各种变化 将属性将属性, 应用的结构、行为以及状态等的易变方面抽象为应用的结构、行为以及状态等的易变方面抽象为 一组元对象一组元对象. 使用两层架构分离元对象和核心应用逻辑使用两层架构分离元对象和核心应用逻辑: 元层次包含元对象元层次包含元对象, 基本层包含应用逻辑基本层包含应用逻辑. 48 Reflection (反射) User configure aspect configure property property_1 Metalobject Protocol Maintainer aspect_2Meta

28、lobjects do something function_1 User Interface function_1 Core Application Logic usesuses Metal Level Base Level 49 Reflection: 问题 监管控制与应用功能分离 基本层以及 元层的划分 元层访问 元对象 生命周期管理 Reflection Domain Model 什么模式可以提供解决方案什么模式可以提供解决方案? 50 Pipes and Filters (管道-过滤器) l 背景 n 提供一种设计, 使应用适合处理数据流 问题 某些应用需要处理数据流:输入数据逐级变

29、换为输出数据流使用通常的请求应 答式结构不可行，为此要建立一种数据流模型. 作用力(force) 系统的各部分对数据流执行明确的不同的动作 有些时候需要显式访问中间数据结果 数据流模型应该支持增量式读写和处理 持续时间长的处理不应成为性能瓶颈 将应用任务划分为几个自含的数据处理步骤将应用任务划分为几个自含的数据处理步骤,这些步骤通这些步骤通 过其间的数据缓冲区连接成一个数据处理管道过其间的数据缓冲区连接成一个数据处理管道. 51 input Pipes and Filters (管道-过滤器) bufferinput buffer input Input Device Output Devic

30、e Filter 1Pipe 1Filter 2Filter 2 Pipe N-1 Filter N 52 Pipes and Filters :问题 层间通过数据流交互 管道以及 过滤器的划分 远程通信 数据交换 Pipes and Filters Domain Model 什么模式可以提供解决方案什么模式可以提供解决方案? 53 Shared Repository (共享仓库) l 背景 n 提供一种设计, 使应用的各部分操作一组共享数据, 并通过共享数据进行协调 问题 某些应用本质上使数据驱动的: 组件之间的交互不是通过特定的业务流程, 而是依 赖其所处理的数据. 即便如此, 仍然需要一

31、种机制来控制这种交互. 作用力(force) 比如网络管理和控制系统, 它们需要操作大量现场数据. 其核心职责如监控,报警,汇 报等相互独立, 是数据状态决定了任务流程及其交互. 将这些任务直接联系起来会 导致硬编码的业务流程 为所有数据维持一个中心仓库为所有数据维持一个中心仓库, 以供各功能组件共享以供各功能组件共享. 数数 据的可用性据的可用性,质量以及状态等触发和协调应用的控制流质量以及状态等触发和协调应用的控制流. 54 Shared Repository (共享仓库) Application Components function_1 function_2 function_3 fu

32、nction_4 Shared Repository Operates on 55 Blackboard (黑板) l 背景 n 提供一种设计, 使应用在没有确定性解决方案的时候可以完成任务 问题 某些任务没有确定性算法, 但是试误技术足够胜任, 因此需要开发针对这种任务的 软件产品. 作用力(force) 输入的数据模糊不精确 需要探索各种方案路径, 每个中间步骤都可能产生可选结果, 通常不知道最佳解 在合理的时间内, 计算出有价值的解决方案 运用启发式计算运用启发式计算, 通过多个具有确定性算法的组件通过多个具有确定性算法的组件, 对假对假 定的中间解决方案逐步改进定的中间解决方案逐步改进

33、. 56 Blackboard (黑板) check activate check activate check activate Intermediate Solution Hypothesis 1 - Intermediate Solution Hypothesis 2 - Intermediate Solution Hypothesis 3 Knowledge Sources Blackboard run Control 1. 1. 2. 1. 1.确定最佳的知识源, 以修改黑板中的数据 2. 激活选中的知识源, 使之修改黑板中的数据 57 Blackboard , Shared Rep

34、ository : 问题 分离数据与功能分离数据与功能 传播变化 线程安全 数据访问 功能 划分 数据 访问 数据 交换 数据 交换 数据 访问 功能 划分 Shared Repository Blackboard Domain Model 什么模式可以提供解决方案什么模式可以提供解决方案? 58 Domain Object (领域对象) l 背景 n 所有设计的关键: 分离应用职责, 每个职责应自我包含, 内聚 问题 组成软件的各部分具有复杂的相互作用, 未经仔细设计会导致系统结构极其复杂 作用力(force) 关注点分离, 适当合理的划分系统 不同部分的实现和交互必须有效且高效, 特别是关

35、键属性如性能, 错误处理以及安 全性等 将每个不同的功能封装进一个自我包含的构成块将每个不同的功能封装进一个自我包含的构成块 Domain Object (领域对象领域对象)中中 59 Domain Object (领域对象) Function A Function BFunction C Function Z Domain Object 1 Function XFunction Y Domain Object 2 Domain Object 3Domain Object 4 Domain Object Interface Domain Object Implementation 60 Dom

36、ain Object (领域对象) 分离接口和实现 内部划分 内部划分 通用 领域对象 连接接口和实现生命周期控制 领域对象 配置 Domain Object Domain Model Layers Model-View- Controller Presentation Abstraction Control MicrokernelReflectionPipes and Filters Shared Repository Blackboard 什么模式可以提供解决方案什么模式可以提供解决方案? 61 3.2 分布式基础设施 62 分布式基础设施 l 分布式基础设施软件是一种中间件 (middl

37、eware) n 应用程序之下, 操作系统和网络之上 n 屏蔽来自不同操作系统和网络的固有复杂性和偶发复杂性 固有复杂性: 选择合适的通信机制, 并设计良好的协议来有效使用这些机制 设计合理的网络服务, 以有效利用现有计算资源, 并降低将来的维护成本 有效使用并发机制, 使系统获得可预计的, 可靠的高性能 管理和配置服务, 以获得最大程度的系统可用性和灵活性 63 偶发复杂性: 缺乏类型安全, 可移植, 可扩充的原始OS API 算法分解的广泛使用, 无谓造成网络应用程序在维护和扩充上的困难 网络应用中, 核心概念和功能的不断发现和创造, 造成软件生命周期的成本无谓地居高不下 l 有各种中间件

38、可供选择 n CORBA, .Net Remoting, the Microsoft Communication Framework, JMS l 了解这些中间件使用的设计模式, 有助于选择正确的中间件 l 这些中间件使用了三种基本的通信方式: messaging, publish/subscribe, remote method invocation , 基本上对应三种模式 分布式基础设施 64 分布式基础设施 模式模式通信方式通信方式通信关系通信关系组件依赖性组件依赖性 Broker (代理者)远程方法调用一对一组件接口 Messaging (消息传递)消息多对一通讯终点, 消息格式 Pu

39、blisher-Subscriber (发布者 -订阅者) 事件一对多事件格式 65 Messaging (消息传递) l 背景 n 需要一个通信的基础设施, 将独立开发的服务组成一个统一的系统 问题 某些分布式系统是由独立开发的服务组成, 这些服务必须可靠地交互, 但又不能导 致过紧的依赖关系 作用力(force) 集成现有的、独立的特定服务以构成企业级解决方案 被集成的服务需要可靠地协调工作, 但这些服务是独立开发的, 并不知道彼此的功能接口 每个服务可能要被多个集成环境使用, 服务对不同的集成环境不能具有排他性 将服务通过一个消息总线连接起来将服务通过一个消息总线连接起来, 并通过它异步

40、传输数据并通过它异步传输数据 消息消息. 对消息编码对消息编码, 使发送者和接受者能够可靠地通信使发送者和接受者能够可靠地通信, 而不而不 需要知道数据的所有静态类型信息需要知道数据的所有静态类型信息. 66 Messaging (消息传递) Message Bus Service 1Service 2Service 3Service 4 data msg 1 data msg 2data msg3 data msg 4 关键应用关键应用: Enterprise Application Integration, Service Oriented Architecture 67 Messagin

41、g (消息传递) Publisher-Subscriber (发布者-订阅者):问题 进程间通信进程间通信 数据 转移 数据 封装 数据格式 转换 数据 路由 错误 通知 Messaging Publisher- Subscriber Domain Model 组件 连接 数据格式 转换 数据 路由 错误 通知 事件 封装 事件 转移 组件 连接 事件 过滤 什么模式可以提供解决方案什么模式可以提供解决方案? 68 Publisher-Subscriber (发布者-订阅者) l 背景 n 需要一种通信基础设施, 当某事件发生时, 系统中感兴趣的组件可以彼此通告 问题 某些分布式系统是由松散耦

42、合,基本独立的组件构成. 如果这种系统需要在各组件间传播信息, 则需要某种机制 来通知各组件有关系统状态的变化, 或其他事件, 这些事件会影响各组件本身的计算或组件间的协调工作 作用力(force) 通告机制不能造成各组件的耦合过于紧密 接收事件的那些组件只知道系统中有某个组件处于特定状态, 但不关心具体是哪个组件处于该状态 散布事件的组件也不关心哪个组件会接收它 各组件不知道彼此的位置 定义一种变化传播基础设施定义一种变化传播基础设施, 发布者发布者(publisher)通过它发通过它发 布事件布事件, 其他发布者可能对该事件包含的信息感兴趣其他发布者可能对该事件包含的信息感兴趣. 事事 件

43、发生时要告知对该事件感兴趣的订阅者件发生时要告知对该事件感兴趣的订阅者(subscriber). 69 Change Propagation Infrastructure Publisher 1Subscriber 2Subscriber 3Publisher 2 State change State changeState change State change Publisher-Subscriber (发布者-订阅者) 应用应用: CORBA Notification Service 70 Messaging (消息传递) Publisher-Subscriber (发布者-订阅者):问

44、题 进程间通信进程间通信 数据 转移 数据 封装 数据格式 转换 数据 路由 错误 通知 Messaging Publisher- Subscriber Domain Model 组件 连接 数据格式 转换 数据 路由 错误 通知 事件 封装 事件 转移 组件 连接 事件 过滤 什么模式可以提供解决方案什么模式可以提供解决方案? 71 Broker (代理者) l 背景 n 需要一种通信基础设施, 以之屏蔽组件位置和进程间通信的复杂性 问题 分布式应用要面对许多单进程应用未有的挑战, 但是应用不应该自己直接去处理这些挑战. 应用应该使用模块 化的编程模型, 力求简化, 以屏蔽网络连接和空间位置

45、等细节 作用力(force) 将不同语言写的各类服务移植到不同的操作系统平台, 是一项极其复杂的任务 在何处以什么方式部署服务, 也是一项复杂费力的事情 服务之间通过方法调用的协作应该以一种与位置无关的方式进行 使用代理者使用代理者(broker)联盟封装分布式系统通信基础设施的联盟封装分布式系统通信基础设施的 细节细节, 并与应用系统的功能分离并与应用系统的功能分离. 要定义一种基于组件的编要定义一种基于组件的编 程模型程模型, 以使客户应用调用远程服务的方法时就象在本地调以使客户应用调用远程服务的方法时就象在本地调 用一样用一样. 72 method_1 method_2 Broker (

46、代理者) send receive request discover receive send invoke register method_1 method_2 client Client Proxy Client-side Broker Server-side Broker Application Component Discover client proxy Register component Network 73 Broker (代理者): 问题 进程间通信 Broker Domain Object 请求分派 请求分派 代理者访问 组件访问 组件访问 发布-订阅通信 组件创建 内部划

47、分 OS 抽象 发出请求 接收请求 封装请求 错误通知 代理者配置 组件发现 什么模式可以提供解决方案什么模式可以提供解决方案? 74 3.3 事件多路分离和分派 l 分布式计算的核心: 响应和处理来自网络的事件 事件处理的复杂性: 事件异步到达 多个事件同时到达 事件到达顺序不确定 多种类型的事件 隐藏事件多路分离和分派的复杂性 事件处理软件通常采用Layers架构模式 事件源:sockets 事件多路分离器: WaitForMultipleObjects, select, et al 事件处理器 +应用程序 75 事件多路分离和分派 l模式提供高效，可扩展，可复用解决方案 Reactor(

48、反应器)模式 对事件执行同步多路分离并分派给应用程序 Proactor(前摄器)模式 对事件执行异步多路分离和分派, 可获得并发处理的好处并规 避其缺点 Acceptor-Connector(接收器-连接器)模式 将连接和初始化工作与其后的一般事件处理分离 Asynchronous Completion Token(异步完成令牌)模式 对异步服务请求的响应提供高效的多路分离和处理 76 Reactor (反应器) l 背景 n 开发事件驱动应用时, 需要将事件的检测, 多路分离和分派等与处理时间短的服务分离 问题 事件驱动软件接受来自多个源的服务请求事件, 并对之实行多路分离, 分派给事件处理

49、器 做进一步处理. 多个 事件可能同时到达, 但是为简化软件开发, 这些事件需要顺序处理, 并同步返回处理结果. 作用力(force) 高效灵活处理多个源的并发事件 容易集成新的或改进的事件处理器 提供一种事件处理基础设施提供一种事件处理基础设施, 它可以同时等待多个源的服务它可以同时等待多个源的服务 请求事件请求事件, 但是每次只分离一个事件但是每次只分离一个事件, 并将该事件分派给相并将该事件分派给相 应的事件处理器去执行对应的服务应的事件处理器去执行对应的服务 77 event loop Reactor (反应器) A client demux event event _loop() b

50、egin # run an infinite event loop for (ever) # block waiting for events to occur event = demux _events(); # dispatch the event handler = identify _handler (event); handler. handle _event (event); rof end handle event handle event handle event Event handlers Start event processing Reactor Operating S

51、ystem Send service request event 1 3 2 4 78 Proactor (前摄器) l 背景 n 开发事件驱动应用时, 需要将事件的检测, 多路分离和分派等与处理时间长的服务分离 问题 为获得高性能和高吞吐量, 事件驱动软件需要同时处理多个事件, 但是又不希望使用多线程 作用力(force) 对服务请求的处理不能延迟太久 性能和吞吐量要最大化 容易集成新的和改进的组件 将应用程序功能分为异步操作和完成处理器两部分将应用程序功能分为异步操作和完成处理器两部分. 异步操作针对事件异步操作针对事件 源执行某些活动源执行某些活动, 而完成处理器使用异步操作的结果而完成

52、处理器使用异步操作的结果. 异步操作和完成异步操作和完成 处理器共同实现应用的服务逻辑处理器共同实现应用的服务逻辑. 异步操作由操作系统执行异步操作由操作系统执行, 而完成处而完成处 理器在应用的控制线程中执行理器在应用的控制线程中执行 79 event loop Proactor (前摄器) A client demux event handle _event (Event event) begin # Process the received event if (event. type=Request) # read request asynchronously # and return

53、control async _read(); elseif (event. Type =READ_COMPLETE) # Process event, deliver results # asynchronously, and return control process_ data(); async _write(); fi end handle event handle event Completion handlers Start event processing Proactor Operating System Send service request event 1 3 2 4 a

54、sync write async read 80 Reactor (反应器), Proactor (前摄器):问题 Reactor Proactor Server Request Handler Client Request Handler 同步事件处理 异步事件处理 异步事件处理 同步事件处理 实现的 变化 实现的 变化 事件处理器 类型 事件处理器 类型 事件源封装 事件源封装 并发事件处理 并发事件处理并发事件处理 事件处理器 分派 完成处理器 分派 什么模式可以提供解什么模式可以提供解 决方案决方案? 81 Acceptor-Connector(接受器-连接器) l 背景 n 在面向连

55、接的网络系统中实现事件处理器时, 建立连接以及初始化事件处理器等基 本活动需要与处理应用特定服务的功能分离 问题 网络系统中对等的事件处理器在执行其服务功能前需要先建立连接并初始化, 建立连接以及初始化代码与其服 务功能基本无关 作用力(force) 事件处理器服务的变化比连接建立和初始化策略的变化快 事件处理器可能动态改变其在连接中的角色 在网络系统中在网络系统中, 将对等事件处理器的连接和初始化与之后执将对等事件处理器的连接和初始化与之后执 行的服务解耦行的服务解耦 82 connect 1 3 4 service init Acceptor-Connector (接受器-连接器) acc

56、ept service init connectoracceptor Service handler Connect me Pass connection 3 Pass connection Perform work 2 Accept connection Service handler A peer componentAnother peer component 83 Acceptor-Connector (接受器-连接器):问题 Acceptor- Connector Server Request Handler Client Request Handler Proactor 事件处理器

57、类型 Reactor 事件处理器 类型 完成处理器 类型 创建服务 处理器 封装IPC机制 管理 事件处理器 连接管理的变化 并发服务处理器 84 Asynchronous Completion Token (异步完成令牌) l 背景 n 在使用异步通信的系统中, 需要高效地多路分离和处理对异步服务请求的响应 问题 客户端异步调用服务, 其响应通过完成事件返回, 并在客户端处理. 客户端调用服务后不能被阻塞, 客户端在完 成事件到达时的状态与调用服务时的状态不同 作用力(force) 客户需要在合适的背景下处理异步响应 客户判断如何处理异步响应的时间要尽可能短 异步响应到达的顺序与请求发起的顺

58、序可能不同 客户在发起每个异步服务请求的同时客户在发起每个异步服务请求的同时, 传输一个异步完成令牌传输一个异步完成令牌, 该令牌该令牌 包含足够的信息包含足够的信息, 可以让客户知道如何处理服务完成后的返回结果可以让客户知道如何处理服务完成后的返回结果 85 dispatch 1 3 4 dispatch service Asynchronous Completion Token (异步完成令牌) Client 2 process result async_ operation Send request Return response Dispatch result Process resu

59、lt ACT Service 86 Asynchronous Completion Token (异步完成令牌): 问题 Asynchronous Completion Token Future 未来通告 完成处理器 通告 Proactor ACT管理 87 3.4 接口分割 l 组件接口要告知客户其职责, 提供的服务, 以及使用契约 l 利于客户正确有效地与之合作 l 设计高质量的组件接口, 需要解决的问题 组件的职责与契约规范 质量属性 描述性和简单性 松耦合和稳定性 组件的分布性 组件及其客户的异质性 88 接口分割 l 相关模式 n Explicit Interface (显式接口)

60、n Extension Interface (扩展接口) n Introspective Interface (内省接口) n Dynamic Invocation Interface (动态调用接口) n Business Delegate (业务代理) n Proxy (代理) n Faade (外观) n Combined Method (组合方法) n Iterator (迭代器) n Enumeration Method (枚举方法) n Batch Method (批处理方法) 89 Explicit Interface (显式接口) l 背景 n 软件架构工作的主要关注点之一: