04系统架构之六大战术-应对质量属性

ZPEDU.ORG讲义版权由中培教育所有，未经同意，不得转印软件系统架构实践中国信息化培训中心2013年6月ZPEDU.ORG讲义版权由中培教育所有，未经同意，不得转印课程目录一、系统架构概述二、系统架构之三分过程三、系统架构之四入策略四、系统架构之六大战术五、系统架构之案例探究六、系统架构之评估体系七、系统架构师成长之路ZPEDU.ORG讲义版权由中培教育所有，未经同意，不得转印四、系统架构之六大战术（一）影响软件架构的因素（二）理解质量属性（三）质量属性战术应对ZPEDU.ORG讲义版权由中培教育所有，未经同意，不得转印（三）质量属性战术应对1、可用性战术2、可修改性战术3、性能战术4、安全性战术5、可测试性战术6、易用性战术ZPEDU.ORG讲义版权由中培教育所有，未经同意，不得转印战术介绍质量需求指定了软件的响应，以实现业务目标战术（tactics）——影响质量属性响应的设计决策构架策略（architecturalstrategy）——战术的集合构架模式（architecturalpattern）——以某种方式将战术打包在一起ZPEDU.ORG讲义版权由中培教育所有，未经同意，不得转印质量属性战术是什么使一个设计具有了可移植性？一个设计有了高性能，而另一个设计具备了可集成性？实现这些质量属性依赖于基本的设计决策——战术战术就是影响质量属性响应控制的设计决策可用性战术可修改性战术性能战术安全性战术可测试性战术易用性战术战术的集合称为“构架设计策略”ZPEDU.ORG讲义版权由中培教育所有，未经同意，不得转印可用性战术目标可用性战术将会阻止错误发展为故障，或者至少能够把错误的影响限制在一定范围内，从而使系统恢复成为可能控制可用性的战术错误所屏蔽的错误或所作的修改可用性战术的目标ZPEDU.ORG讲义版权由中培教育所有，未经同意，不得转印可用性战术分类维持可用性的方法包括：1.错误检测——用来检测故障的某种类型的健康监视2.自动恢复——检测到故障时某种类型的恢复3.错误预防——阻止错误演变为故障ZPEDU.ORG讲义版权由中培教育所有，未经同意，不得转印可用性战术分类可用性战术总结可用性错误所屏蔽的错误或所作的修改错误检测恢复：监测和修复预防信号/响应心跳异常表决主动冗余被动冗余备件Shadow状态再同步回滚从服务中删除事物进程监视器恢复：重新引入ZPEDU.ORG讲义版权由中培教育所有，未经同意，不得转印错误检测错误检测包括以下3个战术1.信号/响应（ping/echo）：一个组件发出一个信号，并希望在预定义的时间内收到一个来自审查组件的响应，该战术可以用在共同负责某项任务的一组组件内这种战术采用组件主动询问方式，就好像我们在课堂上点名一样，必须要求学生回答ZPEDU.ORG讲义版权由中培教育所有，未经同意，不得转印错误检测2.心跳（heartbeat）：一个组件定期发出一个心跳信息，另一个组件收听该信息。心跳还可用于传递数据这种方式监视组件采用被动方式，就好像领导听取员工汇报工作这两种战术在不同的进程中进行操作ZPEDU.ORG讲义版权由中培教育所有，未经同意，不得转印错误检测3.异常（exceptions）：异常处理程序通常将错误在语义上转换为可以被处理的形式，异常通常与引入异常的程序在同一个进程中比如：if(x==0){throwException()}ZPEDU.ORG讲义版权由中培教育所有，未经同意，不得转印错误恢复——表决有6种错误恢复的战术1.表决（voting）：运行在冗余处理器上的每个进程都具有相等的输入，它们计算的值都发给表决者，表决者发现异常则终止进程表决算法包括“多数规则”、“首选组件”等该方法用于纠正算法的错误操作或处理器的故障，通常用在控制系统中ZPEDU.ORG讲义版权由中培教育所有，未经同意，不得转印表决冗余处理器表决者组件冗余组件冗余组件冗余组件输入值输出值用一定的表决算法进行表决；多数规则或首选组件如果检测到单处理器的异常行为，则终止它或重起它。ZPEDU.ORG讲义版权由中培教育所有，未经同意，不得转印错误恢复——主动冗余2.主动冗余（Activeredundancy）：所有的冗余组件都以并行的方式对事件做出响应，它们的状态都相同，但每次只使用一个组件的响应而丢弃其余组件的响应主动冗余通常用在客户机/服务器的配置中，在这种配置中，即使发生错误，也可在极短的时间，通常为几毫秒内恢复，比如门户网站采取的策略ZPEDU.ORG讲义版权由中培教育所有，未经同意，不得转印主动冗余（热重启）同时响应使用第一个组件的响应处在相同的状态切换ZPEDU.ORG讲义版权由中培教育所有，未经同意，不得转印错误恢复——被动冗余3.被动冗余（passiveredundancy）：主组件对事件做出响应，并通知其它备用组件必须进行的状态更新。这样，主/从组件的状态是一致的被动冗余通常用在控制系统中，恢复时间一般在几秒内在被动冗余中，主组件负责状态同步ZPEDU.ORG讲义版权由中培教育所有，未经同意，不得转印被动冗余（暖重启）备份OlddataNewdataZPEDU.ORG讲义版权由中培教育所有，未经同意，不得转印错误恢复——备件4.备件（spare）：备件是计算平台配置用于更换各种不同的故障组件。出现故障时，必须将其重新启动为适当的软件配置，并对其状态进行初始化备件通常用在备用客户机工作站，恢复时间一般在几分钟内ZPEDU.ORG讲义版权由中培教育所有，未经同意，不得转印错误恢复——重新引入5.Shadow操作：出现故障的组件可以以“Shadow模式”运行，这样可以在系统恢复前模仿工作组件的行为6.状态再同步（Stateresynchronization）：主动和被动冗余战术要求所恢复的组件在重新提供服务前更新其状态ZPEDU.ORG讲义版权由中培教育所有，未经同意，不得转印错误恢复——重新引入7.检查点/回滚（Checkpoint/rollback）：检查点就是记录所创建的一致状态，遇到故障，可以使用上次正确的检查点状态比如，Windows操作系统的以上一次正常运行的配置启动ZPEDU.ORG讲义版权由中培教育所有，未经同意，不得转印高可用性解决方案现状及问题随着计算机在社会各个领域的广泛使用，人们已习惯于计算机系统带来的便捷和高效率，但计算机系统也非常脆弱，它会受各种因素的影响，如硬件系统本身的故障，电源故障，病毒，自然灾害或人为的恶意破坏，都会导致系统无法正常运行。现有很多系统均是单主机工作环境，任何一个单点故障，都会影响企业业务的正常运转，而且产生很多不良后果。ZPEDU.ORG讲义版权由中培教育所有，未经同意，不得转印我们认为，解决该问题的关键，就是采用高可用性的群集解决方案。在一个承担关键业务的计算中心，采用多台主机共享一套存储设备存储业务数据，主机之间通过物理连接形成一定的相互联系，与相应的群集软件配合，可以实现如下功能：当整套系统中出现任何一个单点故障，都有相应的冗余部件代替发挥相应的功能，从而保证业务的正常进行，在此过程中的物理设备和应用软件的切换都不会被前端用户所察觉。ZPEDU.ORG讲义版权由中培教育所有，未经同意，不得转印解决方案ZPEDU.ORG讲义版权由中培教育所有，未经同意，不得转印ZPEDU.ORG讲义版权由中培教育所有，未经同意，不得转印虚拟服务器ZPEDU.ORG讲义版权由中培教育所有，未经同意，不得转印ZPEDU.ORG讲义版权由中培教育所有，未经同意，不得转印错误预防1.从服务中删除（removalfromservice）：该战术从操作中删除了系统的一个组件，以执行某些活动来防止预期发生的故障，比如重新启动备用组件阻止当前组件的内存泄漏ZPEDU.ORG讲义版权由中培教育所有，未经同意，不得转印错误预防2.事务（transactions）：事务是指绑定几个有序的步骤，以能够立刻撤销这个绑定，可以使用事务来防止任何数据受到影响3.进程监视器（processmonitor）：监视进程中存在的错误，如果发现错误，则删除该执行进程，并为该进程创建一个新的实例ZPEDU.ORG讲义版权由中培教育所有，未经同意，不得转印“系统可用性”质量目标与保障手段30检测手段F5心跳检测、错误日志记录、业务最大并发数控制、后台模块可用性控制在线保障双通道工作模式，主备通道可同时运行，对外提供不停断持续服务；应用服务器多节点集群，提供负载均衡和故障转移；场景描述提供系统对外服务不中断情况下进行系统维护的策略；应用服务器单节点重启控制在3~5分钟之内；最大业务并发预警与控制，单节点最大并发数在应用级动态可控制；决策1.主动禁用有故障模块相关业务功能；2.单节点并发数控制调整，保障系统运行；3.利用系统监控日志定期分析系统瓶颈，持续优化架构质量。ZPEDU.ORG讲义版权由中培教育所有，未经同意，不得转印（三）质量属性战术应对1、可用性战术2、可修改性战术3、性能战术4、安全性战术5、可测试性战术6、易用性战术ZPEDU.ORG讲义版权由中培教育所有，未经同意，不得转印可修改性战术可修改性战术的目标是控制实现、测试和部署变更的时间和成本控制可修改性的战术变更到达在时间和预算内完成、测试和部署的变更可修改性战术的目标ZPEDU.ORG讲义版权由中培教育所有，未经同意，不得转印可修改性战术分类可修改性战术可以分为3类：1.局部化修改——目标是减少由某个变更直接影响的模块的数量2.防止连锁反应——目标是限制对局部化的模块的修改，以防止对某个模块的修改间接地影响到其他模块3.延迟绑定时间——目标是控制部署时间并允许非开发人员进行修改ZPEDU.ORG讲义版权由中培教育所有，未经同意，不得转印可修改性战术分类可修改性战术总结可修改性变更到达在时间和预算内实现、测试和部署的变更局部化变更防止连锁反应语义一致性预期期望的变更泛化模块限制可能的选择抽象通用服务隐藏信息维持现有的接口限制通信路径使用仲裁者运行时注册配置文件多态组件更换遵守已定义的协议推迟绑定时间ZPEDU.ORG讲义版权由中培教育所有，未经同意，不得转印局部化修改(localizemodifications)该组战术的目标是在设计时为模块分配责任，以把预期的变更限制在一定的范围内1.预期期望的变更（expectedchanges）：根据语义一致性原则，预测期望变更的战术并不关心模块责任的一致性，而是关心将变更的影响最小化ZPEDU.ORG讲义版权由中培教育所有，未经同意，不得转印局部化修改(localizemodifications)2.维持语义一致性（semanticcoherence）：语义一致性是模块中责任之间的关系，目标是确保所有这些责任都能够协同工作，不需要过多地依赖其它模块，即这组模块的内聚性维持语义一致性的子战术就是“抽象通用服务”，通过专门的模块提供通用服务通常被视做支持重用，比如设计数学函数sin(x)为通用函数ZPEDU.ORG讲义版权由中培教育所有，未经同意，不得转印局部化修改(localizemodifications)3.泛化模块（Generalizethemodule）：使一个模块更通用能够使他根据输入计算更广泛的功能；模块越通用越有可能通过调整语言而非修改模块来进行请求变更4.限制选择参数（Limitpossibleoptions）：限制可能的选择将会降低这些修改所造成的影响，比如我们将可选择的处理器或操作系统限定在一定的范围内ZPEDU.ORG讲义版权由中培教育所有，未经同意，不得转印防止连锁反应(preventrippleeffects)连锁反应——修改某个模块却影响到其他并没有被修改的模块，我们必须修改所有相关模块（直接影响和间接影响）才能够实现我们的变更目标依赖关系——如果我们根据某种需要修改模块A，那么也必须修改模块B，我们就说模块B依赖于模块AZPEDU.ORG讲义版权由中培教育所有，未经同意，不得转印防止连锁反