第 10 章《软件架构的演化和维护》

在软考高级《系统架构设计师》考试中，官方教程第 10 章《软件架构的演化和维护》是全书将架构设计与长期运维、重构演进相结合的关键章节。本章不仅在上午综合知识单选题中稳定贡献 6~8 分，更是下午案例分析大题（大型网站 10 阶段演化、静态 vs 动态重配置、架构可维护性度量指标）与论文科目（《论软件架构的演化及其应用》、《论大型网站架构演化与重构实践》）的核心采分源头！

本文紧扣《系统架构设计师教程（第2版）》官方教材 PDF 第 10 章脉络，对 5 大核心板块 进行系统化、深度逻辑拆解，并在每个模块下配备全仿真真题/例题打靶与深度解析。

📌 章节知识全景导航

第 10 章 软件架构的演化和维护├── 10.1 & 10.2 软件架构演化基础（演化与定义关系、面向对象4类演化：对象/消息/复合片段/约束）├── 10.3 演化方式分类（4个演化时期、静态演化与正交架构、动态演化DSA与3级动态性）├── 10.4 18 种可持续演化原则（演化成本ECC、平滑演化IWR、主体维持AIG、修改局部化等）├── 10.5 & 10.6 演化评估与大型网站 10 阶段演化实例（单体→集群→读写分离→分布式服务）└── 10.7 软件架构维护与可维护性度量实践（知识管理、修改隔离、CCN/FFC/CBO/RFC/TCC/LCC 6大指标）

🎯 模块一：10.1 & 10.2 软件架构演化概念与面向对象演化过程

1. 核心考点精讲

• • 软件架构演化的核心定义：
• • 演化是软件架构全生命周期（需求、设计、实现、维护）中，为了适应用户新需求、业务环境与运行环境的变化，对架构结构进行持续修改完善的过程。
• • “软件架构是演化来的，而不是一锤子设计出来的。” 演化保证了软件架构自身的“有用性”。
• • 演化与架构定义（三要素）的关系：
• • 若架构定义为 SA = {Components, Connectors, Constraints}（组件、连接件、约束），则演化即为对这三者的添加、删除与修改：
• • 组件演化：增加/删除/修改计算与数据模块，易引发波及效应（Ripple Effect）。
• • 连接件演化：改变组件间的交互消息（增加、删除、改变消息或交互流程）。
• • 约束演化：改变拓扑关系、参数或配置数据。
• • 面向对象（OO）软件架构演化的 4 类过程（UML 顺序图表示）：
1. 1. 对象演化：包含 AddObject (AO) 与 DeleteObject (DO)，通常伴随消息演化。
2. 2. 消息演化：包含 AM (增添消息)、DM (删除消息)、SMO (交换消息时序)、OM (反转发送/接收方)、CMM (改变发送/接收对象)。
3. 3. 复合片段演化：控制流分支演化，包含 AF (新增片段)、DF (删除片段)、FTC (改变片段类型如 ref/alt/loop/par)、FCC (改变执行条件)。
4. 4. 约束演化：包含 AC (添加约束) 和 DC (删除约束)。

💡 考点例题打靶（单选题）

【单选题】在基于 UML 顺序图对面向对象软件架构的动态行为进行演化建模时，当开发团队需要将原本单向广播的消息传递机制修改为反向回调机制时，这属于消息演化类型中的（ ）？A. SwapMessageOrder (SMO)B. ChangeMessageModule (CMM)C. OverturnMessage (OM)D. AddMessage (AM)

【答案与解析】

• • 正确答案：C
• • 详细解析：根据官方教程，OverturnMessage (OM) 专门指反转消息的发送对象与接收对象，发生于需要修改某个交互行为方向本身的时候。SMO 交换两条消息的时序，CMM 改变消息的发送或接收对象。故选 C。

🎯 模块二：10.3 演化方式分类（4 大时期 + 静态 vs 动态演化）

1. 核心考点精讲

