deepread7｜论文7 软件架构演化与维护（大型网站10阶段演化可维护性）详解

ONEPSOFT | 软考学习知识库

---

deepread7｜论文7 软件架构演化与维护（大型网站10阶段演化可维护性）详解

对应清单条目：#7 论文·软件架构演化与维护（大型网站 10 阶段演化 / 可维护性）

教材来源：《系统架构设计师教程（第 2 版）》第 10 章 软件架构演化与维护（10.1–10.7）

一、知识点定位

• 主要教材出处：第 10 章 软件架构演化与维护（10.1 演化重要性、10.2 演化过程、10.3 演化方式/静态动态、10.4 18 原则、10.6 大型网站 10 阶段、10.7 维护与可维护性度量）。
• 在考试中的角色：论文高频方向（" 架构演化/系统重构 " 几乎必考），选择题考 10 阶段顺序、静态演化 5 步、维护类型、可维护性度量指标。与 #1 风格、#2 质量属性、#3 云原生弹性直接呼应。
• 与 #3 关联：云原生 " 持续演进原则 "（#3 提到）正是本章演化原则在云时代的落地；大型网站 10 阶段是 " 架构随业务生长 " 的经典叙事。

一句话定位：架构是 " 演化来的，不是设计来的 "——业务增长驱动架构一步步拆分（大型网站 10 阶段），而演化成本控制、平滑演化、模块独立演化等原则保证 " 改得起、改得稳 "；可维护性靠度量（耦合/圈复杂度）来量化。

---

二、教材原文精摘（第 10 章，原封不动）

【演化重要性】原文：

本质上讲，软件架构的演化就是软件整体结构的演化……人们通常说软件架构是演化来的，而不是设计来的。

软件架构演化使得软件系统演化更加便捷，主要有 3 个原因：①形式化可视化表示提高可构造性；②设计方案涵盖整体/配置/约束信息助于预判演化；③组件耦合描述助于动态调整。

【演化分类】原文：

针对演化过程是否处于系统运行时期，分为静态演化 (Static Evolution) 和动态演化 (Dynamic Evolution)。

静态演化 5 步骤：软件理解 → 需求变更分析 → 演化计划 → 系统重构 → 系统测试。

动态演化：系统运行期间不停止功能完成演化，更难；动态性分交互/结构/架构三级；内容包括属性改名、行为变化、拓扑改变、风格变化。

【体系结构演化 6 步骤】原文：

1.需求变化归类；2.制订体系结构演化计划；3.修改/增加/删除构件；4.更新构件相互作用；5.构件组装与测试；6.技术评审（不符则第 2–6 步迭代）。

【演化原则（关键）】原文：

18 种可持续演化原则。关键：①演化成本控制（演化成本明显小于重新开发）；②进度可控；③风险可控；④主体维持（平均增量平稳）；⑤系统总体结构优化；⑥平滑演化（速率趋稳）；⑦目标一致；⑧模块独立演化；⑨影响可控（一模块变影响可控）；⑩复杂性可控；⑪有利于重构；⑫有利于重用；⑬设计原则遵从；⑭适应新技术；⑮环境适应；⑯标准依从；⑰质量向好；⑱适应新需求。

【大型网站 10 阶段（10.6）】原文：

①单体架构（应用/数据/文件同机）；②应用与数据分离（3 台服务器）；③使用缓存（二八定律，本地 + 分布式缓存）；④使用服务集群（负载均衡分担压力）；⑤数据库读写分离（主从热备）；⑥反向代理和 CDN（缓存加速）；⑦分布式文件系统和分布式数据库；⑧NoSQL 和搜索引擎；⑨业务拆分（分产品线独立部署，消息队列分发）；⑩分布式服务（提取共用业务独立部署）。

【可维护性 / 维护类型】原文：

软件架构维护涉及架构知识管理、修改管理（建立隔离区域 Region of Quiescence 使修改影响最小）、版本管理。

维护方法 3 类：更正性维护、适应性维护、完善性维护。

可维护性度量（组件图）：①圈复杂度 CCN（实践 CCN≤10 为宜）；②扇入扇出度 FFC；③模块间耦合度 CBO（CBO 越大越易受修改影响、可维护性越差）。

---

三、系统解读（逐段讲透）

