原子标签索引：[概念×14 | 机制×3 | 流程×2 | 判据×6 | 分类×5 | 案例×3 | 数据×4] 上游：无（开篇章） 下游：为第2~48章提供架构总概念框架，架构风格分类被后续各架构章引用

标准表述

• 系统架构（IEEE 1471-2000）：体现在组件中的系统基本组织、组件彼此关系及与环境的关系、指导其设计与发展的原则。
• 通俗定义：系统架构是系统整体的高层次结构表示，是系统的骨架和根基，决定系统的健壮性和生命周期长短。
• 架构设计作用（5条）：解决复杂需求分析；解决非功能属性设计；解决生命周期长、扩展性高的整体结构问题；解决基于组件的集成问题；解决业务流程再造难题。
• 软件危机：20世纪60年代中期爆发，表现为软件生产效率低、质量差；NATO 于 1968、1969 两次会议提出"软件工程"概念。
• 软件架构发展四阶段：基础研究（1968—1994）→ 概念体系与核心技术形成（1999—2000）→ 理论体系完善与发展（1996 至今）→ 普及应用（2000 至今）。
• 组件化 ≠ 模块化 ≠ 应用集成：模块化仅逻辑切分、物理未隔离；组件化更独立（可组装、可插拔，仅依赖平台/容器）；应用集成是无缝整合成单一系统。
• 2000 年 IEEE 1471-2000 发布，第一次给出软件架构的形式化标准。
• 架构风格五类（Garlan & Shaw 划分）：数据流、调用/返回、独立组件、虚拟机、仓库。
• 建模方法四种模型：结构、框架、动态、过程。
• 4+1 视角（Kruchten，1995）：逻辑、过程（进程）、物理、开发、场景；场景视图是"+1"。
• 架构设计师职责＝技术领导；技术层面三大任务：抽象设计、非功能设计、关键技术设计。
• 架构设计师三类任务：领导协调整个技术活动；推动主要技术决策并表达为架构；确定架构并文档化（含需求、设计、实施、部署视图）。
• 优秀架构师 6 种角色特质（Pat Kua）：领导者、开发者、系统综合者、企业家思维、战略/战术权衡思维、良好沟通。
• 架构工作主题就是权衡；架构师要习惯不完美与有条件的不精确。
• 成长关键三力：判断力（识别复杂度与脆弱点）、执行力（用合适方案解决复杂度）、创新力（创造新解法）。

蒸馏笔记

概念

• 架构：组件中的系统基本组织＋关系＋环境＋指导原则（IEEE 1471-2000，针对软件密集系统）。
• 系统：组织起来完成特定功能的组件集；含应用、子系统、系统之系统、产品线、企业等。
• 环境/上下文：决定系统开发、运作、政策的外部设置。
• 任务：利益相关者通过系统达到目标的用途或操作。
• 软件架构：刻画软件系统整体抽象结构的手段，软件工程的重要分支。
• 架构设计师：负责系统架构的人、团队或组织（IEEE 1471-2000）；系统或产品线的设计责任人。
• 模块化开发：把软件分解成若干小而简单的部分，分而治之；涉及"系统如何分解成模块"的规则。
• SOA（面向服务架构）：基于标准的方法，通过整合重用现有应用实现服务组件化、快速组装新业务。
• 软件产品线：一组具有公共需求集的软件系统，由标准产品线架构定制＋可重用组件集成得到。
• 组件：可组装、可插拔的程序集；运行仅依赖平台或容器，组件间无直接耦合。
• 冯·诺伊曼结构：EDVAC 五部件（运算器、控制器、存储器、输入、输出），二进制运算，程序存于存储器。
• 信息化背景：MIS 在企业广泛使用 → 业务与数据处理分离的分层思想是软件架构的雏形。
• 架构演化名词：运行时刻的架构变化＝架构动态性；静态修改＝架构扩展；两者同属架构适应性与演化范畴。
• 架构发现：从已有系统中提取架构，属逆向工程。

机制

• 软件危机 →(手工作坊、理论方法不系统) 效率低成本高 →(NATO 会议) 软件工程 →(规模与复杂性再升) 第二次危机 →(重用与组件化) 软件架构应运而生。
• 模块化 →(抽象、封装、分解、层次化) 重用水平提升 →(业务灵活性诉求) SOA 思想。
• 架构影响软件生命周期各阶段：需求阶段保证可追踪性与一致性；设计阶段是研究最多之处；实现阶段用程序语言表示设计；维护阶段依赖架构规定的可扩展、可替换等属性。

流程

软件架构发展四阶段 1. 基础研究（1968—1994）：术语首提于 NATO 会议；模块化方法奠基；MIS 分层雏形。 2. 概念体系与核心技术形成（1999—2000）：1991 首次定义；1992 Perry&Wolf 公式化阐述；1996 Shaw&Garlan 专著；2000 IEEE 1471 形式化标准；组件化技术为最大成果。 3. 理论体系完善与发展（1996 至今）：描述表示（C2SADL、Wright、ACME、UniCon、Rapide 等）、分析设计测试、发现演化重用、开发方法、架构风格五研究方向。 4. 普及应用（2000 至今）：1999 首届 IFIP 架构会议；ADML（基于 XML 的架构描述语言）；软件产品线分支兴起。

