软件架构与设计模式_2

1、软件架构与设计模式曾令秋 博士、副教授2014年4月l 1. 软件架构n 软件架构定义n 架构设计方法与过程n 软件架构的设计要点l 2. 模式简介n 模式的定义n 模式的分类l 3. 常用模式n 从混沌到结构n 分布式基础设施n 事件多路分离和分派n 接口分割n 组件分割l 4. 典型面向服务的架构SOA2目录目录1. 软件架构1.1 架构定义l软件体系结构通常被称为架构，指可以预制和可重构的软件框架结构，Garlan & Shaw模型的基本思想是：软件体系结构=构件(component)、连接件(connector)和约束(constrain)：n 构件可以是一组代码，如程序的模块

2、；也可以是一个独立的程序；n 连接件可以是过程调用、管道、远程过程调用(RPC)等，用于表示构件之间的相互作用；n 约束一般为对象连接时的规则，或指明构件连接的形式和条件，例如，上层构件可要求下层构件的服务，反之不行；两对象不得递规地发送消息；代码复制迁移的一致性约束；什么条件下此种连接无效等。4架构定义l 软件架构不仅仅注重软件本身的结构和行为, 还注重其他特性:使用, 功能性, 性能, 弹性, 重用, 可理解性, 经济和技术的限制及权衡。5例: ACE的分层架构6架构的范围l 软件架构本门课程的主关注点。l 硬件架构包括CPU, 内存，硬盘，周边设备例如打印机，与连接这些元素的部分。l 组

3、织架构是一些关于商业进程，组织结构，规则和职责，与组织核心能力的部分。l 信息架构包含组织好的信息结构。l 软件架构、硬件架构、组织架构和信息架构是全部系统架构的子结构。l 企业架构与系统架构很相似，包括硬件，软件，人员等。7l 企业架构师EA (Enterprise Architect) 的职责是决定整个公司的技术路线和技术发展方向。盖茨给自己的Title是首席软件架构师，实际上就是EA角色;l 基础结构架构师IA (Infrastructure Architect) 的工作是提炼和优化技术方面积累和沉淀形成的基础性的、公共的、可复用的框架和组件，这些是技术型公司传承下来的最宝贵的财富;l

4、特定技术架构师TSA (Technology-Specific Architect)主要从事类似安全架构、存储架构等专项技术的规划和设计工作;l 解决方案架构师SA (Solution Architect)的工作则专于解决方案的规划和设计，所谓解决方案，就是把产品、技术或理论，不断地进行组合，来创造出满足用户需求的选择。 软件架构师基本上是EA+TSA+IA,是程序员向上发展的道路,系统架构师实际上是SA+TSA，更着力于综合运用已有的产品和技术，来实现客户期望的需求。架构师分类架构师分类81.2 架构设计基本过程概念化阶段概念化阶段分析阶段分析阶段架构设计阶段架构设计阶段并行开发和测试阶段并

5、行开发和测试阶段验收与交互阶段验收与交互阶段愿景需求架构可执行系统交付的系统9架构设计基本过程分析阶段需求分析领域建模确定关键需求概念性架构设计细化架构验证架构架构设计阶段10软件需求l 需求n 系统必须满足的情况或提供的能力. 可以直接来自客户需要, 也可以来自合同,标准,规范或其他有正规约束力的文档软件需求软件需求功能需求功能需求非功能需求非功能需求质量属性质量属性约束约束运行期质量属性运行期质量属性开发期质量属性开发期质量属性11软件系统架构要素l 它是一个软件系统从整体到部分的最高层次的划分。一个系统通常是由组件组成的，而这些组件如何形成、相互之间如何发生作用，则是关于这个系统本身结构

6、的重要信息。系统包括架构组件、连接器、任务流。架构组件是组成系统的核心“砖瓦”，而连接器则描述这些 组件之间通讯的路径、通讯的机制、通讯的预期结果，任务流则描述系统如何使用这些组件和连接器完成某一项需求。l 它是建造一个系统所作出的最高层次的、以后难以更改的，商业的和技术的决定。这样的决定必定是有关系统设计成败的最重要决定，必须经过非常慎重的研究和考察。在决定时，要考虑独特的架构风格和恰当的架构模式。1.3 软件架构的设计要素软件架构的设计要素12软件软件架构的目标架构的目标l 可靠性（Reliable）。软件系统对于用户的商业经营和管理来说极为重要，因此软件系统必须非常可靠。l 安全性（Se