• 针对 " 演化来的不是设计来的 "：这是全章灵魂。架构不是一次定型，而是随业务持续生长。静态演化（停服改，5 步）和动态演化（不停服改，更难）是两种时机。论文写 " 我主导了架构演进 " 就讲这个。
• 针对大型网站 10 阶段：这是必背的 " 生长故事 "——从单机 → 分离 → 缓存 → 集群 → 读写分离 → CDN → 分布式存储 → NoSQL/搜索 → 业务拆分 → 分布式服务。每步都是被 " 瓶颈 " 逼出来的（性能/存储/复杂度），不是提前设计的。论文案例用这个叙事极加分。
• 针对演化原则：18 条记住最关键的几条——演化成本\<重开发（①）、平滑演化（⑥）、模块独立演化（⑧）、影响可控（⑨）、复杂性可控（⑩）。这些原则保证 " 改得起、改得稳、不失控 "。
• 针对体系结构演化 6 步：需求归类→计划→改构件→更新交互→组装测试→评审迭代。比静态 5 步多了 " 评审迭代 "，是 ABSD 式闭环（呼应 #1 ABSD）。
• 针对可维护性度量：三个硬指标——CCN 圈复杂度（≤10 好）、FFC 扇入扇出、CBO 耦合度（越大越差）。CBO 高=模块缠在一起=改一个带崩一片=难维护。这正是 " 影响可控/模块独立演化 " 原则的量化依据。
• 针对维护类型：教材明确 3 类——更正性（修 bug）、适应性（适应新环境）、完善性（加功能）；预防性维护教材片段未以原词列出（我据软件工程常规补：预防性=改前防未来问题），考试以教材三类为准。

核心一句话总结：架构随业务 " 演化 " 而非一次设计；大型网站 10 阶段是被瓶颈一步步逼出来的生长史；演化原则（成本/平滑/独立/可控）保证改得动，可维护性度量（CCN/FFC/CBO）量化改得好不好。

---

四、工程实践举例（土木工程视角）

" 改扩建/分期建设 " 与架构演化同构：

• 大型网站 10 阶段 ↔ 从自建小楼到城市综合体分期建设：
• ①单体=小楼所有功能同栋；
• ②应用数据分离=把设备机房/仓储从主楼独立出去（3 栋）；
• ③缓存=常用药材/工具就近库房（二八定律，常用物资内存放）；
• ④集群=多台同功能设备并联 + 调度（负载均衡）；
• ⑤读写分离=主备双系统（主写从读）；
• ⑥CDN/反向代理=就近配送点/前置仓；
• ⑦分布式存储=分布式仓储网络；
• ⑧NoSQL/搜索=专业检索档案系统；
• ⑨业务拆分=分业态独立运营（消息队列协同）；
• ⑩分布式服务=提取共用职能（如物业/安保）独立成共享服务中心。
• 演化成本控制原则 ↔ 改扩建 vs 推倒重建：改造老楼成本必须明显低于重建，否则不如重来——正对应 " 演化成本\<重新开发 "。
• 静态演化 5 步 ↔ 改造设计流程：理解现状（查图纸）→需求变更分析（新功能差异）→演化计划（方案 + 造价）→系统重构（施工）→系统测试（验收）。
• 模块独立演化 / 影响可控 ↔ 结构模块化：某层改造不影响其他层（像装配式独立构件），改一处不塌一片——对应 CBO 耦合度低=好维护。
• 可维护性度量 ↔ 结构可检测性：圈复杂度 CCN↔结构节点复杂度（≤10 为宜，别搞成迷宫）；CBO 耦合↔构件间连接数（连太多=一处坏全坏）。
• 隔离区域（Region of Quiescence）↔ 施工隔离区：改造时围蔽某区域，使施工影响不外溢——正是 " 修改影响最小 "。

知识点 ↔ 工程实践 对照表

教材知识点要素	你的实践场景对应	映射说明
架构演化（非一次设计）	建筑分期改扩建	随业务生长，非一次定型
大型网站 10 阶段	小楼→综合体分期建设	每步被瓶颈逼出
演化成本\<重开发	改扩建\<推倒重建	改得起才演化
静态演化 5 步	改造设计流程	理解→变更→计划→施工→验收
模块独立演化/影响可控	结构模块化（装配式）	改一处不塌一片
CBO 耦合度（大=差）	构件连接数（多=脆）	缠一起难维护
隔离区域	施工围蔽隔离区	修改影响最小
维护三类	维修/适应性改造/功能提升	更正/适应/完善

当知识点涉及生长顺序时，补充演化链（单体→…→分布式服务）：

流程图（结构化呈现）

1. ①单体
2. ②分离
3. ③缓存
4. ④集群
5. ⑤读写分离
6. ⑥CDN
7. ⑦分布式存储
8. ⑧NoSQL/搜索
9. ⑨业务拆分
10. ⑩分布式服务

运维视角提示：演化原则里的 " 平滑演化/影响可控/模块独立演化 " 正是运维友好的架构特征——每次变更影响小、可灰度、易回滚，运维才不慌。可维护性度量（CBO 低、CCN≤10）是 " 这系统好不好运维 " 的提前量指标。换句话说，架构演化设计阶段就决定了运维是天堂还是地狱——最该建立 " 演化即运维 " 的心智。