从工程师到架构师成长路径（关键：积累经验、拓宽视野、深度思考；10000 小时定律） 1. 工程师（1~3 年）：在别人指导下完成开发，积累编程语言、数据结构、环境等基础。 2. 高级工程师（3~5 年）：独立完成开发；深挖 Why 与理论（范式、设计模式、SOLID、缓存理论）。 3. 技术专家（4~8 年）：某领域专家，可修改、扩展、优化架构；关键是拓展技术宽度。 4. 初级架构师（5~8 年）：独立完成一个系统的架构设计；关键是形成自己的架构设计方法论。 5. 中级架构师（8~10 年以上）：能完成复杂系统架构（高性能、高可用、可扩展、海量存储）；关键是技术深度与理论积累。 6. 高级架构师（10 年以上）：创造新的架构模式（如 MapReduce、Docker 容器化），开创新技术潮流。

分类体系

• 常用架构模式 5 类：分层架构（表现/业务/持久/数据库四层，层间经接口通信，不可跳层）；事件驱动架构（事件队列、分发器、事件通道、事件处理器）；微核/插件架构（小内核＋独立插件，插件间通信降到最低）；微服务架构（SOA 升级，独立部署单元，REST/SOAP 远程通信；三种实现模式：RESTful API、RESTful 应用、集中消息）；云架构（处理单元＋虚拟中间件，无中央数据库，访问量增减启停处理单元）。
• 云架构虚拟中间件 4 组件：消息中间件（请求分配）、数据中间件（数据同步复制）、处理中间件（跨类型协调，可选）、部署中间件（启停与负载监控）。
• 架构风格 5 类（Garlan & Shaw）：数据流、调用/返回、独立组件、虚拟机、仓库。
• 架构模型 4 种：结构模型（最直观普遍，核心是架构描述语言）、框架模型（侧重整体）、动态模型（研究"大颗粒"行为，激励型）、过程模型（研究构造步骤与过程）。
• 架构师分类两套：组织上 5 类——业务、主题领域、技术、项目、系统架构师；按关注领域 4 类（参考微软）——企业架构师 EA、基础结构架构师 IA、特定技术架构师 TSA、解决方案架构师 SA。

判据

• 模块分解 6 规则：最高内聚（一种功能高内聚、三种以上低内聚）；最低耦合；模块大小适度；调用链嵌套不可过深；接口简单精炼（扇入扇出不宜大）＋信息隐蔽；尽量复用已有模块。
• 架构风格适用场景：管道-过滤器→独立步骤分解；主程序/子系统、面向对象→组件内部设计；虚拟机→解释器、专家系统；C/S、B/S→数据与处理分布＋网络连接；平台/插件→可扩展插件应用；MVC→用户交互程序；SOA→企业集成；C2→GUI 软件。现代大型软件混合多种风格。
• 架构设计师与项目经理分工：架构师＝技术领导、拥有技术决策权威；项目经理关注资源、进度、成本；两者是项目的公共角色。
• 团队履行架构师角色时：必须设首席架构师（架构团队的单点协调人），否则难以产生内聚架构。
• 优秀架构师评价：无法用统一标准，可按能力评价；6 种角色特质均需良好专业知识；与开发人员待在一起、花时间在代码上是缓解"象牙塔式架构师"的最佳方法。
• 架构师应具备的专业素质 8 项：业务领域知识、技术知识（关注重要因素而非细节）、设计技能（多年积累）、编程技能（应编写一定量代码）、沟通能力（软技能中最重要）、决策能力、知晓组织策略、谈判专家（尽早降风险、精炼需求）。

案例

• ENIAC（1946，第一台电子计算机）→ 冯·诺伊曼针对其不足提出 EDVAC，奠定现代计算机结构。出处：1.1 节。
• 1995 年 Standish Group 调查 8000 个美国软件项目：84% 无法按时按需完成，超 30% 夭折，耗费超预算 189%。出处：1.1.1。
• 谷歌分布式存储 / MapReduce / 列式存储开创大数据时代；Docker 在虚拟机成熟背景下创造容器化潮流（高级架构师创造新架构模式之例证）。出处：1.3.2。

数据

• 架构关键技术发展 70 余年（自 20 世纪 40 年代编程算法起），主线：模块化/面向对象编程 → 构件技术 → 面向服务开发 → 云技术。
• 知识结构 10 方面：战略规划、业务流程建模、信息数据架构、技术架构设计与实现、应用系统架构解决、基础 IT 与资源调配、信息安全、IT 审计治理与需求分析、可靠性与生命周期质量保障、新技术理解分析。
• 软件架构研究 20 世纪 90 年代集中于：架构风格（模式）、架构描述语言、架构文档、形式化方法。
• 架构分析常用方法：SAAM、ATAM、CBAM、SBAR、ALPSM、SAEM。

易错点 / 边界情况

• 四阶段年份在原书中即有交叉（"概念体系形成 1999—2000"与"理论完善 1996 至今"），作答以书上年份区间为准，勿自行"修正"。
• 组件化、模块化、应用集成三者关系是高频混淆点：组件化比模块化更独立，比应用集成结合更紧密。
• 4+1 中的"1"是场景（Scenarios）视图，非"物理视图"；五个视角合起来才反映架构全貌。
• 架构风格五类的划分人是 David Garlan 和 Mary Shaw（书原文写 Garland/Shaw），勿与 Perry & Wolf（{elements, forms, rationale}）混淆。
• 架构师分类有两套口径（组织 5 类 / 领域 4 类），考题常只给其中一套的简称，需能互认。
• "软件架构"术语 1968 年首提但当时无明确定义；80 年代"架构"多指计算机物理结构或指令集体系。
• 初级架构师 vs 技术专家：前者基于架构设计方法论设计、能清晰阐述理由；后者更多基于经验；系统复杂度不高时两者实际差别不明显。
• 架构设计师可以是个人、小组或团队；一人可履行多个角色，但团队履行时必须有首席架构师。