架构-软件架构设计

一、软件架构基础概念

1. 软件架构的定义

• 通俗理解：软件架构是软件系统的“骨架”，定义了系统的结构、行为和属性，就像盖房子的设计图纸，规划了房间布局、承重结构和功能分区。
• 核心作用：
  • 沟通桥梁：让技术人员（如程序员）和非技术人员（如产品经理）能理解系统设计，比如用“用户模块”“数据存储模块”描述系统组成。
  • 质量预测：通过架构设计可提前判断系统是否能满足性能、安全等需求，例如分层架构能提升可维护性。
  • 方便迭代：清晰的架构让修改局部功能更简单，比如更换数据库时只需调整数据层接口。
• 重点：架构设计本质是“需求分配”，即把用户需求拆解到不同组件（如登录需求分配给“认证组件”）。

2. 架构 vs 需求分析 vs 软件设计

• 需求分析：明确“系统要做什么”，例如“用户需要在线购物”。
• 架构设计：规划“系统如何组织”，例如设计“前端页面层-业务逻辑层-数据库层”三层架构。
• 软件设计：细化“具体实现细节”，例如设计数据库表结构、编写接口文档。

二、基于架构的软件开发（ABSD方法）

1. 核心思想

• 架构驱动开发：以业务需求（如电商系统的订单处理）、质量需求（如高并发）和功能需求（如商品搜索）为驱动，设计系统架构。
• 三大基础：
  • 功能分解：将复杂功能拆分为模块，如电商系统拆分为“用户模块”“订单模块”“支付模块”。
  • 架构风格选择：根据需求选合适的架构模式，如高并发场景选“事件驱动”风格。
  • 软件模板：复用成熟的架构模板，如微服务架构模板。

2. 开发过程（高频考点）

1. 架构需求：收集需求并转化为架构目标，例如“支持10万用户并发访问”。
2. 架构设计：确定架构风格（如分层架构）、组件划分（如前端、后端）。
3. 架构文档化：编写《架构规格说明书》，明确组件接口和交互规则，确保开发团队理解一致。
4. 架构复审：检查架构是否存在缺陷，例如“单点故障”风险。
5. 架构实现：开发组件并组装，如用Spring Boot开发后端微服务。
6. 架构演化：根据需求变化升级架构，例如从单体架构演进为微服务架构。

3. 实际案例

• 电商系统开发：用ABSD方法，先分解出“商品展示”“购物车”“支付”等功能模块，选择“微服务架构”应对高并发，编写文档定义各服务接口，定期复审确保架构支持业务增长。

三、软件架构风格（核心考点）

1. 数据流风格

• 特点：数据像“水流”一样依次经过多个处理单元（过滤器），前一个的输出是后一个的输入。
• 子风格：
  • 管道-过滤器：如编译器，源码依次经过“词法分析器（过滤器）→语法分析器（过滤器）→代码生成器（过滤器）”，每个过滤器独立处理数据。
  • 批处理：一次性处理大量数据，如银行每月批量生成对账单。
• 适用场景：数据处理流程固定、需要高可扩展性的场景（如日志处理系统）。

2. 调用/返回风格

• 特点：通过“函数调用”实现模块交互，类似“主程序调用子程序，子程序返回结果”。
• 子风格：
  • 分层架构：将系统分为多层，每层提供特定功能，下层向上层提供接口，如操作系统的“硬件层→驱动层→应用层”。
  • 面向对象：通过对象方法调用实现交互，如Java程序中“用户对象调用支付对象的支付方法”。
• 实际案例：手机App的“界面层（调用）→业务逻辑层（调用）→数据层”分层架构，每层分工明确，便于维护。

3. 独立构件风格（事件驱动）

• 特点：构件通过“事件”交互，当某个事件发生（如按钮点击），相关构件自动响应，无需显式调用。
• 典型场景：GUI程序（如Windows操作系统），点击“保存”按钮触发“文件保存事件”，相关组件自动执行保存逻辑。
• 优缺点：
  • 优点：松耦合，新增功能只需注册事件即可，如电商系统新增“库存不足预警”功能，无需修改订单模块。
  • 缺点：事件处理顺序难控制，可能出现逻辑混乱。

4. 虚拟机风格

• 特点：通过“解释器”模拟运行环境，让代码在不同平台运行，如Java字节码在Java虚拟机（JVM）中执行。
• 适用场景：跨平台开发，如“一次编写，到处运行”的Java程序，或脚本语言（Python）的解释执行。

5. 以数据为中心风格

• 特点：有一个“中央数据仓库”，所有构件都访问该仓库，如数据库、黑板系统（多个知识源共享数据）。
• 案例：医疗诊断系统，多个诊断模块（知识源）共享患者病历数据（黑板），共同分析病情。