7、cure）。软件系统所承担的交易的商业价值极高，系统的安全性非 常重要。l 可扩展性（Scalable）。软件必须能够在用户的使用率、用户的数目增加很快的情况下，保持合理的性能，才能适应用户的市场扩展得可能性。 l 可定制化（Customizable）。同样的一套软件，可以根据客户群的不同和市场需求的变化进行调整。13软件架构的目标l 可延伸性（Extensible）。在新技术出现的时候，一个软件系统应当允许导入新技术，从而对现有系统进行功能和性能的扩展；l 可维护性（Maintainable）。软件系统的维护包括两方面：1。排除现有的错 误，2。将新的软件需求反映到现有系统中去。一个易于维护

8、的系统可以有效 地降低技术支持的花费l 客户体验（Customer Experience）。软件系统必须易于使用。l 市场时机（Time to Market）。软件用户要面临同业竞争，软件提供商也要面 临同业竞争。以最快的速度争夺市场先机非常重要。14软件软件架构的种类架构的种类软件系统的逻辑架构图逻辑架构：软件系统中元件之间的关系，比如用户界面，数据库，外部系统接口，商业逻辑元件，等等15软件软件架构的种类架构的种类物理架构：软件元件是怎样放到硬件上的软件系统的物理架构图16软件软件架构的种类架构的种类l 系统架构系统架构：系统的非功能性特征，如可扩展性、可靠性、强壮性、灵活性、 性能等。系

9、统架构的设计要求架构师具备软件和硬件的功能和性能的过硬知识，是架 构设计工作中最为困难的工作。架构的两要素：元件划分和设计决定。 l 元件划分元件划分 一个软件系统中的元件首先是逻辑元件。这些逻辑元件如何放到硬件上，以 及这些元件如何为整个系统的可扩展性、可靠性、强壮性、灵活性、性能等 做出贡献，是非常重要的信息。l 设计决定设计决定 进行软件设计需要做出的决定中，必然会包括逻辑结构、物理结构，以及它 们如何影响到系统的所有非功能性特征。这些决定中会有很多是一旦作出， 就很难更改的。17视图可以表示系统的整体设计，但构架与以下几个具体方面相关：l模型的结构，即组织模式，例如分层。 l基本元素，

10、即关键用例、主类、常用机制等，它们与模型中的各元素相对。l几个关键场景，它们表示了整个系统的主要控制流程。 l记录模块度、可选特征、产品线状况的服务。 l构架视图在本质上是整体设计的抽象或简化，它们通过舍弃具体细节来突出重要的特征。在考虑以下方面时，这些特征非常重要： n系统演进，即进入下一个开发周期。 n在产品线环境下复用构架或构架的一部分。 n评估补充质量，例如性能、可用性、可移植性和安全性。 n向团队或分包商分配开发工作。 n决定是否包括市售构件。 n插入范围更广的系统。 构架重点构架重点 182. 模式 Pattern19模式简介l要素n背景 contextn问题 problemn作用

11、力 (约束) forcen解决方案 solution202.1 模式定义lPOSA1的定义:nA pattern for software architecture describes a particular recurring design problem that arise in specific design contexts, and presents a well-proven generic scheme for its solution. The solution scheme is specified by its constituent components, their

12、 relationships, and the ways in which they collaborate.21模式的特性l 最佳实践的记录n 更高一级的抽象n 设计的公共词汇表n 记录软件架构的工具n 支持具有良好属性的软件构建n 与项目细节, 实现方法, 编程语言无关22例子：简单的模式Explicit Interface (显式接口)l 背景n 软件架构工作的主要关注点之一: 有效恰当地表述组件接口 问题一个组件代表一个自含的功能单位及其发布的使用契约. 客户可以使用它来建立自己的功能, 但是直接访问组件的完全实现, 则会导致客户依赖组件的内部表示, 最终增加了应用程序内部的耦合度 作

