本页目录 · 5 节
- 一、知识框架
- 二、必背要点
- 10.1 演化和定义的关系
- 10.2 面向对象软件架构演化过程
- 10.3 演化方式分类
- 10.4 演化原则
- 10.5 演化评估方法
- 10.6 大型网站系统架构演化实例
- 10.7 软件架构维护
- 三、易混淆概念对比
- 四、常见考法与出题角度
- 五、速记与自测
第 10 章 软件架构的演化和维护#
对应大纲：科目 1-9 软件架构的演化和维护｜教材 P330–P368｜优先级 ★★★★｜综合知识估分 3～5 分
读法：用「一变四类、二种形态、十个阶段」抓骨架；演化原则与大型网站十阶段是案例、论文最好用的两条线。
一、知识框架#
软件架构的演化和维护
├─ 10.1 演化和定义的关系：定义是基线，演化是再定义
├─ 10.2 面向对象架构演化过程
│ ├─ 对象演化：类/对象、属性、方法、关系
│ ├─ 消息演化：消息增删、参数、方向、顺序
│ ├─ 复合片段演化：alt/opt/loop/par 片段
│ └─ 约束演化：前后置条件、不变量、时序
├─ 10.3 演化方式分类
│ ├─ 按时期：设计时演化｜运行时演化
│ ├─ 按形态：静态演化｜动态演化
│ └─ 按粒度：原子演化｜复合演化
├─ 10.4 演化原则：成本、投资、一致性、渐进等
├─ 10.5 演化评估：过程已知｜过程未知
├─ 10.6 大型网站架构演化十阶段
└─ 10.7 架构维护：知识｜修改｜版本｜可维护性度量
二、必背要点#
10.1 演化和定义的关系#
- 架构定义：对构件、连接件、约束及质量目标的明确描述，是演化的基线。
- 架构演化：生命周期中因需求、技术、环境变化对架构所做的增量修改。
- 二者关系：定义是演化的起点与边界，演化是定义的修改与再定义，形成「定义→演化→新定义」的循环。定义不清，演化必然失控；演化不记录，定义就会失真。
- 演化不等于重写：优先在原有结构上增量调整，保持风格与约束一致。
10.2 面向对象软件架构演化过程#
| 演化类型 | 演化内容 | 示例 |
|---|
| 对象演化 | 类与对象的增删、属性方法变化、可见性与关系变化 | 订单域新增「优惠券」对象 |
| 消息演化 | 消息增删、名称参数方向变化、顺序与同步方式变化 | 下单流程新增「锁库存」消息 |
| 复合片段演化 | alt、opt、loop、par 等片段的增删改与嵌套变化 | 支付流程增加 opt 优惠分支 |
| 约束演化 | 前置后置条件、不变量、时序与守卫条件变化 | 库存数量不得为负 |
10.3 演化方式分类#
| 分类维度 | 类型 | 含义与特点 |
|---|
| 演化时期 | 设计时演化 | 开发阶段修改模型与代码，可停机、成本低 |
| 演化时期 | 运行时演化 | 系统运行中修改，不停机，难度与风险高 |
| 演化形态 | 静态演化 | 停机后修改并重新部署，需保证版本一致 |
| 演化形态 | 动态演化 | 运行中替换构件，需处理状态迁移与兼容 |
| 演化粒度 | 原子演化 | 单构件或单操作变更，影响范围小 |
| 演化粒度 | 复合演化 | 多构件协同变更，需调整接口与交互 |
动态演化的两个关键词：软件动态性（运行时可被修改的能力）与动态替换（热替换构件并保持系统状态一致）。难点在状态迁移、版本兼容与事务一致性。
10.4 演化原则#
| 原则 | 含义 |
|---|
| 演化成本最小 | 用最小改动满足变更，避免过度设计 |
| 保护投资者利益 | 不轻易推倒重来，保护既有投资 |
| 保持架构一致性 | 新构件遵循原有风格、接口与约束 |
| 需求驱动 | 每次演化都对应真实需求，不为技术而改 |
| 渐进可控 | 小步演化、可分步上线、可回退 |
| 风险可控 | 先做影响分析再实施，设置止损点 |
| 演化可追溯 | 记录变更原因、决策与版本 |
| 质量不降 | 演化后质量属性不低于基线 |
10.5 演化评估方法#
| 维度 | 过程已知 | 过程未知 |
|---|
| 数据条件 | 有完整演化记录与中间版本 | 只有首尾版本或少量版本 |
| 评估方法 | 逐版本度量、变更影响分析、还原演化路径 | 版本差异对比、结构与行为差异分析 |
| 输出 | 演化成本、风险与质量变化趋势 | 变更影响范围、演化代价估算 |
常用度量：结构（耦合、内聚、复杂度、模块数）、性能（响应时间、吞吐量）、可靠性（MTBF、失效数）、可维护性（变更影响集、回归范围）。
10.6 大型网站系统架构演化实例#
| 阶段 | 解决什么问题 | 引入什么技术 | 副作用 |
|---|
| 1 单一应用 | 访问量小、快速上线 | 一台服务器承载应用、数据库、文件 | 单点、无扩展能力 |
| 2 应用数据分离 | 应用与数据库争抢资源 | 应用服务器、数据库服务器、文件服务器 | 网络调用增加 |
| 3 使用缓存 | 读多写少、数据库压力大 | 本地缓存、分布式缓存 | 一致性、缓存穿透 |
| 4 应用集群 | 单机并发达到上限 | 负载均衡加多应用节点 | 会话共享、状态管理 |
| 5 读写分离 | 读压力持续增长 | 主从复制、读写分离 | 主从延迟、一致性 |
| 6 代理与 CDN | 静态资源与入口压力 | 反向代理、CDN | 缓存刷新、成本上升 |
| 7 分布式存储 | 单机存储容量上限 | 分布式文件系统、分库分表 | 运维复杂、跨库事务 |
| 8 NoSQL 与搜索 | 海量非结构化查询 | NoSQL、搜索引擎 | 数据同步、一致性 |
| 9 业务拆分 | 系统耦合、迭代变慢 | 垂直拆分、微服务 | 分布式事务、链路变长 |
| 10 分布式服务 | 服务治理与复用 | 注册中心、消息队列、容器化 | 治理成本、故障定位难 |
演化规律：先分离（应用与数据）、再扩展（缓存、集群、读写分离）、后拆分（业务与服务）；每一步解决上一个瓶颈，同时引入新的复杂度。
10.7 软件架构维护#
| 维护内容 | 主要做法 | 产出 |
|---|
| 知识管理 | 维护架构文档、设计决策与领域知识库 | 可查可用的架构知识 |
| 修改管理 | 变更申请、影响分析、审批、实施、验证 | 变更记录与验证结论 |
| 版本管理 | 建立基线、分支管理、配置项与回滚机制 | 可追溯的版本历史 |
| 可维护性度量 | 度量可理解性、可测试性、可修改性、稳定性 | 维护性评估报告 |
三、易混淆概念对比#
| A | B | 关键区别 |
|---|
| 架构演化 | 架构维护 | 演化强调结构随需求变化；维护强调运行期的修正与保障 |
| 静态演化 | 动态演化 | 静态需停机修改再部署；动态在运行中替换构件 |
| 原子演化 | 复合演化 | 原子改单构件、影响小；复合改多构件、需协调接口 |
| 设计时演化 | 运行时演化 | 设计时在开发阶段完成；运行时在系统运行中完成 |
| 对象演化 | 消息演化 | 对象演化改结构与属性；消息演化改交互与顺序 |
| 复合片段演化 | 约束演化 | 前者改流程分支与循环；后者改条件与不变量 |
| 过程已知评估 | 过程未知评估 | 前者有完整版本链可逐版度量；后者只能对比首尾推断 |
| 架构演化 | 架构重写 | 演化是增量调整、保护投资；重写是推倒重来、风险高 |
| 版本管理 | 配置管理 | 版本管理管版本线与基线；配置管理范围更大，含全部配置项 |
| 可维护性 | 可修改性 | 可维护性是维护视角的综合属性；可修改性是架构评估中的质量属性 |
四、常见考法与出题角度#
| 题型 | 出题角度 | 典型问法 | 答题要点 |
|---|
| 单选 | 演化分类 | 「运行中替换构件属于哪种演化」 | 动态演化、运行时演化 |
| 单选 | 粒度判断 | 「同时修改多个构件属于」 | 复合演化 |
| 单选 | 阶段排序 | 「大型网站演化中读写分离之后是」 | 反向代理与 CDN |
| 单选 | 原则理解 | 「不推倒重来体现哪条原则」 | 保护投资者利益 |
| 单选 | 评估条件 | 「缺少中间版本时采用哪种评估」 | 过程未知的差异对比法 |
| 简答 | 演化内容 | 「面向对象架构演化包括哪四类」 | 对象、消息、复合片段、约束 |
| 简答 | 维护内容 | 「架构维护包括哪些工作」 | 知识、修改、版本、可维护性度量 |
| 案例题角度 | 演化路径设计 | 给出业务增长问「架构应如何演进」 | 按十阶段顺序对应瓶颈给方案，并说明副作用 |
| 论文可用角度 | 正文举例 | 「论文写系统演进时怎么用本章」 | 可写：「系统上线后经历三次演进：先应用与数据分离，再集群与读写分离，最后按业务垂直拆分，每一步都以架构基线为依据、以影响分析为前提。」 |
五、速记与自测#
速记
- 演化四类：对、消、复、约
- 两形态：静、动；两粒度：原、复；两时期：设、运
- 十阶段：单分缓群读，代文搜拆服
- 维护四项：知、改、版、度
- 原则核心：成本最小、保护投资、保持一致
自测
- 大型网站架构演化中，引入缓存主要解决什么问题，又带来什么副作用？
- 静态演化与动态演化的根本区别是什么？
- 演化过程未知时，如何评估演化影响？
答案：1. 解决读多写少导致的数据库压力，副作用是一致性与缓存穿透；2. 是否需要停机修改并重新部署；3. 对比演化前后版本的结构与行为差异，结合度量估算影响范围与代价。