架构-软件架构设计
一、软件架构基础概念
1. 软件架构的定义
- 通俗理解：软件架构是软件系统的“骨架”，定义了系统的结构、行为和属性，就像盖房子的设计图纸，规划了房间布局、承重结构和功能分区。
- 核心作用：
- 沟通桥梁：让技术人员（如程序员）和非技术人员（如产品经理）能理解系统设计，比如用“用户模块”“数据存储模块”描述系统组成。
- 质量预测：通过架构设计可提前判断系统是否能满足性能、安全等需求，例如分层架构能提升可维护性。
- 方便迭代：清晰的架构让修改局部功能更简单，比如更换数据库时只需调整数据层接口。
- 重点：架构设计本质是“需求分配”，即把用户需求拆解到不同组件（如登录需求分配给“认证组件”）。
2. 架构 vs 需求分析 vs 软件设计
- 需求分析：明确“系统要做什么”，例如“用户需要在线购物”。
- 架构设计：规划“系统如何组织”，例如设计“前端页面层-业务逻辑层-数据库层”三层架构。
- 软件设计：细化“具体实现细节”，例如设计数据库表结构、编写接口文档。
二、基于架构的软件开发（ABSD方法）
1. 核心思想
- 架构驱动开发：以业务需求（如电商系统的订单处理）、质量需求（如高并发）和功能需求（如商品搜索）为驱动，设计系统架构。
- 三大基础：
- 功能分解：将复杂功能拆分为模块，如电商系统拆分为“用户模块”“订单模块”“支付模块”。
- 架构风格选择：根据需求选合适的架构模式，如高并发场景选“事件驱动”风格。
- 软件模板：复用成熟的架构模板，如微服务架构模板。
2. 开发过程（高频考点）
- 架构需求：收集需求并转化为架构目标，例如“支持10万用户并发访问”。
- 架构设计：确定架构风格（如分层架构）、组件划分（如前端、后端）。
- 架构文档化：编写《架构规格说明书》，明确组件接口和交互规则，确保开发团队理解一致。
- 架构复审：检查架构是否存在缺陷，例如“单点故障”风险。
- 架构实现：开发组件并组装，如用Spring Boot开发后端微服务。
- 架构演化：根据需求变化升级架构，例如从单体架构演进为微服务架构。
3. 实际案例
- 电商系统开发：用ABSD方法，先分解出“商品展示”“购物车”“支付”等功能模块，选择“微服务架构”应对高并发，编写文档定义各服务接口，定期复审确保架构支持业务增长。
三、软件架构风格（核心考点）
1. 数据流风格
- 特点：数据像“水流”一样依次经过多个处理单元（过滤器），前一个的输出是后一个的输入。
- 子风格：
- 管道-过滤器：如编译器，源码依次经过“词法分析器（过滤器）→语法分析器（过滤器）→代码生成器（过滤器）”，每个过滤器独立处理数据。
- 批处理：一次性处理大量数据，如银行每月批量生成对账单。
- 适用场景：数据处理流程固定、需要高可扩展性的场景（如日志处理系统）。
2. 调用/返回风格
- 特点：通过“函数调用”实现模块交互，类似“主程序调用子程序，子程序返回结果”。
- 子风格：
- 分层架构：将系统分为多层，每层提供特定功能，下层向上层提供接口，如操作系统的“硬件层→驱动层→应用层”。
- 面向对象：通过对象方法调用实现交互，如Java程序中“用户对象调用支付对象的支付方法”。
- 实际案例：手机App的“界面层（调用）→业务逻辑层（调用）→数据层”分层架构，每层分工明确，便于维护。
3. 独立构件风格（事件驱动）
- 特点：构件通过“事件”交互，当某个事件发生（如按钮点击），相关构件自动响应，无需显式调用。
- 典型场景：GUI程序（如Windows操作系统），点击“保存”按钮触发“文件保存事件”，相关组件自动执行保存逻辑。
- 优缺点：
- 优点：松耦合，新增功能只需注册事件即可，如电商系统新增“库存不足预警”功能，无需修改订单模块。
- 缺点：事件处理顺序难控制，可能出现逻辑混乱。
4. 虚拟机风格
- 特点：通过“解释器”模拟运行环境，让代码在不同平台运行，如Java字节码在Java虚拟机（JVM）中执行。
- 适用场景：跨平台开发，如“一次编写，到处运行”的Java程序，或脚本语言（Python）的解释执行。
5. 以数据为中心风格
- 特点：有一个“中央数据仓库”，所有构件都访问该仓库，如数据库、黑板系统（多个知识源共享数据）。
- 案例：医疗诊断系统，多个诊断模块（知识源）共享患者病历数据（黑板），共同分析病情。
重点总结
- 必背风格：管道-过滤器（编译器）、分层架构（操作系统）、事件驱动（GUI）、虚拟机（Java跨平台）、黑板系统（AI诊断）。
- 风格判断：根据数据流动方式（数据流vs事件驱动）、模块交互方式（调用vs事件）选择合适的风格。
四、特定领域软件架构（DSSA）
1. 定义
- 针对特定领域（如医疗、金融）设计的通用架构，包含领域模型、参考需求和参考架构，可快速生成该领域的具体应用。
- 例：金融领域的“支付结算架构”，可复用账户管理、交易处理、风险控制等模块。
2. 核心活动
- 领域分析：提取该领域共性需求，如医疗系统的“患者信息管理”“电子病历”。
- 领域设计：设计通用架构，如医疗系统的“患者数据中心+业务模块”。
- 领域实现：开发可复用构件，如病历解析组件、处方生成组件。
3. 考点
- DSSA作用：提高特定领域软件的开发效率和质量，避免重复造轮子。
- 参与人员：领域专家（提供行业知识）、领域分析师（分析需求）、领域设计师（设计架构）、领域实现人员（开发构件）。
五、软件架构评估（质量属性与评估方法）
1. 关键质量属性（必考）
| 质量属性 | 定义 | 实际案例 | 提升战术 |
|---|---|---|---|
| 性能 | 系统响应速度，如“响应时间＜1s” | 电商系统双11高并发处理 | 引入并发（多线程）、资源调度（优先处理支付请求） |
| 可用性 | 系统正常运行时间比例 | 银行系统7×24小时可用 | 冗余设计（主备服务器）、故障切换（1分钟内切换到备用机） |
| 安全性 | 防止非授权访问，如抵御SQL注入 | 支付系统加密用户数据 | 身份验证（密码+验证码）、数据加密（HTTPS） |
| 可修改性 | 方便修改系统，如2人周内修改报表模块 | 微信新增功能不影响现有模块 | 模块化设计（各模块独立）、接口隔离（修改模块不影响其他模块） |
2. 评估方法
- SAAM：主要评估可修改性，通过模拟“修改某模块需要改动多少其他模块”判断架构优劣。
- ATAM：综合评估性能、可用性、安全性等，通过“场景分析”识别架构中的权衡点（如提升性能可能降低安全性）。
3. 实际应用
- 电商系统评估：用ATAM分析“高并发下性能与可用性的权衡”，确定是否采用“分布式缓存（提升性能）+ 多机房容灾（提升可用性）”方案。
六、构件与中间件技术
1. 构件（软件复用核心）
- 定义：可独立部署、可替换的功能单元，如“登录构件”“支付构件”。
- 复用流程：
- 检索构件：通过关键字（如“支付”）或刻面检索（按“应用领域+功能”）从构件库查找。
- 组装构件：通过接口连接，如“登录构件”调用“用户数据库构件”的查询接口。
- 案例：复用开源构件（如Spring框架的“事务管理构件”），快速实现系统功能。
2. 中间件（系统集成桥梁）
- 定义：位于操作系统和应用程序之间的软件，解决异构系统交互问题，类似“翻译官”让不同语言的系统沟通。
- 分类：
- 通信中间件：实现跨平台通信，如消息队列（Kafka）用于异步数据传输。
- 事务中间件：保证交易原子性，如银行转账时确保“扣款”和“入账”同时成功。
- Web中间件：处理Web请求，如Tomcat作为Web服务器中间件。
- 优点：简化开发（无需处理底层通信）、提高复用（中间件可通用）。
3. 重点
- 构件标准：CORBA（跨语言跨平台）、J2EE（Java企业级构件）、DNA 2000（微软构件标准）。
- 中间件作用：屏蔽硬件/操作系统差异，让应用开发更专注业务逻辑。
七、高频考点总结（加粗标注）
- 软件架构定义与作用：架构是高层抽象，核心作用是沟通、预测质量、方便迭代，架构设计是需求分配。
- ABSD方法：三大基础（功能分解、架构风格、软件模板），开发过程六阶段（需求→设计→文档化→复审→实现→演化）。
- 架构风格：五大风格（数据流、调用/返回、独立构件、虚拟机、数据中心）及其子风格特点、案例。
- 质量属性：性能、可用性、安全性、可修改性的定义、案例及提升战术。
- 构件与中间件：构件复用流程、中间件分类及作用，常见构件标准（CORBA、EJB）。
- 评估方法：SAAM（可修改性）、ATAM（多质量属性权衡）。
总结
软件架构设计是系统开发的核心，掌握其概念、风格、评估方法及构件技术，既能应对，也能在实际开发中设计出高效、可扩展的系统。重点记忆高频考点，结合实际案例理解，如用“电商系统”“编译器”等例子加深对架构风格和质量属性的理解。