13、用力(force)客户只能依赖组件发布的接口, 对实现的修改不能影响客户客户不倚赖组件的地理位置组件提供的方法对客户有意义, 能有效正确使用将组件接口的声明与实现分离, 只对客户曝露组件接口, 同时隐藏实现和位置23Method _Bmethod _AExplicit Interface (显式接口)method _B _impmethod _A_ imp客户客户接口接口实现实现多态分派组件组件24误解与陷阱l 企图将所有软件开发活动和工件变成模式n 企图将每个新颖的和复杂的设计贴上模式的标签n 将模式看成一些固定不变的事物: 如特定的类配置n 将模式看作编码指南n 有限或误解的模式词汇导致对

14、给定问题使用了错误的模式n 企望机械应用模式就可以得到精致的架构25误解与陷阱n 企图在需要新思想的软件开发中使用现成模式n 对模式如何起作用以及怎样起作用企望过高n 企图完全基于自动化工具使用模式n 将模式当作组件的简单集合n 认为基于模式的设计排斥或替代重构262.2 模式分类l 按粒度分类n 架构, 设计, 惯用法l 按效果好坏分类n 模式, 反模式l 按问题域(使用目的)分类 (以分布式计算为例)n 从混沌到结构n 分布式基础设施n 事件多路分离和分派n 接口分割n 组件分割27n 应用程序控制n 并发n 同步n 对象交互n 适配与扩展n 模态(modal)行为n 资源管理 (对象生命

15、周期管理)n 数据库访问3. 常用模式28常用模式l 从混沌到结构l 分布式基础设施l 事件多路分离和分派l 接口分割l 组件分割l 应用程序控制l 并发l 同步l 对象交互l 适配与扩展l 模态(modal)行为l 资源管理l 数据库访问293.1 从混沌到结构303.1 从混沌到结构l从混沌到结构n将需求和约束转换为粗粒度的软件结构 各部分定义清晰,可操作 抽象与划分, 忽略细节n关注 性能, 持续可用性 可扩展性, 可维护性 支持变化313.1 从混沌到结构l 领域建模n满足应用领域的功能性需求, 同时适应变化 功能属性 业务流程 业务算法选择Domain Model32Domain M

16、odel (领域模型)l 背景n 为应用建立初始结构l 问题需求和约束只是隐含了功能, 但还不能为应用提供直接具体的开发结构对系统范围和应用领域缺乏精确和合理的洞见, 会使实现成为一团烂泥,难于理解, 难于开发, 不易交付l 作用力(force)需求列表只是应用的问题域, 而不是解域, 需要映射为软件实体建立一个模型建立一个模型, 定义系统的业务职责范围以及可能的变化定义系统的业务职责范围以及可能的变化:模型元素是对应用领域的概念抽象模型元素是对应用领域的概念抽象, 它们的角色和交互反它们的角色和交互反映了应用领域的工作流映了应用领域的工作流33从混沌到结构l 分解领域模型n 应用与环境怎样交

17、互?n 应用怎样处理数据?n 应用支持什么变化?n 应用的预期生命周期如何?34Domain Model (领域模型)内部划分数据流处理数据驱动处理系统演进用户界面变化功能变化远程通信Domain ModelDomain ObjectPipes and FiltersShared RepositoryBlackboardLayersDatabaseAccess LayerModel-View-ControllerPresentationAbstraction-ControlMicrokernelReflectionBrokerMessagingPublisher-Subscriber35Lay

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

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

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

21、somethingupdateget datafunction 2function1data 1data 2data 3notifyUser InterfaceModelViewController1. invoke2. modify3. start change notification4. notify5. updatestateApplicationFunctionality41Presentation-Abstraction-Control (PAC)l 背景n 有时要考虑应用的不同功能职责需要不同范式的用户界面l 问题n 通过一种界面如表单,菜单,对话框等, 应用程序就可以提供人机交

