室内设计自学教程,聊城哪里做优化网站,潍坊建公司网站,vs做网站怎么放视频个人总结#xff0c;仅供参考#xff0c;欢迎加好友一起讨论 文章目录 架构 - 软件架构的演化与维护考点摘要软件架构演化和定义面向对象软件架构演化对象演化消息演化复合片段演化约束演化 软件架构演化方式静态演化动态演化 软件架构演化原则软件架构演化评估方法大型网站架… 个人总结仅供参考欢迎加好友一起讨论 文章目录 架构 - 软件架构的演化与维护考点摘要软件架构演化和定义面向对象软件架构演化对象演化消息演化复合片段演化约束演化 软件架构演化方式静态演化动态演化 软件架构演化原则软件架构演化评估方法大型网站架构的演化第一阶段单体架构第二阶段垂直架构第三阶段使用缓存改善网站性能第四阶段使用服务集群改善网站并发处理能力第五阶段数据库读写分离第六阶段使用反向代理和CDN加速网站响应第七阶段使用分布式文件系统和分布式数据库系统第八阶段使用NoSQL和搜索引擎第九阶段业务拆分第十阶段分布式服务 软件架构维护软件架构知识管理架构修改管理架构版本管理 架构 - 软件架构的演化与维护
考点摘要
软件架构演化和定义★面向对象软件架构演化★★软件架构演化方式★★软件架构演化原则★★软件架构演化评估★★大型网站架构演化★★软件架构维护★
第二版架构新教材里新增加内容对应第10章新增的内容是关于架构的演化和维护阶段偏理论多而且不像架构风格、质量属性那块容易出题。个人认为会出几个选择题甚至到案例题中有内容涉及。 软件架构一般会经历初始设计、实际使用、修改完善和退化弃用的过程其中修改完善的过程实际上就是软件架构的演化和维护过程演化和维护的目的就是为了使软件能够适应环境的变化而进行的纠错性修改和完善性修改等。软件架构的演化和维护过程是一个不断迭代的过程通过演化和维护软件架构逐步得到完善以满足用户需求。 软件架构演化和定义
软件架构的演化就是软件整体结构的演化演化过程涵盖软件架构的全生命周期包括软件架构需求的获取、软件架构建模、软件架构文档、软件架构实现以及软件架构维护等阶段。
软件架构演化的重要性体
架构是整个系统的骨架是软件系统具备诸多好的特性的保障软件架构作为软件蓝图为人们宏观管控软件系统的整体复杂性和变化性提供了一条有效途径。
软件架构的演化能降低软件演化的成本的原因
对系统的软件架构进行的形式化、可视化表示提高了软件的可构造性便于软件演化。软件架构设计方案涵盖的整体结构信息、配置信息、约束信息等有助于开发人员充分考虑未来可能出现的演化问题、演化情况和演化环境。架构设计时对系统组件之间的耦合描述有助于软件系统的动态调整。
软件架构的定义包含组件、连接件、约束三大要素这类软件架构演化主要关注的就是这三者之间的添加、修改和删除等。
面向对象软件架构演化
假设软件架构对应到具体的架构风格或模式我们就可以讨论演化的各种具体操作了。面向对象软件架构结合UML顺序图来进一步讨论各种演化操作。
对象演化
在顺序图中组件的实体为对象。组件本身包含了众多的属性如接口、类型、语义等这些属性的演化是对象自身的演化对于描述对象之间的交互过程并无影响。因此会对架构设计的动态行为产生影响的演化只包括AddObjectAO和DeleteObjectDO两种。
AO表示在顺序图中添加一个新的对象。这种演化一般是在系统需要添加新的对象来实现某种新的功能或需要将现有对象的某个功能独立以增加架构灵活性的时候发生。DO删除顺序图中现有的一个对象。这种演化一般在系统需要移除某个现有的功能或需要合并某些对象及其功能来降低架构的复杂度的时候发生。
消息演化
消息是顺序图中的核心元素包含了名称、源对象、目标对象、时序等信息。消息演化是将消息演化分为AddMessageAM、DeleteMessageDM、SwapMessageOrderSMO、OverturnMessageOM、ChangeMessageModuleCMM5种。
AM增添一条新的消息产生在对象之间需要增加新的交互行为的时候。DM删除当前的一条消息产生在需要移除某个交互行为的时候是AM的逆向演化。SMO交换两条消息的时间顺序发生在需要改变两个交互行为之间关系的时候。OM反转消息的发送对象与接收对象发生在需要修改某个交互行为本身的时候。CMM改变消息的发送或接收对象发生在需要修改某个交互行为本身的时候。
复合片段演化
复合片段演化是对象交互关系的控制流描述表示可能发生在不同场合的交互与消息同属于连接件范畴。复合片段的演化分为AddFragmentAF、DeleteFragmentDF、FragmentTypeChangeFTC和FragmentConditionChangeFCC。
FCC改变复合片段内部执行的条件发生在改变当前控制流的执行条件时。自动机中与控制流执行条件相对应的转移包括两个一个是符合条件时的转移另一个是不符合条件时的转移因此每次发生FFC 演化时会同时修改这两个转移的触发事件。AF在某几条消息上新增复合片段发生在需要增添新的控制流时。复合片段所产生的分支是不同类型的。DF删除某个现有的复合片段发生在需要移除当前某段控制流时。DF与AF互为逆向演化过程。FTC改变复合片段的类型发生在需要改变某段控制流时。类型演化意味着交互流程的改变一般伴随着条件、内部执行序列的同时演化可以视为复合片段的删除与添加的组合。
约束演化
约束演化是直接对约束信息进行添加和删除。
Add ConstraintAC直接添加新的约束信息会对架构设计产生直接的影响需要判断当前设计是否满足新添加的约束要求。Delete ConstraintDC直接移除某条约束信息发生在去除某些不必要条件的时候一般而言架构设计均会满足演化后的约束。
软件架构演化方式
3种典型的分类方法
按照软件架构的实现方式和实施粒度分类基于过程和函数的演化、面向对象的演化、基于组件的演化和基于架构的演化。按照研究方法将软件架构演化方式分为4类第1类是对演化的支持如代码模块化的准则、可维护性的指示如内聚和祸合、代码重构等第2类是版本和工程的管理工具第3类是架构变换的形式方法包括系统结构和行为变换的模型以及架构演化的重现风格等第4类是架构演化的成本收益分析决定如何增加系统的弹性。针对软件架构的演化过程是否处于系统运行时期可以将软件架构演化分为静态演化和动态演化。 软件架构演化时期 设计时演化运行前演化有限制运行时演化运行时演化 静态演化
软件架构静态演化主要是在设计时演化以及运行前演化。与此相对应的维护方法有3类更正性维护、适应性维护和完善性维护。
软件的静态演化一般包括如下5个步骤
软件理解查阅软件文档分析软件架构识别系统组成元素及其之间的相互关系提取系统的抽象表示形式。需求变更分析静态演化往往是由于用户需求变化、系统运行出错和运行环境发生改变等原因所引起的需要找出新的软件需求与原有的差异。演化计划分析原系统确定演化范围和成本选择合适的演化计划。系统重构根据演化计划对系统进行重构使之适应当前的需求。系统测试对演化后的系统进行测试查找其中的错误和不足之处
架构演化的可维护性度量基于组件图表示的软件架构。
架构演化的可靠性评估基于用例图、部署图和顺序图。
动态演化
动态演化是在系统运行期间的演化需要在不停止系统功能的情况下完成演化较之静态演化更加困难。
架构的动态演化主要来自两类需求
软件内部执行所导致的体系结构改变例如许多服务器端软件会在客户请求到达时创建新的组件来响应用户需求。软件系统外部的请求对软件进行的重配置例如操作系统在升级时无须重新启动在运行过程中就完成对体系结构的修改。
软件的动态性分为3个级别
交互动态性要求数据在固定的结构下动态交互。结构动态性允许对结构进行修改通常的形式是组件和连接件实例的添加和删除这种动态性是研究和应用的主流。架构动态性允许软件架构的基本构造的变动即结构可以被重定义如新的组件类型的定义。
根据所修改的内容不同软件的动态演化主要包括以下4个方面
属性改名目前所有的ADL都支持对非功能属性的分析和规约而在运行过程中用户可能会对这些指标进行重新定义如服务响应时间。行为变化在运行过程中用户需求变化或系统自身服务质量的调节都将引发软件行为的变化。拓扑结构改变如增删组件增删连接件改变组件与连接件之间的关联关系等。风格变化一般软件演化后其架构风格应当保持不变如果非要改变软件的架构风格也只能将架构风格变为其衍生风格如两层C/S到三层C/S。
实现软件架构动态演化的技术主要有两种 采用动态软件架构DSADSA是指在运行时刻会发生变化的系统框架结构允许在运行过程中通过框架结构的动态演化实现对架构的修改。 DSA实施动态演化大体遵循以下4 步①捕捉并分析需求变化②获取或生成体系结构演化策略③根据步骤2得到的演化策略选择适当的演化策略并实施演化④演化后的评估与检测。 进行动态重配置DRDR从组件和连接件的配置入手允许在运行过程中增删组件增删连接件修改连接关系等操作。主要是指在软件部署之后对配置信息的修改常常被用于系统动态升级时需要进行的配置信息修改。 动态重配置可能涉及的修改有①简单任务的相关实现修改②工作流实例任务的添加和删除③组合任务流程中的个体修改④任务输入来源的添加和删除⑤任务输入来源的优先级修改⑥组合任务输出目标的添加和删除⑦组合任务输出目标的优先级修改等。 动态重配置模式主从模式、中央控制模式、客户端/服务器模式、分布式控制模式。
软件架构演化原则 演化成本控制原则 演化成本要控制在预期的范围之内也就是演化成本要明显小于重新开发成本。 用于判断架构演化的成本是否在可控范围内以及用户是否可接受。 进度可控原则 架构演化要在预期时间内完成也就是时间成本可控。 根据该原则可以规划每个演化过程的任务量体现一种迭代、递增(持续演化)的演化思想。 风险可控原则 架构演化过程中的经济风险、时间风险、人力风险、技术风险和环境风险等必须在可控范围内。 用于判断架构演化过程中各种风险是否易于控制。 主体维持原则 保证软件系统主体行为稳定。 用于判断架构演化是否导致系统主体行为不稳定。 系统总体结构优化原则 架构演化要遵循系统总体结构优化原则使得演化之后的软件系统整体结构(布局)更加合理。 用于判断系统整体结构是否合理是否最优。 平滑演化原则 在软件系统的生命周期里软件的演化速率趋于稳定如相邻版本的更新率相对固定。 用于判断是否存在剧烈架构演化。 目标一致原则 架构演化的阶段目标和最终目标要一致。 用于判断每个演化过程是否达到阶段目标所有演化过程结束是否能达到最终目标。 模块独立演化原则 软件中各模块(相同制品的模块如Java的某个类或包)自身的演化最好相互独立或者至少保证对其他模块的影响比较小或影响范围比较小。 用于判断每个模块自身的演化是否相互独立。 影响可控原则 软件中一个模块如果发生变更其给其他模块带来的影响要在可控范围内也就是影响范围可预测。 用于判断是否存在对某个模块的修改导致大量其他修改的情况。 复杂性可控原则 架构演化必须要控制架构的复杂性从而进一步保障软件的复杂性在可控范围内。 用于判断演化之后的架构是否易维护、易扩展、易分析、易测试等。 有利于重构原则 架构演化要遵循有利于重构原则使得演化之后的软件架构更便于重构。 用于判断架构易重构性是否得到提高。 有利于重用原则 架构演化最好能维持甚至提高整体架构的可重用性。 用于判断整体架构可重用性是否遭到破坏。 设计原则遵从性原则 架构演化最好不能与架构设计原则冲突。 用于判断架构设计原则是否遭到破坏(架构设计原则是好的设计经验总结要保障其得到充分使用)。 适应新技术原则 软件要独立于特定的技术手段这样才能够让软件运行于不同平台。 用于判断架构演化是否存在对某种技术依赖过强的情况。 环境适应性原则 架构演化后的软件版本能够比较容易适应新的硬件环境与软件环境。 用于判断架构在不同环境下是否仍然可使用或者容易进行环境配置。 标准侬从性原则 架构演化不会违背相关质量标准(国际标准、国家标准、行业标准、企业标准等)。 用于判断架构演化是否具有规范性是否有章可循而不是胡乱或随意地演化。 质量向好原则 通过演化使得所关注的某个质量指标或某些质量指标的综合效果变得更好或者更满意例如可靠性提高了。 用于判断架构演化是否导致某些质量指标变得很差。 适应新需求原则 架构演化要很容易适应新的需求变更架构演化不能降低原有架构适应新需求的能力架构演化最好可以提高适应新需求的能力。 用于判断演化之后的架构是否降低了架构适应新需求的能力。
软件架构演化评估方法
根据演化过程是否已知可将评估过程分为演化过程已知的评估和演化过程未知的评估。 演化过程己知的评估其目的在于通过对架构演化过程进行度量比较架构内部结构上的差异以及由此导致的外部质量属性上的变化对该演化过程中相关质量属性进行评估。 基于度量的架构演化评估方法其基本思路在于通过对演化前后的软件架构进行度量,比较架构内部结构上的差异以及由此导致的外部质量属性上的变化。具体包括:架构修改影响分析、监控演化过程、分析关键演化过程。 当演化过程未知时我们无法像演化过程已知时那样追踪架构在演化过程中的每一步变化只能根据架构演化前后的度量结果逆向推测出架构发生了哪些改变并分析这些改变与架构相关质量属性的关联关系。
大型网站架构的演化 解决庞大用户访问海量数据和高并发问题 第一阶段单体架构
应用程序、数据库、文件等所有资源都在一台服务器上。 第二阶段垂直架构
将应用和数据分离。应用和数据分离后整个网站使用3台服务器应用服务器、文件服务器和数据库服务器。这3台服务器对硬件资源的要求各不相同
应用服务器需要处理大量的业务逻辑因此需要更快更强大的处理器速度。数据库服务器需要快速磁盘检索和数据缓存因此需要更快的磁盘和更大的内存。文件服务器需要存储大量用户上传的文件因此需要更大容量的硬盘 第三阶段使用缓存改善网站性能
缓存可以分为两种缓存在应用服务器上的本地缓存和缓存在专门的分布式缓存服务器上的远程缓存。 第四阶段使用服务集群改善网站并发处理能力 系统演变到这里将会出现下面几个问题
用户的请求由谁来转发到具体的应用服务器用户如果每次访问到的服务器不一样那么如何维护session的一致性
相关负载均衡问题可以参考案例分析 - 架构设计Web架构中的负载均衡和session有无状态的等相关技术。
第五阶段数据库读写分离
改善数据库负载压力可以实现数据库读写分离。
应用服务器在写数据的时候访问主数据库主数据库通过主从复制机制将数据更新同步到从数据库这样当应用服务器读数据的时候就可以通过从数据库获得数据。为了便于应用程序访问读写分离后的数据库通常在应用服务器端使用专门的数据访问模块使数据库读写分离对应用透明。 相关主从复制问题可以参考案例分析 - 数据库设计中的数据库主从复制等相关技术。
第六阶段使用反向代理和CDN加速网站响应
由于区域的差别使得网络环境异常复杂不同地区的用户访问网站时速度差别也极大。网站需要加速网站访问速度。主要手段有使用CDN和反向代理。 CDN和反向代理的基本原理都是缓存。 CDN部署在网络提供商的机房使用户在请求网站服务时可以从距离自己最近的网络提供商机房获取数据。
反向代理则部署在网站的中心机房当用户请求到达中心机房后首先访问的服务器是反向代理服务器如果反向代理服务器中缓存着用户请求的资源就将其直接返回给用户。
使用CDN和反向代理的目的都是尽早返回数据给用户一方面加快用户访问速度另一方面也减轻后端服务器的负载压力。
第七阶段使用分布式文件系统和分布式数据库系统
数据库经过读写分离后从一台服务器拆分成两台服务器但是随着网站业务的发展依然不能满足需求这时需要使用分布式数据库。文件系统也一样需要使用分布式文件系统。 第八阶段使用NoSQL和搜索引擎
随着网站业务越来越复杂对数据存储和检索的需求也越来越复杂网站需要采用一些非关系数据库技术如NoSQL和非数据库查询技术如搜索引擎。 相关NoSQL问题可以参考案例分析 - 数据库设计中的NoSQL和Redis等相关技术。
第九阶段业务拆分
大型网站为了应对日益复杂的业务场景通过使用分而治之的手段将整个网站业务分成不同的产品线。如大型购物交易网站都会将首页、商铺、订单、买家、卖家等拆分成不同的产品线分归不同的业务团队负责。
具体到技术上也会根据产品线划分将一个网站拆分成许多不同的应用每个应用独立部署。应用之间可以通过一个超链接建立关系(在首页上的导航链接每个都指向不同的应用地址),也可以通过消息队列进行数据分发当然最多的还是通过访问同一个数据存储系统来构成一个关联的完整系统。 第十阶段分布式服务
大型网站的架构演化到这里基本上大多数的技术问题都得以解决诸如跨数据中心的实时数据同步和具体网站业务相关的问题也都可以通过组合改进现有技术架构解决。 软件架构维护
软件架构维护过程一般分为架构知识管理、架构修改管理和架构版本管理。
软件架构知识管理
软件架构知识管理是对架构设计中所隐含的决策来源进行文档化表示进而在架构维护过程中帮助维护人员对架构的修改进行完善的考虑并能够为其他软件架构的相关活动提供参考。
架构知识的定义架构知识 架构设计架构设计决策即需要说明在进行架构设计时采用此种架构的原因。
架构知识管理侧重于软件开发和实现过程所涉及的架构静态演化从架构文档等信息来源中捕捉架构知识进而提供架构的质量属性及其设计依据以进行记录和评价。
架构修改管理
在软件架构修改管理中一个主要的做法就是建立一个隔离区域保障该区域中任何修改对其他部分的影响比较小甚至没有影响。需要明确修改规则、修改类型以及可能的影响范围和副作用等。
架构版本管理
软件架构版本管理为软件架构演化的版本演化控制、使用和评价等提供了可靠的依据并为架构演化量化度量奠定了基础。
