软件架构演化和维护
本章导读
软件架构演化是保障系统持续满足业务需求的关键活动。本章介绍面向对象架构演化的四种类型(对象、消息、复合片段、约束)、静态与动态演化的区别、18 种演化原则,以及大型网站架构演化的典型路径。重点理解遗留系统的四种演化策略(淘汰、继承、改造、集成)及其适用场景。
学习目标
- 理解软件架构演化与架构定义的关系
- 掌握面向对象软件架构演化的四种类型及其操作
- 区分静态演化和动态演化的特点与应用场景
- 熟记 18 种架构演化原则
- 掌握遗留系统的四种演化策略及判断标准
- 理解大型网站架构演化的典型阶段
软件架构演化概述
演化的重要性
软件架构演化对系统健康发展至关重要:
mindmap
root((架构演化))
保障系统特性
可维护性
可扩展性
可靠性
管控复杂性
降低修改成本
控制变化风险
保证正确性
演化一致性
演化便捷性 演化与定义的关系
软件架构包括**组件、连接件和约束**三大要素,因此架构演化主要关注这三个要素的:
| 操作类型 | 说明 |
|---|---|
| 添加 | 引入新的组件、连接件或约束 |
| 修改 | 调整现有元素的属性或行为 |
| 删除 | 移除不再需要的元素 |
面向对象软件架构演化
面向对象架构演化涉及四个维度:对象演化、消息演化、复合片段演化、约束演化。
演化类型总览
graph TB
subgraph 对象演化
AO[AO: Add Object<br>添加对象]
DO[DO: Delete Object<br>删除对象]
end
subgraph 消息演化
AM[AM: Add Message<br>添加消息]
DM[DM: Delete Message<br>删除消息]
SMO[SMO: Swap Message Order<br>交换消息顺序]
OM[OM: Overturn Message<br>反转消息方向]
CMM[CMM: Change Message Module<br>改变消息模块]
end
subgraph 复合片段演化
AF[AF: Add Fragment<br>添加片段]
DF[DF: Delete Fragment<br>删除片段]
FTC[FTC: Fragment Type Change<br>片段类型改变]
FCC[FCC: Fragment Condition Change<br>片段条件改变]
end
subgraph 约束演化
AC[AC: Add Constraint<br>添加约束]
DC[DC: Delete Constraint<br>删除约束]
end 对象演化
对象演化影响架构设计的动态行为:
| 操作 | 全称 | 触发场景 |
|---|---|---|
| AO | Add Object | 需要添加新功能,或将现有功能独立以增加架构灵活性 |
| DO | Delete Object | 需要移除某功能,或合并对象以降低架构复杂度 |
消息演化
消息演化涉及对象间的交互行为变更:
| 操作 | 全称 | 触发场景 |
|---|---|---|
| AM | Add Message | 对象间需要增加新的交互行为 |
| DM | Delete Message | 需要移除某个交互行为 |
| SMO | Swap Message Order | 需要改变两个交互行为的执行顺序 |
| OM | Overturn Message | 需要反转消息的发送者与接收者 |
| CMM | Change Message Module | 需要改变消息的发送或接收对象 |
记忆技巧
消息演化 5 种操作可记为:"增删换反改"
- 增:AM(增加消息)
- 删:DM(删除消息)
- 换:SMO(交换顺序)
- 反:OM(反转方向)
- 改:CMM(改变模块)
复合片段演化
复合片段演化涉及控制流的变更:
| 操作 | 全称 | 触发场景 |
|---|---|---|
| AF | Add Fragment | 需要增添新的控制流 |
| DF | Delete Fragment | 需要移除当前某段控制流 |
| FTC | Fragment Type Change | 需要改变控制流的类型 |
| FCC | Fragment Condition Change | 需要改变控制流的执行条件 |
约束演化
| 操作 | 全称 | 说明 |
|---|---|---|
| AC | Add Constraint | 添加新约束,需判断当前设计是否满足新约束 |
| DC | Delete Constraint | 移除不必要的约束条件 |
软件架构演化方式分类
按演化时期分类
timeline
title 架构演化时期
设计时演化 : 代码编译前
运行前演化 : 编译后、执行前
有限制运行时演化 : 特定约束满足时
运行时演化 : 运行时需求变更时 | 演化时期 | 发生时机 | 特点 |
|---|---|---|
| 设计时演化 | 架构模型与代码编译之前 | 最灵活、成本最低 |
| 运行前演化 | 编译之后、执行之前 | 需重新部署 |
| 有限制运行时演化 | 特定约束满足时 | 有条件的动态调整 |
| 运行时演化 | 系统运行中 | 最复杂、风险最高 |
静态演化
静态演化需求:设计时演化需求 + 运行前演化需求
静态演化的一般过程:
graph LR
A[软件理解] --> B[需求变更分析]
B --> C[演化计划]
C --> D[系统重构]
D --> E[系统测试] 静态演化的原子操作:
| 操作 | 全称 | 说明 |
|---|---|---|
| AMD | Add Module Dependence | 添加模块依赖 |
| RMD | Remove Module Dependence | 移除模块依赖 |
| AMI | Add Module Interface | 添加模块接口 |
| RMI | Remove Module Interface | 移除模块接口 |
| AM | Add Module | 添加模块 |
| RM | Remove Module | 移除模块 |
| SM | Split Module | 拆分模块 |
| AGM | Aggregate Modules | 聚合模块 |
| 操作 | 全称 | 说明 |
|---|---|---|
| AMS | Add Message | 添加消息 |
| RMS | Remove Message | 移除消息 |
| AO/RO | Add/Remove Object | 添加/移除对象 |
| AF/RF | Add/Remove Fragment | 添加/移除片段 |
| CF | Change Fragment | 改变片段 |
| AU/RU | Add/Remove Use Case | 添加/移除用例 |
| AA/RA | Add/Remove Actor | 添加/移除参与者 |
动态演化
动态演化需求:
- 软件内部执行导致的架构改变
- 软件系统外部请求的重配置
动态演化类型:
| 分类维度 | 类型 |
|---|---|
| 动态性等级 | 交互动态性 → 结构动态性 → 架构动态性 |
| 演化内容 | 属性改名、行为变化、拓扑结构改变、风格变化 |
动态软件架构(DSA):
graph TB
subgraph DSA描述语言
A[π-ADL<br>基于行为视角]
B[Pilar<br>基于反射视角]
C[LIME<br>基于协调视角]
end
subgraph DSA演化工具
D[反射机制]
E[组件操作]
F[π演算]
G[外部演化管理器]
end 动态重配置模式:
| 模式 | 特点 |
|---|---|
| 主从模式 | 主节点控制从节点的配置 |
| 中央控制模式 | 统一的控制中心管理所有配置 |
| 客户端/服务器模式 | C/S 架构下的配置管理 |
| 分布式控制模式 | 去中心化的配置协调 |
动态配置难点
- 约束定义困难
- 性能约束难以静态衡量
- 难以管理所有方面
- 需同时保证组件系统完整性和重配置策略的正确安全性
软件架构演化原则
软件架构包括 18 种可持续演化原则,可分为五大类:
成本与风险控制
| 序号 | 原则 | 说明 |
|---|---|---|
| 1 | 演化成本控制原则 | 演化成本要控制在预期范围内 |
| 2 | 进度可控原则 | 架构演化要在预期时间内完成 |
| 3 | 风险可控原则 | 经济、时间、人力、技术、环境风险在可控范围内 |
系统稳定性
| 序号 | 原则 | 说明 |
|---|---|---|
| 4 | 主体维持原则 | 平均增量增长保持平稳,保证系统主体行为稳定 |
| 5 | 系统总体结构优化原则 | 使演化后系统整体结构(布局)更加合理 |
| 6 | 平滑演化原则 | 软件的演化速率趋于稳定 |
| 7 | 目标一致原则 | 架构演化的阶段目标和最终目标要一致 |
模块独立性
| 序号 | 原则 | 说明 |
|---|---|---|
| 8 | 模块独立演化原则 | 软件中各模块自身的演化最好相互独立 |
| 9 | 影响可控原则 | 一个模块变更对其他模块的影响在可控范围内 |
| 10 | 复杂性可控原则 | 控制架构复杂性,保障软件复杂性在可控范围内 |
可重构与可重用
| 序号 | 原则 | 说明 |
|---|---|---|
| 11 | 有利于重构原则 | 使演化后软件架构便于重构 |
| 12 | 有利于重用原则 | 演化最好能维持甚至提高整体架构的可重用性 |
| 13 | 设计原则遵循性原则 | 架构演化不能与架构设计原则冲突 |
环境适应性
| 序号 | 原则 | 说明 |
|---|---|---|
| 14 | 适应新技术原则 | 软件独立于特定技术手段,可运行于不同平台 |
| 15 | 环境适应性原则 | 演化后的软件版本容易适应新的硬件和软件环境 |
| 16 | 标准依从性原则 | 演化不违背相关质量标准(国际、国家、行业) |
| 17 | 质量向好原则 | 使所关注的质量指标或综合效果变更好 |
| 18 | 适应新需求原则 | 很容易适应新的需求变更 |
记忆技巧:18 原则分类记忆
- 成本风险(3):成本、进度、风险
- 系统稳定(4):主体、结构、平滑、目标
- 模块独立(3):独立、影响、复杂
- 重构重用(3):重构、重用、设计
- 环境适应(5):技术、环境、标准、质量、需求
软件架构演化评估
演化过程已知的评估
graph LR
A[架构度量] --> B[演化前度量]
A --> C[演化后度量]
B --> D[计算差值]
C --> D
D --> E[分析变化趋势]
E --> F[计算质量属性距离]
F --> G[评估质量属性] 演化过程未知的评估
当演化过程未知时,需要通过架构逆向工程等手段重建架构信息,然后进行评估。
大型网站系统架构演化实例
大型网站架构演化通常经历以下 10 个阶段:
graph TB
subgraph 初始阶段
A1[第1阶段<br>单体架构]
A2[第2阶段<br>垂直架构]
end
subgraph 性能优化
B1[第3阶段<br>缓存]
B2[第4阶段<br>服务集群]
B3[第5阶段<br>读写分离]
B4[第6阶段<br>CDN+反向代理]
end
subgraph 分布式化
C1[第7阶段<br>分布式存储]
C2[第8阶段<br>NoSQL+搜索]
C3[第9阶段<br>业务拆分]
C4[第10阶段<br>分布式服务]
end
A1 --> A2 --> B1 --> B2 --> B3 --> B4 --> C1 --> C2 --> C3 --> C4 | 阶段 | 架构模式 | 核心特点 |
|---|---|---|
| 1 | 单体架构 | 应用、数据库、文件都在一台服务器上 |
| 2 | 垂直架构 | 应用和数据分离(应用服务器、文件服务器、数据服务器) |
| 3 | 使用缓存 | 本地缓存 + 分布式缓存服务器 |
| 4 | 服务集群 | 负载均衡调度服务器,解决高并发问题 |
| 5 | 读写分离 | 主数据库写、从数据库读,主从复制同步 |
| 6 | CDN + 反向代理 | CDN 就近获取,反向代理缓存静态资源 |
| 7 | 分布式存储 | 业务分库,不同业务数据部署在不同服务器 |
| 8 | NoSQL + 搜索引擎 | 引入 NoSQL 和搜索引擎提升查询能力 |
| 9 | 业务拆分 | 将网站拆分成多个独立应用,独立部署 |
| 10 | 分布式服务 | 微服务化,服务间通过 RPC 通信 |
软件架构维护
软件架构维护包括三个核心管理活动:
graph TB
A[架构维护] --> B[知识管理]
A --> C[修改管理]
A --> D[版本管理]
B --> B1[架构知识 = 架构设计 + 设计决策]
B --> B2[防止关键设计知识沉没]
C --> C1[建立隔离区域]
C --> C2[最小化修改影响]
D --> D1[版本演化控制]
D --> D2[使用和评价依据] 架构可维护性度量指标
| 指标 | 全称 | 说明 |
|---|---|---|
| CNN | 圈复杂度 | 衡量程序逻辑复杂度 |
| FFC | 扇入扇出度 | 衡量模块调用关系 |
| CBO | 模块间耦合度 | 衡量模块间依赖程度 |
| RFC | 模块的响应 | 衡量模块响应能力 |
| TCC | 紧内聚度 | 衡量模块内部紧密程度 |
| LCC | 松内聚度 | 衡量模块内部松散程度 |
遗留系统演化策略 ⭐
高频考点
遗留系统演化策略是考试重点,需要根据**技术含量**和**业务价值**两个维度判断采用哪种策略。
四种演化策略
quadrantChart
title 遗留系统演化策略矩阵
x-axis 低技术含量 --> 高技术含量
y-axis 低业务价值 --> 高业务价值
quadrant-1 改造
quadrant-2 继承
quadrant-3 淘汰
quadrant-4 集成 | 策略 | 技术含量 | 业务价值 | 适用场景 | 关键措施 |
|---|---|---|---|---|
| 淘汰 | 低 | 低 | 技术落后且业务价值低 | 全面重新开发新系统 |
| 继承 | 低 | 高 | 技术落后但业务依赖强 | 完全兼容功能模型和数据模型,新老并行运行 |
| 改造 | 高 | 高 | 技术先进且业务价值高 | 系统功能增强 + 数据模型改造 |
| 集成 | 高 | 低 | 技术先进但形成信息孤岛 | 打通不同平台和数据模型,消除信息孤岛 |
详细说明
适用条件:技术含量低 + 业务价值低
措施:全面重新开发新系统以代替遗留系统
特点:彻底替换,不保留原有系统
适用条件:技术含量低 + 业务价值高
措施:
- 完全兼容遗留系统的**功能模型**和**数据模型**
- 新老系统**并行运行**一段时间
- 保证业务连续性
特点:平稳过渡,保障业务不中断
适用条件:技术含量高 + 业务价值高
措施:
- 系统功能的增强
- 数据模型的改造
特点:保留技术优势,提升业务能力
适用条件:技术含量高 + 业务价值低(局部)
典型场景:
- 系统只完成某个部门的业务管理
- 多个系统基于不同平台、不同数据模型
- 形成多个"信息孤岛"
措施:整合各系统,消除信息孤岛
特点:统一平台,数据互通
系统维护类型
系统维护是系统交付使用后的改变工作,根据维护原因分为四种类型:
| 维护类型 | 别称 | 触发原因 | 说明 |
|---|---|---|---|
| 正确性维护 | 改正性维护 | 发现缺陷 | 改正开发阶段已发生但测试未发现的错误 |
| 适应性维护 | - | 环境变化 | 适应硬件、软件配置或数据环境的变化 |
| 完善性维护 | - | 新需求 | 扩充功能、增强性能、改进加工效率、提高可维护性 |
| 预防性维护 | - | 未来变化 | 主动增加新功能以适应未来软硬件环境变化 |
记忆技巧
四种维护类型可记为:"正适完预"
- **正**确性:改 Bug
- **适**应性:适应环境
- **完**善性:加功能
- **预**防性:防未来
本章小结
核心知识点
- 面向对象演化:对象(2)、消息(5)、复合片段(4)、约束(2)共 13 种操作
- 演化方式:静态演化(设计时、运行前)vs 动态演化(运行时)
- 演化原则:18 种原则分五大类(成本风险、系统稳定、模块独立、重构重用、环境适应)
- 大型网站演化:10 个阶段(单体→垂直→缓存→集群→读写分离→CDN→分布式→NoSQL→拆分→微服务)
- 遗留系统策略:淘汰(低低)、继承(低高)、改造(高高)、集成(高低)
- 系统维护:正确性、适应性、完善性、预防性
考试重点
| 知识点 | 考查形式 |
|---|---|
| 遗留系统演化策略 | 根据技术含量和业务价值判断策略类型 |
| 演化操作类型 | 识别各种演化操作的触发场景 |
| 维护类型区分 | 根据维护原因判断维护类型 |
| 演化原则 | 理解各原则的含义和应用 |
学习建议
- 遗留系统策略:画出四象限图,牢记各象限对应的策略
- 演化操作:理解每种操作的含义,能举出实际例子
- 维护类型:通过典型场景区分四种维护类型