22、互, 但是有时候某些应用程序需要对不同的功能提供不同范式的界面, 以达到最佳的操作性l 作用力(force)n 比如在机器人控制系统中, 定义某项任务和控制机器人完成该任务需要不同的用户界面, 但是必须保证所有的功能及其对应的用户界面内聚一致n 某一界面的改变不能影响其对应的功能和其他功能-界面n 某一功能实现的改变也不能影响其对应的界面和其他的功能-界面 将交互式应用划分为解耦的代理将交互式应用划分为解耦的代理agents层级结构层级结构: 一个顶层根代理一个顶层根代理, 几个中间级代理几个中间级代理,以及许多底层代理以及许多底层代理. 每个代理完成应用的某项功能每个代理完成应用的某项功能,

23、 并提供对应的用户界面并提供对应的用户界面42Presentation-Abstraction-Control (PAC)do somethingdisplaymediatefunction_2function_1PresentationControlAbstractiondo somethingdisplaymediatefunction_2function_1do somethingdisplaymediatefunction_2function_1do somethingdisplaymediatefunction_2function_1do somethingdisplaymediat

24、efunction_2function_1协调协调协调协调协调协调协调协调顶层顶层 PAC Agent中间层中间层 PAC Agent底层底层PAC Agent43MVC and PAC: 问题用户界面分离视图种类控制器种类请求处理用户界面分离变化传播模型划分数据交换OS/库独立变化传播代理划分数据交换请求路由控制设计子系统设计Model-ViewControllerPresentationAbstractionControlDomain Model什么模式可以提供解决方案什么模式可以提供解决方案?44Microkernel (微内核)l 背景n 设计支持不同部署环境下功能的可伸缩性和的适应性

25、l 问题n 某些系统有多个版本, 每个版本或者提供不同的功能集, 或者在某一方面与前一版本不同. 但是所有的版本应该基于共同的架构和核心功能l 作用力(force)n 避免架构在不同版本间产生漂移, 使共享功能的开发和维护代价降到最小n 应用的版本升级不需要修改系统, 或使修改降到最小n 方便地提供针对不同界面, 不同平台的版本, 以满足客户的环境提供一个公用的最小的核心架构提供一个公用的最小的核心架构. 应用的不同版本通过一应用的不同版本通过一种即插即用的基础设施种即插即用的基础设施, 在此架构上进行扩展在此架构上进行扩展. 45Microkernel (微内核)route requestr

26、egister_ svrunregister_ svrfunction_1function_2function_3displaydo somethingfunction_2function_1function_3External Server (GUI)External Server (API)MicrokernelInternal ServerSystemUser46Microkernel: 问题标准和可选功能分离微内核以及内部服务器划分微内核以及内部服务器划分数据交换外部服务器设计微内核配置请求路由MicrokernelLayers什么模式可以提供解决方案什么模式可以提供解决方案?47Re

27、flection (反射)l 背景n 提供一种设计, 为预期之外变化的演进和集成做准备 问题对长生命周期应用, 支持变化是可持续演进架构的关键. 但是通常很难预测什么会变化以及什么时候发生变化. 作用力(force)变化可能在任何时候发生变化可能在任何尺度上发生对维护者隐藏变化的复杂性, 提供统一的机制支持各种变化将属性将属性, 应用的结构、行为以及状态等的易变方面抽象为应用的结构、行为以及状态等的易变方面抽象为一组元对象一组元对象. 使用两层架构分离元对象和核心应用逻辑使用两层架构分离元对象和核心应用逻辑: 元层次包含元对象元层次包含元对象, 基本层包含应用逻辑基本层包含应用逻辑. 48Re

28、flection (反射)Userconfigureaspect configurepropertyproperty_1Metalobject ProtocolMaintaineraspect_2Metalobjectsdo something function_1User Interfacefunction_1CoreApplicationLogicusesusesMetalLevelBaseLevel49Reflection: 问题监管控制与应用功能分离基本层以及元层的划分元层访问元对象生命周期管理ReflectionDomain Model什么模式可以提供解决方案什么模式可以提供解决方案

29、?50Pipes and Filters (管道-过滤器)l 背景n 提供一种设计, 使应用适合处理数据流 问题某些应用需要处理数据流:输入数据逐级变换为输出数据流使用通常的请求应答式结构不可行，为此要建立一种数据流模型. 作用力(force)系统的各部分对数据流执行明确的不同的动作有些时候需要显式访问中间数据结果数据流模型应该支持增量式读写和处理持续时间长的处理不应成为性能瓶颈将应用任务划分为几个自含的数据处理步骤将应用任务划分为几个自含的数据处理步骤,这些步骤通这些步骤通过其间的数据缓冲区连接成一个数据处理管道过其间的数据缓冲区连接成一个数据处理管道.51inputPipes and Fi

