2024 年软件系统设计考题解答¶
来源：综合自
exams/软件系统设计-复习-EagleBear.pdf中标记为【2024】的考题 注：本考题集由 EagleBear 复习资料中的 2024 年标签汇总而成，题目具体编排可能与真实考卷有差异。
1. 在设计软件时应用了哪些通用设计策略？为每个策略提供一个带有软件架构的简明工作示例¶
六种通用设计策略：
| 策略 | 示例 |
|---|---|
| 分解（Decomposition） | 将系统分解为前端、业务逻辑、数据访问三层 |
| 抽象（Abstraction） | 将系统抽象为组件和连接器 |
| 逐步求精/分而治之 | 先定义接口，再逐步实现具体逻辑 |
| 生成与测试（Generate and Test） | 针对关键路径生成测试用例验证设计 |
| 迭代-增量细化 | ADD 方法多次迭代直到满足所有 ASR |
| 复用元素（Reuse of Elements） | 重用 MVC、分层等成熟架构模式 |
参考课件：
slides/Lecture 01 - Attributes Driven Design.pdf
2. 描述 4+1 视图¶
五种视图：逻辑视图（功能需求）→ 过程视图（并发交互）→ 开发视图（代码组织）→ 物理视图（硬件部署）→ +1 场景/用例视图（架构验证）。
参考课件：
slides/2026SUG_SysArch1_introduction.pdf
3. Software Architect 是什么？写出其五种职责¶
架构师定义¶
软件架构师（Software Architect）是负责软件系统架构设计的专业人员： - 监督施工并确保符合计划 - 在设计变更、危机和模糊性中引导愿景 - 对软件构造专业人员（程序员、工程师、设计师）进行监督
五种职责¶
| 职责 | 说明 |
|---|---|
| 1. 联络（Liaison） | 作为客户、技术团队、业务/需求分析师之间的联络人；与管理或营销部门沟通 |
| 2. 软件工程（Software Engineering） | 推广和应用软件工程最佳实践，确保设计质量和代码规范 |
| 3. 技术知识（Technical Knowledge） | 对技术领域有深入理解，能做出合理的技术选型决策 |
| 4. 风险管理（Risk Management） | 识别和管理与设计、技术选择相关的风险 |
| 5. 愿景引导（Vision Leadership） | 在变更和不确定性中保持架构的一致性，引导技术方向 |
参考课件：
slides/2026SUG_SysArch1_introduction.pdf（架构师角色）
4. 如何对质量属性场景建模？画出 Interoperability 和 Performance 的刺激-响应图¶
建模方法¶
六部分组成：刺激源（Source）→ 刺激（Stimulus）→ 工件（Artifact）→ 环境（Environment）→ 响应（Response）→ 响应度量（Response Measure）
Interoperability¶
刺激源: 车辆信息系统 → 刺激: 发送当前位置和其他车辆信息 → 工件: 路况监控系统 → 环境: 系统运行前已知 → 响应: 信息合并，覆盖到Google地图并广播 → 度量: 99.99%时间正确
Performance¶
参考课件：
slides/2026SUG_SysArch2_quality attributes.pdf
5. Layered Pattern 和 Multi-tier Pattern 的区别¶
| 维度 | Layered Pattern | Multi-tier Pattern |
|---|---|---|
| 所属风格 | Module Style（模块风格） | Allocation Style（分配风格） |
| 关注层面 | 代码/模块的组织（逻辑分层） | 物理部署的组织（部署分层） |
| 层次关系 | 严格的分层使用关系（关注点分离） | 逻辑组合，没有强依赖关系 |
| 典型应用 | OSI 网络模型、Java EE 分层 | Web 三层部署（Web Server、App Server、DB Server） |
参考课件：
slides/软件架构模式_update_2.pdf，slides/2026SUG_SysArch1_introduction.pdf
6. 描述架构设计中架构模式和决策之间的关系。给出四种决策的名称及目的¶
关系：决策比模式更简单，是构成模式的组成部分。架构模式通常将多个决策组合在一起。
四种决策：
| 决策名称 | 目的 |
|---|---|
| 心跳（Heartbeat） | 可用性：定期检测组件故障 |
| 冗余（Redundancy） | 可用性：多实例容错 |
| 负载均衡（Load Balancing） | 性能：分发请求 |
| 加密（Encryption） | 安全性：数据保护 |
参考课件：
slides/Lecture 01 - Attributes Driven Design.pdf
7. 微服务部署的容器模式：上下文、需求、优势和限制¶
上下文与需求¶
微服务架构中需要将众多小型服务独立部署和管理，容器技术（如 Docker/Kubernetes）提供了标准化的部署单元。
各种部署模式对比¶
| 模式 | 优势 | 限制 |
|---|---|---|
| 容器（Container） | 轻量级、灵活、延迟可预测 | 需要管理 Docker 编排框架及其底层虚拟机 |
| 无服务器（Serverless） | 消除管理 OS 和运行时状态、自动弹性配置、基于请求定价 | 长尾延迟、基于事件/请求的编程模型受限 |
| 虚拟机（VM） | 支持多种后续模式、功能强大 | 重量级、部署慢、资源消耗大 |
| 服务部署平台（PaaS） | 功能强大 | 额外的技术学习和资源成本 |
| 单主机/多主机 | 简单 | 扩展性受限 |
容器模式的选择考量¶
- 小型简单应用 → Serverless
- 需要灵活性和可控性 → 容器
- 大型复杂系统 → VM 或混合方案
参考课件：
slides/Microservices Patterns.pdf
8. 从设计策略、优势、限制等角度解释分层架构、SOA 和微服务架构之间的差异¶
| 维度 | 分层架构（Layered） | SOA | 微服务架构（MSA） |
|---|---|---|---|
| 设计策略 | 将系统分解为抽象级别递增的层次 | 将系统分解为可重用的业务服务 | 将系统分解为围绕业务能力的小型独立服务 |
| 服务间通信 | 层间直接调用 | 智能管道（ESB），重量级协议（SOAP/WS-*） | 哑管道（消息代理），轻量级协议（REST/gRPC） |
| 数据管理 | 层间共享数据模型 | 全局数据模型和共享数据库 | 每个服务独立数据库 |
| 优势 | 关注点分离，易于理解和开发 | 服务重用，松耦合，互操作性好 | 独立部署和扩展，技术栈灵活，高可伸缩 |
| 限制 | 性能开销，严格的层次约束 | ESB 可能成为瓶颈，复杂度高 | 分布式系统复杂性，运维成本高 |
| 典型服务规模 | N/A | 较大的单体服务 | 较小的微服务 |
参考课件：
slides/软件架构模式_update_2.pdf（分层/SOA），slides/Microservices Patterns.pdf
9. DDD（Domain-Driven Design）的一般过程¶
核心原理¶
- 业务驱动（而非数据驱动）：业务模型是软件开发的核心，开发者应深入理解业务领域
- 领域划分：将业务领域划分为不同的子域（核心域、支撑域、通用域），每个子域有特定业务逻辑
- 统一语言（Ubiquitous Language）：开发者和业务专家使用统一语言沟通，减少误解
- 限界上下文（Bounded Context）：定义模型的边界，明确不同模型间的交互规则
一般过程¶
| 阶段 | 活动 |
|---|---|
| 战略设计 | 分析业务领域，划分子域和限界上下文，建立统一语言，识别核心域 |
| 战术设计 | 在限界上下文内设计实体（Entity）、值对象（Value Object）、聚合（Aggregate）、领域服务（Domain Service）、领域事件（Domain Event）、仓储（Repository） |
| 实现 | 根据战术设计模型编写代码，确保模型与实现一致 |
参考课件：
slides/Lecture 01 - Attributes Driven Design.pdf（DDD 相关），exams/软件系统设计-复习-EagleBear.pdf（DDD 参考）
10. 企业架构（Enterprise Architecture）的基本功能¶
企业架构的基本功能包括：
- 战略对齐（Strategic Alignment）：确保 IT 投资与业务战略一致
- 标准化与整合（Standardization & Integration）：提供技术标准，促进系统间互操作
- 决策支持（Decision Support）：为技术选型和架构决策提供框架
- 变更管理（Change Management）：管理 IT 资产的生命周期和演进
- 治理与合规（Governance & Compliance）：确保 IT 系统符合法规和内部政策
企业架构通过从业务、数据、应用、技术四个维度描述企业 IT 全景，帮助组织实现业务与 IT 的协调。
参考课件：
slides/2026SUG_SysArch1_introduction.pdf（企业架构相关）
11. 材料题：在线课程平台从分层架构迁移到微服务架构¶
场景：一个在线课程平台是分层架构的，需要迁移到微服务架构。
迁移策略¶
采用 Strangler Fig Pattern（绞杀者模式） 逐步迁移：
Phase 1: 识别服务边界
├── 课程管理服务（Course Service）
├── 用户管理服务（User Service）
├── 支付服务（Payment Service）
├── 学习进度服务（Progress Service）
└── 通知服务（Notification Service）
Phase 2: 逐步迁移
├── Step 1: 将课程管理模块提取为独立微服务
├── Step 2: 添加 API Gateway 路由请求
├── Step 3: 逐个迁移其他模块
└── Step 4: 最终下线单体系统
关键考量¶
| 考量点 | 说明 |
|---|---|
| 服务拆分 | 按业务能力（课程、用户、支付等）而非技术层次拆分 |
| 数据库 | 每个微服务拥有独立数据库，逐步从共享数据库中拆分 |
| 通信 | 同步：REST/gRPC；异步：消息队列（如课程购买后发送通知） |
| API Gateway | 统一入口，处理路由、认证、限流 |
| 数据一致性 | 使用 Saga 模式处理跨服务事务 |
参考课件：
slides/Microservices Patterns.pdf
综合参考：
exams/软件系统设计-复习-EagleBear.pdf（综合复习资料）