• • 软件架构演化的 4 个时期（按时机划分，选择题高频）：
1. 1. 设计时演化 (Design-Time Evolution)：发生在体系结构模型和代码编译之前的演化。
2. 2. 运行前演化 (Pre-Execution Evolution)：发生在编译之后、执行之前的演化（修改时无须考虑运行状态，但需支持增删组件机制）。
3. 3. 有限制运行时演化 (Constrained Runtime Evolution)：设计时就规定了演化条件，系统在特定约束满足时置于“安全”模式进行预定演化。
4. 4. 运行时演化 (Runtime Evolution)：系统在运行时刻动态发生增删组件、改变拓扑结构，实现难度最高。
• • 软件架构静态演化 vs 动态演化：
• • 静态演化：系统处于停止运行状态下的修改升级（如更正性、适应性、完善性维护）。
• • 一般过程：软件理解 → 需求变更分析 → 演化计划 → 系统重构 → 系统测试。
• • 典型结构：正交软件架构 (Orthogonal Software Architecture)。将系统按功能分层与线索化，同一层组件不能相互调用，每个需求变动仅影响一条线索，极大降低波及效应。
• • 动态演化 (DSA)：系统在不停止运行/不停机的情况下完成的在线演化。
• • Cuesta 的 3 级动态性：级别 1 交互动态性（数据动态交互，结构固定）；级别 2 结构动态性（组件/连接件实例的增删，主流）；级别 3 架构动态性（结构与组件类型被重新定义，真正的动态架构）。
• • 两大实现技术：动态软件架构 (DSA) 与 动态重配置 (DR)。

💡 考点例题打靶（单选题）

【单选题】某高可用金融证券交易系统要求 7*24 小时连续运行，在进行系统升级和扩展时不能停机。架构师拟采用“正交软件架构”来设计静态演化方案，或者采用“动态重配置”来实现运行时演化。关于正交软件架构特性的说法，正确的是（ ）？A. 正交软件架构中同一层次的组件可以相互直接调用B. 正交软件架构将功能进行分层和线索化，每一个需求变更通常仅影响一条线索C. 正交软件架构专为系统在运行时刻不中断服务下的动态演化设计D. 正交软件架构会随着版本迭代导致组件间耦合度剧烈增加

【答案与解析】

• • 正确答案：B
• • 详细解析：正交软件架构通过对功能进行分层和线索化，规定同一层次中的组件不允许相互调用，因此每个需求变动仅影响一条线索，是静态演化中降低修改波及效应的典型结构。故选 B。

🎯 模块三：10.4 18 种软件架构可持续演化原则

1. 核心考点精讲

教程列举了 18 种可持续演化原则及其度量方案（选择题与案例分析常考原则名称与含义）：

1. 1. 演化成本控制原则 (ECC)：演化成本必须远小于重新开发成本 (CoE << CoRD)。
2. 2. 进度可控原则：每个演化任务的实际完成时间与预期时间的差值应尽可能小。
3. 3. 风险可控原则：经济、时间、人力、技术和环境风险必须在可控范围内。
4. 4. 主体维持原则 (AIG)：演化增量保持平稳 (AIG = 主体规模变更量 / 主体规模)，保证系统主体行为稳定。
5. 5. 系统总体结构优化原则：演化后整体布局更加合理（主要通过可靠性和性能指标衡量）。
6. 6. 平滑演化原则 (IWR)：演化速率趋于稳定 (IWR = 变更总量 / 项目规模)，避免剧烈动荡。
7. 7. 目标一致原则：阶段目标与最终目标保持一致。
8. 8. 模块独立演化原则（修改局部化）：各模块自身的演化相互独立，保证修改的影响范围是局部的。
9. 9. 复杂性可控原则：控制架构圈复杂度 CCN 不超过阈值。
10. 10. 有利于重用原则：保持高内聚、低耦合，维持或提高整体架构可重用性。
11. 11. 适应新技术原则 (TI)：降低系统对特定关键技术/厂商的依赖程度。
12. 12. 质量向好原则 (QI)：演化后的综合质量比演化前更好 (EQI > SQ)。

💡 考点例题打靶（单选题）