30、lters (管道-过滤器)bufferinputbufferinputInput DeviceOutput DeviceFilter 1Pipe 1Filter 2Filter 2Pipe N-1Filter N52Pipes and Filters :问题层间通过数据流交互管道以及过滤器的划分远程通信数据交换Pipes and FiltersDomain Model什么模式可以提供解决方案什么模式可以提供解决方案?53Shared Repository (共享仓库)l 背景n 提供一种设计, 使应用的各部分操作一组共享数据, 并通过共享数据进行协调 问题某些应用本质上使数据驱动的: 组件之

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

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

33、逐步改进定的中间解决方案逐步改进.56Blackboard (黑板)checkactivatecheckactivatecheckactivateIntermediate SolutionHypothesis 1-Intermediate SolutionHypothesis 2-Intermediate SolutionHypothesis 3Knowledge SourcesBlackboardrunControl.1.确定最佳的知识源, 以修改黑板中的数据2. 激活选中的知识源, 使之修改黑板中的数据57Blackboard , Shared Repository : 问题

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

35、将每个不同的功能封装进一个自我包含的构成块Domain Object (领域对象领域对象)中中59Domain Object (领域对象)Function AFunction BFunction CFunction ZDomain Object 1Function XFunction YDomain Object 2Domain Object 3Domain Object 4Domain Object InterfaceDomain Object Implementation60Domain Object (领域对象)分离接口和实现内部划分内部划分通用领域对象连接接口和实现生命周期控制领域对象

36、配置Domain ObjectDomain ModelLayersModel-View-ControllerPresentationAbstractionControlMicrokernelReflectionPipes and FiltersShared RepositoryBlackboard什么模式可以提供解决方案什么模式可以提供解决方案?613.2 分布式基础设施62分布式基础设施l 分布式基础设施软件是一种中间件 (middleware)n 应用程序之下, 操作系统和网络之上n 屏蔽来自不同操作系统和网络的固有复杂性和偶发复杂性 固有复杂性: 选择合适的通信机制, 并设计良好的协议来

37、有效使用这些机制 设计合理的网络服务, 以有效利用现有计算资源, 并降低将来的维护成本 有效使用并发机制, 使系统获得可预计的, 可靠的高性能 管理和配置服务, 以获得最大程度的系统可用性和灵活性63偶发复杂性:缺乏类型安全, 可移植, 可扩充的原始OS API算法分解的广泛使用, 无谓造成网络应用程序在维护和扩充上的困难网络应用中, 核心概念和功能的不断发现和创造, 造成软件生命周期的成本无谓地居高不下l 有各种中间件可供选择n CORBA, .Net Remoting, the Microsoft Communication Framework, JMSl 了解这些中间件使用的设计模式,

38、有助于选择正确的中间件l 这些中间件使用了三种基本的通信方式: messaging, publish/subscribe, remote method invocation , 基本上对应三种模式分布式基础设施64分布式基础设施模式模式通信方式通信方式通信关系通信关系组件依赖性组件依赖性Broker (代理者)远程方法调用一对一组件接口Messaging (消息传递)消息多对一通讯终点, 消息格式Publisher-Subscriber (发布者-订阅者)事件一对多事件格式65Messaging (消息传递)l 背景n 需要一个通信的基础设施, 将独立开发的服务组成一个统一的系统 问题某些分布

39、式系统是由独立开发的服务组成, 这些服务必须可靠地交互, 但又不能导致过紧的依赖关系 作用力(force)集成现有的、独立的特定服务以构成企业级解决方案被集成的服务需要可靠地协调工作, 但这些服务是独立开发的, 并不知道彼此的功能接口每个服务可能要被多个集成环境使用, 服务对不同的集成环境不能具有排他性 将服务通过一个消息总线连接起来将服务通过一个消息总线连接起来, 并通过它异步传输数据并通过它异步传输数据消息消息. 对消息编码对消息编码, 使发送者和接受者能够可靠地通信使发送者和接受者能够可靠地通信, 而不而不需要知道数据的所有静态类型信息需要知道数据的所有静态类型信息.66Messagin

