【新版】系统架构设计师 - 软件架构的演化与维护

个人总结，仅供参考，欢迎加好友一起讨论

架构 - 软件架构的演化与维护

考点摘要

• 软件架构演化和定义（★）
• 面向对象软件架构演化（★★）
• 软件架构演化方式（★★）
• 软件架构演化原则（★★）
• 软件架构演化评估（★★）
• 大型网站架构演化（★★）
• 软件架构维护（★）

第二版架构新教材里新增加内容，对应第10章，新增的内容是关于架构的演化和维护阶段，偏理论多，而且不像架构风格、质量属性那块容易出题。个人认为会出几个选择题，甚至到案例题中有内容涉及。

软件架构一般会经历初始设计、实际使用、修改完善和退化弃用的过程，其中修改完善的过程实际上就是软件架构的演化和维护过程，演化和维护的目的就是为了使软件能够适应环境的变化而进行的纠错性修改和完善性修改等。软件架构的演化和维护过程是一个不断迭代的过程，通过演化和维护，软件架构逐步得到完善，以满足用户需求。

软件架构演化和定义

软件架构的演化就是软件整体结构的演化，演化过程涵盖软件架构的全生命周期，包括软件架构需求的获取、软件架构建模、软件架构文档、软件架构实现以及软件架构维护等阶段。

软件架构演化的重要性体：

• 架构是整个系统的骨架，是软件系统具备诸多好的特性的保障
• 软件架构作为软件蓝图为人们宏观管控软件系统的整体复杂性和变化性提供了一条有效途径。

软件架构的演化能降低软件演化的成本的原因：

• 对系统的软件架构进行的形式化、可视化表示提高了软件的可构造性，便于软件演化。
• 软件架构设计方案涵盖的整体结构信息、配置信息、约束信息等有助于开发人员充分考虑未来可能出现的演化问题、演化情况和演化环境。
• 架构设计时对系统组件之间的耦合描述有助于软件系统的动态调整。

软件架构的定义包含组件、连接件、约束三大要素，这类软件架构演化主要关注的就是这三者之间的添加、修改和删除等。

面向对象软件架构演化

假设软件架构对应到具体的架构风格或模式，我们就可以讨论演化的各种具体操作了。面向对象软件架构，结合UML顺序图来进一步讨论各种演化操作。

对象演化

在顺序图中，组件的实体为对象。组件本身包含了众多的属性，如接口、类型、语义等，这些属性的演化是对象自身的演化，对于描述对象之间的交互过程并无影响。因此，会对架构设计的动态行为产生影响的演化只包括AddObject（AO）和DeleteObject（DO）两种。

• AO表示在顺序图中添加一个新的对象。这种演化一般是在系统需要添加新的对象来实现某种新的功能，或需要将现有对象的某个功能独立以增加架构灵活性的时候发生。
• DO删除顺序图中现有的一个对象。这种演化一般在系统需要移除某个现有的功能，或需要合并某些对象及其功能来降低架构的复杂度的时候发生。

消息演化

消息是顺序图中的核心元素，包含了名称、源对象、目标对象、时序等信息。消息演化是将消息演化分为AddMessage（AM）、DeleteMessage（DM）、SwapMessageOrder（SMO）、OverturnMessage（OM）、ChangeMessageModule（CMM）5种。

• AM增添一条新的消息，产生在对象之间需要增加新的交互行为的时候。
• DM删除当前的一条消息，产生在需要移除某个交互行为的时候，是AM的逆向演化。
• SMO交换两条消息的时间顺序，发生在需要改变两个交互行为之间关系的时候。
• OM反转消息的发送对象与接收对象，发生在需要修改某个交互行为本身的时候。
• CMM改变消息的发送或接收对象，发生在需要修改某个交互行为本身的时候。

复合片段演化

复合片段演化是对象交互关系的控制流描述，表示可能发生在不同场合的交互，与消息同属于连接件范畴。复合片段的演化分为AddFragment（AF）、DeleteFragment（DF）、FragmentTypeChange（FTC）和FragmentConditionChange（FCC）。

• FCC改变复合片段内部执行的条件，发生在改变当前控制流的执行条件时。自动机中与控制流执行条件相对应的转移包括两个，一个是符合条件时的转移，另一个是不符合条件时的转移，因此每次发生FFC 演化时会同时修改这两个转移的触发事件。
• AF在某几条消息上新增复合片段，发生在需要增添新的控制流时。复合片段所产生的分支是不同类型的。
• DF删除某个现有的复合片段，发生在需要移除当前某段控制流时。DF与AF互为逆向演化过程。
• FTC改变复合片段的类型，发生在需要改变某段控制流时。类型演化意味着交互流程的改变，一般伴随着条件、内部执行序列的同时演化，可以视为复合片段的删除与添加的组合。

