浙江大学王灿软件体系结构视频课程可用性和可修改性设计.pptx

《浙江大学王灿软件体系结构视频课程可用性和可修改性设计.pptx》由会员分享，可在线阅读，更多相关《浙江大学王灿软件体系结构视频课程可用性和可修改性设计.pptx（25页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、实现质量属性上节课讨论了各种系统质量属性，却没有谈及如何实现这些质量属性质量属性的实现依赖于我们称之为“战术”的基本构架决策给定一个质量属性，“战术”帮助构架师使用相应的构架策略或模式来进行设计，达成响应的质量属性质量属性需求构架决策第1页/共25页战术什么使得不同的设计表现出不同的质量特性可移植性高性能可集成性“战术”是影响质量属性响应控制的设计决策战术的集合系统设计有决策集合组成有些决策确保系统功能的实现有些决策帮助控制质量属性“战术”“战术”是构架师所使用的设计方法第2页/共25页战术示例一个典型的战术示例是通过“引入冗余”来提高系统可用性这往往意味着系统中要有响应的同步机制该示例揭示战

2、术可以进一步的被精练比如：冗余战术可以被进一步的被精练为数据冗余和计算冗余，通常我们以层次结构的形式组织战术模式是战术的打包第3页/共25页可用性战术可用性的回顾定义故障 VS.错误=平均正常工作时间/(平均正常工作时间+平均修复时间)可用性战术将阻止错误发展成故障或将错误影响限制在一定范围内，从而使修复成为可能保持可用性的方法通常包括：一些冗余一些检测故障的监控机制一些恢复机制控制可用性的战术错误错误被屏蔽或系统被修复第4页/共25页错误检测战术命令/响应（Ping/echo）层次形式组织的“命令/响应”错误检测机制心跳（“死人计时器”）一个组件定时发出一个心跳消息，另一个组件接听该消息异常

3、/中断通过抛出异常来识别错误，异常处理程序通常在同一进程内捕获并处理异常第5页/共25页错误恢复战术错误恢复通常由两部分组成准备恢复恢复系统常用的准备和恢复战术表决主动冗余 被动冗余备件重新引入第6页/共25页表决战术(1)运行在冗余处理器上的每个进程都具有相等的输入，它们计算发给表决器的一个简单的输出值。如果表决器检测到单个处理器的异常行为，那么就中止这一行为常用的表决算法多数规则首选组件第7页/共25页表决战术(2)表决战术可以用于纠正算法的错误或处理器的错误，或者某个模块或组件的错误如果出现故障会带来严重的后果，则冗余组件可能是多样的每个冗余组件的软件由不同小组开发在不同的平台上执行.第

4、8页/共25页主动冗余（热启动）战术所有冗余组件在启动的时候同步，以并行的方式对时间作出响应，因而它们都处在相同的状态。通常，作出响应的第一个组件的结果被采用，其他响应被丢弃组件间的同步是通过将传递给任何冗余组件的消息发送给所有冗余组件发生错误时，使用该战术的系统的停机时间通常是几毫秒恢复时间就是组件间的切换时间，因为冗余组件间状态一致，备份都是最新的在高可用性的分布式系统中，冗余可能在通信路径上第9页/共25页被动冗余战术一个组件（主组件）对事件作出响应，并通知其他组件（备用组件）它们必须进行的状态更新同步是主组件的责任，它可以通过对备用组件的原子广播来保证同步当系统发生错误时首先要确保备用

5、组件的状态时最新的该战术依赖与备用组件对工作进行可靠接管第10页/共25页备件战术在备件战术中，配置有相应的备件平台来取代各种出故障的组件当故障出现时，备件必须启动并进行相应的配置，对状态进行初始化，才能替代出故障的组件进行同步并对故障的组件进行接管时，往往使用检查点（checkpoint）日志（logging）的技术第11页/共25页重新引入战术该战术依赖于对发生故障的组件进行纠正后的重新引入shadow操作：以前出现故障的组件在短时间内以“shadow模式”（类似于测试模式）运行，以确保它能够胜任工作组件的要求状态再同步：重新引入后，最好能用一条消息就将状态刷到最新检查点/回滚：使用类似于