40、g (消息传递)Message BusService 1Service 2Service 3Service 4data msg 1data msg 2data msg3data msg 4关键应用关键应用: Enterprise Application Integration, Service Oriented Architecture67Messaging (消息传递)Publisher-Subscriber (发布者-订阅者):问题进程间通信进程间通信数据转移数据封装数据格式转换数据路由错误通知MessagingPublisher-SubscriberDomain Model组件连接数据格

41、式转换数据路由错误通知事件封装事件转移组件连接事件过滤什么模式可以提供解决方案什么模式可以提供解决方案?68Publisher-Subscriber (发布者-订阅者)l 背景n 需要一种通信基础设施, 当某事件发生时, 系统中感兴趣的组件可以彼此通告 问题某些分布式系统是由松散耦合,基本独立的组件构成. 如果这种系统需要在各组件间传播信息, 则需要某种机制来通知各组件有关系统状态的变化, 或其他事件, 这些事件会影响各组件本身的计算或组件间的协调工作 作用力(force)通告机制不能造成各组件的耦合过于紧密接收事件的那些组件只知道系统中有某个组件处于特定状态, 但不关心具体是哪个组件处于该状

42、态散布事件的组件也不关心哪个组件会接收它 各组件不知道彼此的位置定义一种变化传播基础设施定义一种变化传播基础设施, 发布者发布者(publisher)通过它发通过它发布事件布事件, 其他发布者可能对该事件包含的信息感兴趣其他发布者可能对该事件包含的信息感兴趣. 事事件发生时要告知对该事件感兴趣的订阅者件发生时要告知对该事件感兴趣的订阅者(subscriber).69Change Propagation InfrastructurePublisher 1Subscriber 2Subscriber 3Publisher 2State changeState changeState changeS

43、tate changePublisher-Subscriber (发布者-订阅者)应用应用: CORBA Notification Service70Messaging (消息传递)Publisher-Subscriber (发布者-订阅者):问题进程间通信进程间通信数据转移数据封装数据格式转换数据路由错误通知MessagingPublisher-SubscriberDomain Model组件连接数据格式转换数据路由错误通知事件封装事件转移组件连接事件过滤什么模式可以提供解决方案什么模式可以提供解决方案?71Broker (代理者)l 背景n 需要一种通信基础设施, 以之屏蔽组件位置和进程间

44、通信的复杂性 问题分布式应用要面对许多单进程应用未有的挑战, 但是应用不应该自己直接去处理这些挑战. 应用应该使用模块化的编程模型, 力求简化, 以屏蔽网络连接和空间位置等细节 作用力(force)将不同语言写的各类服务移植到不同的操作系统平台, 是一项极其复杂的任务在何处以什么方式部署服务, 也是一项复杂费力的事情服务之间通过方法调用的协作应该以一种与位置无关的方式进行使用代理者使用代理者(broker)联盟封装分布式系统通信基础设施的联盟封装分布式系统通信基础设施的细节细节, 并与应用系统的功能分离并与应用系统的功能分离. 要定义一种基于组件的编要定义一种基于组件的编程模型程模型, 以使客

45、户应用调用远程服务的方法时就象在本地调以使客户应用调用远程服务的方法时就象在本地调用一样用一样.72method_1method_2Broker (代理者)sendreceiverequestdiscoverreceivesendinvokeregistermethod_1method_2clientClientProxyClient-sideBrokerServer-sideBrokerApplicationComponentDiscover client proxyRegister componentNetwork73Broker (代理者): 问题进程间通信BrokerDomain Ob

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

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

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

49、gin # 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); rofendhandle eventhandle eventhandle eventEvent handlersStart event processingReactorOperating SystemSend

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

51、作和完成处理器共同实现应用的服务逻辑处理器共同实现应用的服务逻辑. 异步操作由操作系统执行异步操作由操作系统执行, 而完成处而完成处理器在应用的控制线程中执行理器在应用的控制线程中执行79event loopProactor (前摄器)A clientdemux eventhandle _event (Event event)begin # Process the received event if (event. type=Request) # read request asynchronously # and return control async _read(); elseif (ev