约束演化

约束演化是直接对约束信息进行添加和删除。

• Add Constraint（AC）直接添加新的约束信息，会对架构设计产生直接的影响，需要判断当前设计是否满足新添加的约束要求。
• Delete Constraint（DC）直接移除某条约束信息，发生在去除某些不必要条件的时候，一般而言架构设计均会满足演化后的约束。

软件架构演化方式

3种典型的分类方法：

• 按照软件架构的实现方式和实施粒度分类：基于过程和函数的演化、面向对象的演化、基于组件的演化和基于架构的演化。
• 按照研究方法将软件架构演化方式分为4类：第1类是对演化的支持，如代码模块化的准则、可维护性的指示（如内聚和祸合）、代码重构等；第2类是版本和工程的管理工具；第3类是架构变换的形式方法，包括系统结构和行为变换的模型，以及架构演化的重现风格等；第4类是架构演化的成本收益分析，决定如何增加系统的弹性。
• 针对软件架构的演化过程是否处于系统运行时期，可以将软件架构演化分为静态演化和动态演化。

软件架构演化时期：

• 设计时演化
• 运行前演化
• 有限制运行时演化
• 运行时演化

静态演化

软件架构静态演化主要是在设计时演化以及运行前演化。与此相对应的维护方法有3类：更正性维护、适应性维护和完善性维护。

软件的静态演化一般包括如下5个步骤：

• 软件理解：查阅软件文档，分析软件架构，识别系统组成元素及其之间的相互关系，提取系统的抽象表示形式。
• 需求变更分析：静态演化往往是由于用户需求变化、系统运行出错和运行环境发生改变等原因所引起的，需要找出新的软件需求与原有的差异。
• 演化计划：分析原系统，确定演化范围和成本，选择合适的演化计划。
• 系统重构：根据演化计划对系统进行重构，使之适应当前的需求。
• 系统测试：对演化后的系统进行测试，查找其中的错误和不足之处

架构演化的可维护性度量基于组件图表示的软件架构。

架构演化的可靠性评估基于用例图、部署图和顺序图。

动态演化

动态演化是在系统运行期间的演化，需要在不停止系统功能的情况下完成演化，较之静态演化更加困难。

架构的动态演化主要来自两类需求：

• 软件内部执行所导致的体系结构改变，例如，许多服务器端软件会在客户请求到达时创建新的组件来响应用户需求。
• 软件系统外部的请求对软件进行的重配置，例如，操作系统在升级时无须重新启动，在运行过程中就完成对体系结构的修改。

软件的动态性分为3个级别：

1. 交互动态性，要求数据在固定的结构下动态交互。
2. 结构动态性，允许对结构进行修改，通常的形式是组件和连接件实例的添加和删除，这种动态性是研究和应用的主流。
3. 架构动态性，允许软件架构的基本构造的变动，即结构可以被重定义，如新的组件类型的定义。

根据所修改的内容不同，软件的动态演化主要包括以下4个方面：

• 属性改名：目前所有的ADL都支持对非功能属性的分析和规约，而在运行过程中，用户可能会对这些指标进行重新定义（如服务响应时间）。
• 行为变化：在运行过程中，用户需求变化或系统自身服务质量的调节都将引发软件行为的变化。
• 拓扑结构改变：如增删组件，增删连接件，改变组件与连接件之间的关联关系等。
• 风格变化：一般软件演化后其架构风格应当保持不变，如果非要改变软件的架构风格，也只能将架构风格变为其衍生风格，如两层C/S到三层C/S。

实现软件架构动态演化的技术主要有两种：

• 采用动态软件架构（DSA）：DSA是指在运行时刻会发生变化的系统框架结构，允许在运行过程中通过框架结构的动态演化实现对架构的修改。

  DSA实施动态演化大体遵循以下4 步：①捕捉并分析需求变化；②获取或生成体系结构演化策略；③根据步骤2得到的演化策略，选择适当的演化策略并实施演化；④演化后的评估与检测。

• 进行动态重配置（DR）：DR从组件和连接件的配置入手，允许在运行过程中增删组件，增删连接件，修改连接关系等操作。主要是指在软件部署之后对配置信息的修改，常常被用于系统动态升级时需要进行的配置信息修改。

  动态重配置可能涉及的修改有：①简单任务的相关实现修改；②工作流实例任务的添加和删除；③组合任务流程中的个体修改；④任务输入来源的添加和删除；⑤任务输入来源的优先级修改；⑥组合任务输出目标的添加和删除；⑦组合任务输出目标的优先级修改等。

  动态重配置模式：主从模式、中央控制模式、客户端/服务器模式、分布式控制模式。