重点总结

• 必背风格：管道-过滤器（编译器）、分层架构（操作系统）、事件驱动（GUI）、虚拟机（Java跨平台）、黑板系统（AI诊断）。
• 风格判断：根据数据流动方式（数据流vs事件驱动）、模块交互方式（调用vs事件）选择合适的风格。

四、特定领域软件架构（DSSA）

1. 定义

• 针对特定领域（如医疗、金融）设计的通用架构，包含领域模型、参考需求和参考架构，可快速生成该领域的具体应用。
• 例：金融领域的“支付结算架构”，可复用账户管理、交易处理、风险控制等模块。

2. 核心活动

1. 领域分析：提取该领域共性需求，如医疗系统的“患者信息管理”“电子病历”。
2. 领域设计：设计通用架构，如医疗系统的“患者数据中心+业务模块”。
3. 领域实现：开发可复用构件，如病历解析组件、处方生成组件。

3. 考点

• DSSA作用：提高特定领域软件的开发效率和质量，避免重复造轮子。
• 参与人员：领域专家（提供行业知识）、领域分析师（分析需求）、领域设计师（设计架构）、领域实现人员（开发构件）。

五、软件架构评估（质量属性与评估方法）

1. 关键质量属性（必考）

质量属性	定义	实际案例	提升战术
性能	系统响应速度，如“响应时间＜1s”	电商系统双11高并发处理	引入并发（多线程）、资源调度（优先处理支付请求）
可用性	系统正常运行时间比例	银行系统7×24小时可用	冗余设计（主备服务器）、故障切换（1分钟内切换到备用机）
安全性	防止非授权访问，如抵御SQL注入	支付系统加密用户数据	身份验证（密码+验证码）、数据加密（HTTPS）
可修改性	方便修改系统，如2人周内修改报表模块	微信新增功能不影响现有模块	模块化设计（各模块独立）、接口隔离（修改模块不影响其他模块）

2. 评估方法

• SAAM：主要评估可修改性，通过模拟“修改某模块需要改动多少其他模块”判断架构优劣。
• ATAM：综合评估性能、可用性、安全性等，通过“场景分析”识别架构中的权衡点（如提升性能可能降低安全性）。

3. 实际应用

• 电商系统评估：用ATAM分析“高并发下性能与可用性的权衡”，确定是否采用“分布式缓存（提升性能）+ 多机房容灾（提升可用性）”方案。

六、构件与中间件技术

1. 构件（软件复用核心）

• 定义：可独立部署、可替换的功能单元，如“登录构件”“支付构件”。
• 复用流程：
  1. 检索构件：通过关键字（如“支付”）或刻面检索（按“应用领域+功能”）从构件库查找。
  2. 组装构件：通过接口连接，如“登录构件”调用“用户数据库构件”的查询接口。
• 案例：复用开源构件（如Spring框架的“事务管理构件”），快速实现系统功能。

2. 中间件（系统集成桥梁）

• 定义：位于操作系统和应用程序之间的软件，解决异构系统交互问题，类似“翻译官”让不同语言的系统沟通。
• 分类：
  • 通信中间件：实现跨平台通信，如消息队列（Kafka）用于异步数据传输。
  • 事务中间件：保证交易原子性，如银行转账时确保“扣款”和“入账”同时成功。
  • Web中间件：处理Web请求，如Tomcat作为Web服务器中间件。
• 优点：简化开发（无需处理底层通信）、提高复用（中间件可通用）。

3. 重点

• 构件标准：CORBA（跨语言跨平台）、J2EE（Java企业级构件）、DNA 2000（微软构件标准）。
• 中间件作用：屏蔽硬件/操作系统差异，让应用开发更专注业务逻辑。

七、高频考点总结（加粗标注）

1. 软件架构定义与作用：架构是高层抽象，核心作用是沟通、预测质量、方便迭代，架构设计是需求分配。
2. ABSD方法：三大基础（功能分解、架构风格、软件模板），开发过程六阶段（需求→设计→文档化→复审→实现→演化）。
3. 架构风格：五大风格（数据流、调用/返回、独立构件、虚拟机、数据中心）及其子风格特点、案例。
4. 质量属性：性能、可用性、安全性、可修改性的定义、案例及提升战术。
5. 构件与中间件：构件复用流程、中间件分类及作用，常见构件标准（CORBA、EJB）。
6. 评估方法：SAAM（可修改性）、ATAM（多质量属性权衡）。

总结

软件架构设计是系统开发的核心，掌握其概念、风格、评估方法及构件技术，既能应对，也能在实际开发中设计出高效、可扩展的系统。重点记忆高频考点，结合实际案例理解，如用“电商系统”“编译器”等例子加深对架构风格和质量属性的理解。