52浙江大学王灿《软件体系结构》视频课程5-可用性和可性设计省公开课一等奖全国示范课微课金奖课.pptx

单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,*,实现质量属性(1),1/25,实现质量属性,上节课讨论了各种系统质量属性，却没有谈及怎样实现这些质量属性,质量属性实现依赖于我们称之为“战术”基本构架决议,给定一个质量属性，“战术”帮助构架师使用对应构架策略或模式来进行设计，达成响应质量属性,质量属性需求,构架决议,2/25,战术,什么使得不一样设计表现出不一样质量特征,可移植性,高性能,可集成性,“战术”是影响质量属性响应控制设计决议,战术集合,系统设计有决议集合组成,有些决议确保系统功效实现,有些决议帮助控制质量属性“战术”,“战术”是构架师所使用设计方法,3/25,战术示例,一个经典战术示例是经过“引入冗余”来提升系统可用性,这往往意味着系统中要有响应同时机制,该示例揭示,战术能够深入被精练,比如：冗余战术能够被深入被精练为数据冗余和计算冗余，通常我们以层次结构形式组织战术,模式是战术打包,4/25,可用性战术,可用性回顾,定义,故障 VS.错误,=平均正常工作时间/(平均正常工作时间+平均修复时间),可用性战术,将阻止错误发展成故障,或将错误影响限制在一定范围内，从而使修复成为可能,保持可用性方法通常包含：,一些冗余,一些检测故障监控机制,一些恢复机制,控制可用,性战术,错误,错误被屏蔽,或系统被修复,5/25,错误检测战术,命令/响应Ping/echo）,层次形式组织“命令/响应”错误检测机制,心跳（“死人计时器”）,一个组件定时发出一个心跳消息，另一个组件接听该消息,异常/中止,经过抛出异常来识别错误，异常处理程序通常在同一进程内捕捉并处理异常,6/25,错误恢复战术,错误恢复通常由两部分组成,准备恢复,恢复系统,惯用准备和恢复战术,表决,主动冗余,被动冗余,备件,重新引入,7/25,表决战术(1),运行在冗余处理器上每个进程都含有相等输入，它们计算发给表决器一个简单输出值。假如表决器检测到单个处理器异常行为，那么就中止这一行为,惯用表决算法,多数规则,首选组件,8/25,表决战术(2),表决战术能够用于纠正算法错误或处理器错误，或者某个模块或组件错误,假如出现故障会带来严重后果，则冗余组件可能是多样,每个冗余组件软件由不一样小组开发,在不一样平台上执行.,9/25,主动冗余（热开启）战术,全部冗余组件在开启时候同时，以并行方式对时间作出响应，因而它们都处于相同状态。通常，作出响应第一个组件结果被采取，其它响应被丢弃,组件间同时是经过将传递给任何冗余组件消息发送给全部冗余组件,发生错误时，使用该战术系统停机时间通常是几毫秒,恢复时间就是组件间切换时间，因为冗余组件间状态一致，备份都是最新,在高可用性分布式系统中，冗余可能在通信路径上,10/25,被动冗余战术,一个组件（主组件）对事件作出响应，并通知其它组件备用组件）它们必须进行状态更新,同时是主组件责任，它能够经过对备用组件原子广播来确保同时,当系统发生错误时,首先要确保备用组件状态时最新,该战术依赖与备用组件对工作进行可靠接管,11/25,备件战术,在备件战术中，配置有对应备件平台来取代各种出故障组件,当故障出现时，备件必须开启并进行对应配置，对状态进行初始化，才能替换出故障组件,进行同时并对故障组件进行接管时，往往使用检验点（checkpoint）日志（logging）技术,12/25,重新引入战术,该战术依赖于对发生故障组件进行纠正后重新引入,shadow操作：以前出现故障组件在短时间内以“shadow模式”（类似于测试模式）运行，以确保它能够胜任工作组件要求,状态再同时：重新引入后，最好能用一条消息就将状态刷到最新,检验点/回滚：使用类似于数据库中恢复机制技术,13/25,错误预防战术,从服务中删除,从操作中删除系统一个组件，以执行一些活动来预防预期发生故障。比如：重新开启组件，以防内存泄漏造成故障发生,事务处理,几个有序步骤绑定，是这些步骤都能被完成或撤消，确保一致性，预防冲突,进程监视器,检测到进程中错误后，将之删除并重新创建一实例并初始化状态,14/25,可用行战术层次结构,可用性,命令/响应,心跳,异常,表决,主动冗余,被动冗余,备件,从服务中删除,事务,进程监视器,Shadow,状态再同时,检验点/回滚,准备恢复和修复,故障检测,重新引入,错误预防,故障,故障被,屏蔽或,修复,15/25,可修改性战术,目标：控制实施、测试和布署修改时间和成本,提升可修改性主要方法,局部化修改,预防连锁反应,延迟绑定时间,控制可修改,性战术,变更抵达,在预算范围内,实施修改,测试修改,布署修改,16/25,局部化修改(1),普通来说（尽管不是非常准确），修改模块越少，修改成本就越低,这组战术目标是在设计期间为模块分配责任，以把预期变更限定在一定范围内,维持语义一致性,语义一致性指模块中责任间关系。目标是确保这些责任能够协同工作，不需过多依赖其它模块,“抽象通用服务”,预期期望变更,考虑预想变更为责任或功效分配提供指导实际使用中，该战术实施会有困难，因为极难预期全部变更,17/25,局部化修改(2),泛化模块,泛化模块（使一个模块愈加通用）能够使它依据依据输入计算更广泛功效,能够将一个模块输入看成是该模块定义一个语言,能够在语言上应对修改，而无须去修改模块,限制可能选择,修改（尤其在产品线中）范围可能非常大，所以可能会影响很多模块,限制可能选择能够见地这些修改造成影响,18/25,连锁反应&模块依赖性,修改所产生连锁反应就是需要改变该修改并没有直接影响到模块,比如：模块B依赖于模块A，那么修改了模块A后，有可能对应必须修改模块B,连锁反应原因是模块间依赖性，常见依赖性包含,语法,数据：要使B能正确编译和执行，由A产生并由B使用数据语义必须与B假定一致,服务：要使B能正确编译和执行，由A提供并由B调用服务署名必须与B假定一致,语义,数据&服务：要使B能正确执行，由A提供并由B使用数据或调用服务必须与B假定一致,19/25,模块依赖性(2),次序,数据：要使B能正确执行，它必须以一个固定次序接收由A产生数据（比如：包头要比包体先接收）,控制：要使B能正确执行，A必须在一定时间限制内执行,A一个接口身份,A接口身份（名称或句柄）要与B假设一致,A运行时位置,要使B能正确执行，A运行时位置必须与B假定一致,A提供服务/数据质量,A存在,A资源行为,20/25,预防连锁反应(1),下面战术，并不能一定组织语义变更造成连锁反应,信息隐藏,将某个模块责任分解成更小部分，并选择哪些部分为公有（可见），哪些为私有（隐藏）,维持现有接口,假如B依赖于A一个接口名或署名，则维持该接口和其语法能够使B保持不变通常能够用以下战术来到达这点,添加接口,添加适配器（提供原始A署名）,提供一个占位程序A（stub）,限制通讯路径,与一个被修改模块交互模块越少，被影响到模块也越少,21/25,预防连锁反应(2),使用中间件：A,中间件,B（非语义型依赖）,数据（语法）：存放库充当数据生成者和使用者之间中间件,服务：faade、桥、mediator、代理、工厂模式等都能将服务语法从一个形式转为另一个形式,A接口身份：使用Broker模式,A运行时位置：使用名称服务器,A资源行为或A控制资源：使用资源管理器,A存在：使用工厂模式,22/25,延迟绑定时间,前面两类战术目标是使实现修改所要求改变模块数量最少，不过可修改性同时也该包含：,布署时间,允许非开发人员进行修改,推迟绑定时间支持这两种场景，不过需要额外基础结构支持,静态绑定 VS.动态绑定,23/25,延迟绑定时间策略,运行时注册,支持软件实体即插即用，不过需要管理注册模块,配置文件,在开启时进行参数设置,多态性,允许方法调用后期绑定，从而使对象有不一样动态行为,恪守已定义协议,允许独立进程运行时绑定,24/25,可修改性战术层次结构,可修改性,语义一致性,预期修改,泛化模块,限制可能选项,抽象共同服务,运行时注册,配置文件,组件替换,遵照已定义协议,隐藏信息,保持现有接口,限制通讯路径,使用中间件,局部化修改,预防连锁反应,延迟绑定时间,更改,抵达,作出更改，,测试和,布署更改,25/25,