软件架构演化原则

1. 演化成本控制原则

   演化成本要控制在预期的范围之内，也就是演化成本要明显小于重新开发成本。

   用于判断架构演化的成本是否在可控范围内，以及用户是否可接受。

2. 进度可控原则

   架构演化要在预期时间内完成，也就是时间成本可控。

   根据该原则可以规划每个演化过程的任务量；体现一种迭代、递增(持续演化)的演化思想。

3. 风险可控原则

   架构演化过程中的经济风险、时间风险、人力风险、技术风险和环境风险等必须在可控范围内。

   用于判断架构演化过程中各种风险是否易于控制。

4. 主体维持原则

   保证软件系统主体行为稳定。

   用于判断架构演化是否导致系统主体行为不稳定。

5. 系统总体结构优化原则

   架构演化要遵循系统总体结构优化原则，使得演化之后的软件系统整体结构(布局)更加合理。

   用于判断系统整体结构是否合理，是否最优。

6. 平滑演化原则

   在软件系统的生命周期里，软件的演化速率趋于稳定，如相邻版本的更新率相对固定。

   用于判断是否存在剧烈架构演化。

7. 目标一致原则

   架构演化的阶段目标和最终目标要一致。

   用于判断每个演化过程是否达到阶段目标，所有演化过程结束是否能达到最终目标。

8. 模块独立演化原则

   软件中各模块(相同制品的模块，如Java的某个类或包)自身的演化最好相互独立，或者至少保证对其他模块的影响比较小或影响范围比较小。

   用于判断每个模块自身的演化是否相互独立。

9. 影响可控原则

   软件中一个模块如果发生变更，其给其他模块带来的影响要在可控范围内，也就是影响范围可预测。

   用于判断是否存在对某个模块的修改导致大量其他修改的情况。

10. 复杂性可控原则

    架构演化必须要控制架构的复杂性，从而进一步保障软件的复杂性在可控范围内。

    用于判断演化之后的架构是否易维护、易扩展、易分析、易测试等。

11. 有利于重构原则

    架构演化要遵循有利于重构原则，使得演化之后的软件架构更便于重构。

    用于判断架构易重构性是否得到提高。

12. 有利于重用原则

    架构演化最好能维持，甚至提高整体架构的可重用性。

    用于判断整体架构可重用性是否遭到破坏。

13. 设计原则遵从性原则

    架构演化最好不能与架构设计原则冲突。

    用于判断架构设计原则是否遭到破坏(架构设计原则是好的设计经验总结，要保障其得到充分使用)。

14. 适应新技术原则

    软件要独立于特定的技术手段，这样才能够让软件运行于不同平台。

    用于判断架构演化是否存在对某种技术依赖过强的情况。

15. 环境适应性原则

    架构演化后的软件版本能够比较容易适应新的硬件环境与软件环境。

    用于判断架构在不同环境下是否仍然可使用，或者容易进行环境配置。

16. 标准侬从性原则

    架构演化不会违背相关质量标准(国际标准、国家标准、行业标准、企业标准等)。

    用于判断架构演化是否具有规范性，是否有章可循；而不是胡乱或随意地演化。

17. 质量向好原则

    通过演化使得所关注的某个质量指标或某些质量指标的综合效果变得更好或者更满意，例如可靠性提高了。

    用于判断架构演化是否导致某些质量指标变得很差。

18. 适应新需求原则

    架构演化要很容易适应新的需求变更；架构演化不能降低原有架构适应新需求的能力；架构演化最好可以提高适应新需求的能力。

    用于判断演化之后的架构是否降低了架构适应新需求的能力。

软件架构演化评估方法

根据演化过程是否已知可将评估过程分为：演化过程已知的评估和演化过程未知的评估。

• 演化过程己知的评估其目的在于通过对架构演化过程进行度量，比较架构内部结构上的差异以及由此导致的外部质量属性上的变化，对该演化过程中相关质量属性进行评估。

  基于度量的架构演化评估方法，其基本思路在于通过对演化前后的软件架构进行度量,比较架构内部结构上的差异以及由此导致的外部质量属性上的变化。具体包括:架构修改影响分析、监控演化过程、分析关键演化过程。

• 当演化过程未知时，我们无法像演化过程已知时那样追踪架构在演化过程中的每一步变化，只能根据架构演化前后的度量结果逆向推测出架构发生了哪些改变，并分析这些改变与架构相关质量属性的关联关系。

大型网站架构的演化

解决庞大用户访问，海量数据和高并发问题

第一阶段：单体架构

应用程序、数据库、文件等所有资源都在一台服务器上。

第二阶段：垂直架构

将应用和数据分离。应用和数据分离后整个网站使用3台服务器：应用服务器、文件服务器和数据库服务器。这3台服务器对硬件资源的要求各不相同：