52、ent. Type =READ_COMPLETE) # Process event, deliver results # asynchronously, and return control process_ data(); async _write(); fiendhandle eventhandle eventCompletion handlersStart event processingProactorOperating SystemSend service request event1324async writeasync read80Reactor (反应器), Proactor

53、(前摄器):问题ReactorProactorServer Request HandlerClient RequestHandler同步事件处理异步事件处理异步事件处理同步事件处理实现的变化实现的变化事件处理器类型事件处理器类型事件源封装事件源封装并发事件处理并发事件处理并发事件处理事件处理器分派完成处理器分派什么模式可以提供解什么模式可以提供解决方案决方案?81Acceptor-Connector(接受器-连接器)l 背景n 在面向连接的网络系统中实现事件处理器时, 建立连接以及初始化事件处理器等基本活动需要与处理应用特定服务的功能分离 问题网络系统中对等的事件处理器在执行其服务功能前需要先

54、建立连接并初始化, 建立连接以及初始化代码与其服务功能基本无关 作用力(force)事件处理器服务的变化比连接建立和初始化策略的变化快事件处理器可能动态改变其在连接中的角色在网络系统中在网络系统中, 将对等事件处理器的连接和初始化与之后执将对等事件处理器的连接和初始化与之后执行的服务解耦行的服务解耦82connect134serviceinitAcceptor-Connector (接受器-连接器)acceptserviceinitconnectoracceptorService handlerConnect mePass connection3Pass connectionPerform w

55、ork2AcceptconnectionService handlerA peer componentAnother peer component83Acceptor-Connector (接受器-连接器):问题Acceptor-ConnectorServer Request HandlerClient RequestHandlerProactor事件处理器类型Reactor事件处理器类型完成处理器类型创建服务处理器封装IPC机制管理事件处理器连接管理的变化并发服务处理器84Asynchronous Completion Token (异步完成令牌)l 背景n 在使用异步通信的系统中, 需要高

56、效地多路分离和处理对异步服务请求的响应 问题客户端异步调用服务, 其响应通过完成事件返回, 并在客户端处理. 客户端调用服务后不能被阻塞, 客户端在完成事件到达时的状态与调用服务时的状态不同 作用力(force)客户需要在合适的背景下处理异步响应客户判断如何处理异步响应的时间要尽可能短异步响应到达的顺序与请求发起的顺序可能不同客户在发起每个异步服务请求的同时客户在发起每个异步服务请求的同时, 传输一个异步完成令牌传输一个异步完成令牌, 该令牌该令牌包含足够的信息包含足够的信息, 可以让客户知道如何处理服务完成后的返回结果可以让客户知道如何处理服务完成后的返回结果85dispatch134dis

57、patchserviceAsynchronous Completion Token (异步完成令牌)Client2process resultasync_ operationSend requestReturn responseDispatch resultProcess resultACTService86Asynchronous Completion Token (异步完成令牌): 问题AsynchronousCompletion TokenFuture未来通告完成处理器通告ProactorACT管理873.4 接口分割l 组件接口要告知客户其职责, 提供的服务, 以及使用契约l 利于客户

58、正确有效地与之合作l 设计高质量的组件接口, 需要解决的问题 组件的职责与契约规范 质量属性 描述性和简单性 松耦合和稳定性 组件的分布性 组件及其客户的异质性 88接口分割l 相关模式n Explicit Interface (显式接口)n Extension Interface (扩展接口)n Introspective Interface (内省接口)n Dynamic Invocation Interface (动态调用接口)n Business Delegate (业务代理)n Proxy (代理)n Faade (外观)n Combined Method (组合方法)n Itera

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

60、口的声明与实现分离, 只对客户曝露组件接口只对客户曝露组件接口, 同同时隐藏实现和位置时隐藏实现和位置90Method _Bmethod _AExplicit Interface(显式接口)method _B _impmethod _A_ impClientInterfaceImplementationPolymorphic dispatchComponent91Explicit Interface (显式接口): 问题Explicit InterfaceDomain ObjectReactorProactorCommandInterceptorChain of ResponsibilityItera