【单选题】在软件架构演化管理中，架构师提出：“在系统长期的版本迭代过程中，应当尽量保证每次修改仅局限于单个模块内部，且相邻版本之间的变更总量与项目总规模的比值（更新率）保持相对固定，避免出现剧烈的架构动荡。”这分别体现了软件架构演化中的（ ）原则？A. 演化成本控制原则、质量向好原则B. 修改局部化原则、平滑演化（IWR）原则C. 主体维持原则、适应新技术原则D. 复杂性可控原则、目标一致原则

【答案与解析】

• • 正确答案：B
• • 详细解析：“每次修改局限于单个模块内部”属于模块独立演化/修改局部化原则；“相邻版本更新率保持相对固定”对应平滑演化 (Invariant Work Rate, IWR) 原则。故选 B。

🎯 模块四：10.5 & 10.6 演化评估与大型网站 10 阶段演化实例

1. 核心考点精讲（案例分析与论文绝对高频！）

A. 演化评估方法（过程已知 vs 未知）

• • 演化过程已知的评估：将演化过程拆分为一系列原子演化操作序列A0, A1, A2, ..., An，对每个中间版本度量质量属性 Q0, Q1, ..., Qn，计算相邻版本的架构质量属性距离 D(i-1, i)，监控质量变化趋势。
• • 演化过程未知的评估：无法追踪中间步骤，只能对比演化前后两端点 A0 与 An 的度量结果，逆向推测发生了哪些演化操作及其驱动因素。

B. 大型网站系统架构演化的 10 个阶段（案例大题必考顺口溜！）

1. 单体架构（单机包揽应用、数据库、文件）   └─► 2. 垂直架构（应用、数据库、文件分离到不同服务器）          └─► 3. 使用缓存（本地缓存 + 远程分布式缓存 Redis/Memcached 提升读性能）                 └─► 4. 服务集群（负载均衡 Nginx/F5 分发请求，解决高并发）                        └─► 5. 数据库读写分离（主库写，从库读，主从复制）                               └─► 6. CDN 与反向代理（加速用户静态资源响应）                                      └─► 7. 分布式文件与分布式数据库（解决海量存储）                                             └─► 8. NoSQL 与搜索引擎（处理复杂非结构化检索）                                                    └─► 9. 业务拆分（分而治之，形成独立产品线）                                                           └─► 10. 分布式服务（RPC/微服务化，服务治理）

💡 考点例题打靶（下午案例分析大题）

【案例大题】某高并发互联网电商平台随着用户量和交易量的爆发式增长，原有的单体架构频繁出现数据库瓶颈与 CPU 满载问题。技术团队决定对其进行技术架构升级，演化过程经历了多个典型阶段：

• • 阶段 A：引入负载均衡器，将应用部署在多台物理服务器上组成集群。
• • 阶段 B：将数据库拆分为主库（Master）和从库（Slave），主库负责写操作，从库负责读操作。
• • 阶段 C：引入 CDN 节点与反向代理服务器，加速静态页面与图片的边缘响应。
• • 阶段 D：将单体大应用按商品、订单、支付等业务边界拆分为独立微服务，并通过 RPC 进行服务间调用。

【问题 1】（6 分）请按照大型网站架构演化的标准顺序，将上述 4 个阶段（A、B、C、D）进行正确的先后排序。

【问题 2】（9 分）请简述在“阶段 B（数据库读写分离）”中，主从库之间如何实现数据同步？读写分离主要解决了系统的什么瓶颈？它与“分布式数据库（分库分表）”在适用场景上有何本质区别？

【参考答案与采分点】：

• • 问题 1 解答：
• • 正确顺序为：阶段 A ➔ 阶段 B ➔ 阶段 C ➔ 阶段 D。（6分）
• • 解析：服务集群(A) ➔ 读写分离(B) ➔ CDN与反向代理(C) ➔ 业务拆分与分布式服务(D)。
• • 问题 2 解答：
1. 1. 数据同步机制：主库在执行写操作时记录二进制日志（Binlog），从库通过异步/半同步复制机制拉取并重放日志，实现数据同步。（3分）
2. 2. 解决瓶颈：主要解决绝大多数互联网应用中“读多写少”场景下的数据库单机高并发读取性能瓶颈。（3分）
3. 3. 与分库分表区别：读写分离侧重于 分散高并发读压力 ，数据表结构和单表容量不变；分库分表（分布式数据库）是数据库拆分的最后手段，侧重于解决 单表数据量过于庞大（海量存储） 及单库写入瓶颈。（3分）