• 应用服务器需要处理大量的业务逻辑，因此需要更快更强大的处理器速度。
• 数据库服务器需要快速磁盘检索和数据缓存，因此需要更快的磁盘和更大的内存。
• 文件服务器需要存储大量用户上传的文件，因此需要更大容量的硬盘

第三阶段：使用缓存改善网站性能

缓存可以分为两种：缓存在应用服务器上的本地缓存和缓存在专门的分布式缓存服务器上的远程缓存。

第四阶段：使用服务集群改善网站并发处理能力

系统演变到这里，将会出现下面几个问题：

• 用户的请求由谁来转发到具体的应用服务器
• 用户如果每次访问到的服务器不一样，那么如何维护session的一致性

相关负载均衡问题，可以参考：案例分析 - 架构设计＜Web架构＞中的负载均衡和session有无状态的等相关技术。

第五阶段：数据库读写分离

改善数据库负载压力，可以实现数据库读写分离。

应用服务器在写数据的时候，访问主数据库，主数据库通过主从复制机制将数据更新同步到从数据库，这样当应用服务器读数据的时候，就可以通过从数据库获得数据。为了便于应用程序访问读写分离后的数据库，通常在应用服务器端使用专门的数据访问模块，使数据库读写分离对应用透明。

相关主从复制问题，可以参考：案例分析 - 数据库设计中的数据库主从复制等相关技术。

第六阶段：使用反向代理和CDN加速网站响应

由于区域的差别使得网络环境异常复杂，不同地区的用户访问网站时，速度差别也极大。网站需要加速网站访问速度。主要手段有使用CDN和反向代理。 CDN和反向代理的基本原理都是缓存。

CDN部署在网络提供商的机房，使用户在请求网站服务时，可以从距离自己最近的网络提供商机房获取数据。

反向代理则部署在网站的中心机房，当用户请求到达中心机房后，首先访问的服务器是反向代理服务器，如果反向代理服务器中缓存着用户请求的资源，就将其直接返回给用户。

使用CDN和反向代理的目的都是尽早返回数据给用户，一方面加快用户访问速度，另一方面也减轻后端服务器的负载压力。

第七阶段：使用分布式文件系统和分布式数据库系统

数据库经过读写分离后，从一台服务器拆分成两台服务器，但是随着网站业务的发展依然不能满足需求，这时需要使用分布式数据库。文件系统也一样，需要使用分布式文件系统。

第八阶段：使用NoSQL和搜索引擎

随着网站业务越来越复杂，对数据存储和检索的需求也越来越复杂，网站需要采用一些非关系数据库技术如NoSQL和非数据库查询技术如搜索引擎。

相关NoSQL问题，可以参考：案例分析 - 数据库设计中的NoSQL和Redis等相关技术。

第九阶段：业务拆分

大型网站为了应对日益复杂的业务场景，通过使用分而治之的手段将整个网站业务分成不同的产品线。如大型购物交易网站都会将首页、商铺、订单、买家、卖家等拆分成不同的产品线，分归不同的业务团队负责。

具体到技术上，也会根据产品线划分，将一个网站拆分成许多不同的应用，每个应用独立部署。应用之间可以通过一个超链接建立关系(在首页上的导航链接每个都指向不同的应用地址),也可以通过消息队列进行数据分发，当然最多的还是通过访问同一个数据存储系统来构成一个关联的完整系统。

第十阶段：分布式服务

大型网站的架构演化到这里，基本上大多数的技术问题都得以解决，诸如跨数据中心的实时数据同步和具体网站业务相关的问题也都可以通过组合改进现有技术架构解决。

软件架构维护

软件架构维护过程一般分为：架构知识管理、架构修改管理和架构版本管理。

软件架构知识管理

软件架构知识管理是对架构设计中所隐含的决策来源进行文档化表示，进而在架构维护过程中帮助维护人员对架构的修改进行完善的考虑，并能够为其他软件架构的相关活动提供参考。

架构知识的定义：架构知识 = 架构设计＋架构设计决策，即需要说明在进行架构设计时采用此种架构的原因。

架构知识管理侧重于软件开发和实现过程所涉及的架构静态演化，从架构文档等信息来源中捕捉架构知识，进而提供架构的质量属性及其设计依据以进行记录和评价。

架构修改管理

在软件架构修改管理中，一个主要的做法就是建立一个隔离区域保障该区域中任何修改对其他部分的影响比较小，甚至没有影响。需要明确修改规则、修改类型，以及可能的影响范围和副作用等。

架构版本管理

软件架构版本管理为软件架构演化的版本演化控制、使用和评价等提供了可靠的依据，并为架构演化量化度量奠定了基础。