6、数据库中的恢复机制的技术第12页/共25页错误预防战术从服务中删除从操作中删除系统的一个组件，以执行某些活动来防止预期发生的故障。例如：重新启动组件，以防内存泄漏导致故障发生事务处理几个有序步骤的绑定，是的这些步骤都能被完成或撤销，保证一致性，防止冲突进程监视器检测到进程中的错误后，将之删除并重新创建一实例并初始化状态第13页/共25页可用行战术层次结构可用性可用性命令/响应心跳异常表决主动冗余被动冗余备件从服务中删除事务进程监视器Shadow状态再同步检查点/回滚准备恢复准备恢复和修复和修复故障检测故障检测重新引入重新引入错误预防错误预防故障故障被屏蔽或修复第14页/共25页可修改性战术目标

7、：控制实施、测试和部署修改的时间和成本n提高可修改性的主要方法q局部化修改q防止连锁反应 q延迟绑定时间控制可修改性的战术变更到达在预算范围内实施修改测试修改部署修改第15页/共25页局部化修改(1)一般来说（尽管不是非常精确），修改的模块越少，修改的成本就越低这组战术的目标是在设计期间为模块分配责任，以把预期的变更限定在一定范围内维持语义的一致性语义一致性指模块中责任间的关系。目标是确保这些责任能够协同工作，不需过多依赖其他模块“抽象通用服务”预期期望的变更考虑预想的变更为责任或功能的分配提供指导实际使用中，该战术实施会有困难，因为很难预期所有变更第16页/共25页局部化修改(2)泛化模块泛

8、化模块（使一个模块更加通用）可以使它根据根据输入计算更广泛的功能可以将一个模块的输入看成是该模块定义的一种语言可以在语言上应对修改，而不必去修改模块限制可能的选择修改（尤其在产品线中）的范围可能非常大，因此可能会影响很多模块限制可能的选择可以见地这些修改造成的影响第17页/共25页连锁反应&模块依赖性修改所产生的连锁反应就是需要改变该修改并没有直接影响到的模块比如：模块B依赖于模块A，那么修改了模块A后，有可能相应的必须修改模块B连锁反应的原因是模块间的依赖性，常见的依赖性包括语法数据：要使B能正确编译和执行，由A产生并由B使用的数据语义必须与B的假定一致服务：要使B能正确编译和执行，由A提供

9、并由B调用的服务的签名必须与B的假定一致语义数据&服务：要使B能正确执行，由A提供并由B使用的数据或调用的服务必须与B的假定一致第18页/共25页模块依赖性(2)顺序数据：要使B能正确执行，它必须以一个固定的顺序接收由A产生的数据（比如：包头要比包体先接收）控制：要使B能正确执行，A必须在一定的时间限制内执行A的一个接口身份A的接口身份（名称或句柄）要与B的假设一致A的运行时位置要使B能正确执行，A的运行时位置必须与B的假定一致A提供的服务/数据的质量A的存在A的资源行为第19页/共25页防止连锁反应(1)下面的战术，并不能一定组织语义变更造成的连锁反应信息隐藏将某个模块的责任分解成更小的部分

10、，并选择哪些部分为公有（可见），哪些为私有（隐藏）维持现有的接口如果B依赖于A的一个接口名或签名，则维持该接口和其语法可以使B保持不变通常可以用以下战术来达到这点添加接口添加适配器（提供原始A的签名）提供一个占位程序A（stub）限制通讯路径与一个被修改的模块交互的模块越少，被影响到的模块也越少第20页/共25页防止连锁反应(2)使用中间件：A 中间件 B（非语义型依赖）数据（语法）：存储库充当数据的生成者和使用者之间的中间件服务：faade、桥、mediator、代理、工厂模式等都能将服务的语法从一种形式转为另一种形式A的接口身份：使用Broker模式A的运行时位置：使用名称服务器A的资源行

11、为或A控制的资源：使用资源管理器A的存在：使用工厂模式第21页/共25页延迟绑定时间前面两类战术的目标是使实现修改所要求改变的模块数量最少，但是可修改性同时也该包括：部署时间允许非开发人员进行修改推迟绑定时间支持这两种场景，但是需要额外的基础结构支持静态绑定 VS.动态绑定第22页/共25页延迟绑定时间策略运行时注册支持软件实体的即插即用，但是需要管理注册的模块配置文件在启动时进行参数设置多态性允许方法调用的后期绑定，从而使对象有不同的动态行为遵守已定义的协议允许独立进程运行时绑定第23页/共25页可修改性战术层次结构可修改性可修改性语义一致性预期修改泛化模块限制可能的选项抽象共同服务运行时注册配置文件组件替代遵循已定义协议隐藏信息保持现有接口限制通讯途径使用中间件局部化修改局部化修改防止连锁反应防止连锁反应延迟绑定时间延迟绑定时间更改到达作出更改，测试和部署更改第24页/共25页感谢您的观看！第25页/共25页