🎯 模块五：10.7 软件架构维护与可维护性度量实践

1. 核心考点精讲

• • 软件架构知识管理 (AKM)：
• • 架构知识公式：架构知识 = 架构设计 + 架构设计决策。
• • 必须记录产生该架构方案的设计决策依据（Rationale），防止关键设计知识因人员流失而“沉没”或“腐蚀”。
• • 修改管理与隔离区域 (Region of Quiescence)：
• • 在修改管理中，建立隔离区域（静止区域），保证区域内的修改对外部系统的副作用和波及效应最小。
• • 架构可维护性度量的 6 大子指标（对组件图度量，案例与单选重灾区！）：
1. 1. 圈复杂度 (CCN)：度量整个架构的独立执行路径条数。实践表明，系统架构的圈复杂度以 CCN <= 10 为宜。
2. 2. 扇入扇出度 (FFC)：综合评估组件主动调用（扇出）与被调用（扇入）的频率。FFC 越大，依赖关系越多。
3. 3. 模块间耦合度 (CBO)：度量模块与外部模块交互的频繁程度。CBO 越大，越容易受修改影响，可维护性越差。
4. 4. 模块的响应 (RFC)：度量组件执行所需的功能数量（包括提供的接口、依赖接口及子模块功能）。
5. 5. 紧内聚度 (TCC) 与 松内聚度 (LCC)：针对具有子模块的组件度量内部依赖粘合程度。没有子模块时度量值为 not applied（内聚度视为最小）。

💡 考点例题打靶（单选题）

【单选题】在对某 Web 系统软件架构的可维护性进行定量评估时，架构师针对系统的组件图计算了 6 个子度量指标。关于这些度量指标含义与评估标准说法中，错误的是（ ）？A. 圈复杂度（CCN）度量整个架构独立执行路径条数，通常建议 CCN <= 10B. 模块间耦合度（CBO）越大，说明该模块对其他模块的依赖越少，可维护性越好C. 扇入扇出度（FFC）越大，表明该组件与外部其他组件间的接口关联与依赖关联越多D. 当某个组件内部不包含任何子组件时，其紧内聚度（TCC）与松内聚度（LCC）记为 not applied

【答案与解析】

• • 正确答案：B
• • 详细解析：CBO 度量模块间耦合程度，CBO 越大说明模块与其他模块交互越频繁、依赖越多，受修改影响的风险越高，因此可维护性越差。B 选项说法完全颠倒。故选 B。

🧠 全章核心速记口诀卡片

1. 面向对象 4 类演化：   对象有增删 (AO/DO)，消息 5 变 (AM/DM/SMO/OM/CMM)；   复合片段分支变，约束添加与删除！2. 演化 4 个时期：   设计时、运行前、有限制运行时、运行时（难度最高）！3. 正交软件架构特性：   同层组件不互调，每个变更仅单线！4. 大型网站 10 阶段演化口诀：   单体垂直用缓存，集群读写做分离；   CDN 加速分库表，NoSQL 搜索引擎；   业务拆分微服务，分布式调用降复杂！5. 6 大可维护性度量指标：   CCN 路径不超过10，FFC 关联扇入出；   CBO 耦合越小越安全，RFC 响应看功能；   TCC 与 LCC 看内聚，无子模块记 N/A！

💡 下期预告与互动：下一期我们将进入教程上篇的最后一章 第 11 章《未来信息综合技术》，带大家硬核拆解 信息物理系统（CPS）3 层架构、人工智能（AI）关键技术、数字孪生（Digital Twin）、边缘计算与云计算协同！你在刷第 10 章真题时最容易在哪个考点（大型网站演化阶段/可维护性指标 CCN/CBO）踩雷？ 欢迎在评论区交流分享！如果本文对你的备考有帮助，别忘了 点赞、在看、分享 支持一下，我们下一期见！🚀