Day01-02｜1.1.2 软件架构的常用分类及建模方法

教材版本：系统架构设计师教程（第 2 版）
教材章节：第 1 章 绪论 · 1.1.2
考试科目：综合知识、案例分析
建议用时：120～150 分钟

一、学习目标

本节不是让你机械记住各种架构名词，而是要掌握“从不同角度观察系统”的方法。学完后，你应该能够解释软件架构为什么需要多个视图，区分逻辑架构、开发架构、运行架构和部署架构，理解模型、视图、视角和场景之间的关系，并能够根据案例题选择合适的图来表达系统。

二、为什么一张图无法说明架构

一个大型系统同时面对业务人员、产品经理、开发人员、测试人员、运维人员、安全人员和管理者。业务人员关心系统是否覆盖流程，开发人员关心代码模块和依赖，测试人员关心接口和可验证场景，运维人员关心进程、节点、网络和故障转移，安全人员关心信任边界、身份和数据流。如果只画一张“系统由 A、B、C 三个模块组成”的图，不同人员仍然无法获得自己需要的信息。

因此，架构建模通常采用多个视图。视图是从特定关注点对系统架构的表达；视角规定如何构造和解释某类视图；模型是对系统某些方面的抽象；场景则把用户目标、系统行为和架构元素联系起来。架构文档不是图越多越好，而是要让每张图服务于一个明确问题。

三、常见架构分类

1. 按系统层次分类

可以从业务架构、应用架构、数据架构、技术架构和部署架构观察系统。业务架构描述组织目标、业务能力、流程和角色；应用架构描述应用系统和模块职责；数据架构描述数据实体、数据流、存储和治理；技术架构描述运行平台、中间件、通信和基础设施；部署架构描述软件如何映射到服务器、容器、网络区域和设备。

这些分类不是彼此独立的。业务流程会决定应用边界，应用边界会影响数据所有权，数据访问会影响技术选型，技术选型最终要映射到部署节点。案例题如果问“架构设计是否完整”，可以从这五个层次进行检查。

2. 按静态与动态分类

静态架构描述系统有哪些组成部分、它们之间有什么关系，例如类图、组件图、模块依赖图和部署节点图。动态架构描述系统运行时如何变化，例如时序图、活动图、状态图、消息流和故障转移流程。

静态图可以回答“订单服务和库存服务是否分离”，但不能回答“库存服务超时后订单状态如何变化”；时序图可以回答调用顺序和异常分支，但不能完整表达所有模块的部署位置。因此，架构设计至少要同时考虑结构和行为。

3. 按抽象层次分类

概念架构强调系统边界、主要能力和核心概念，适合早期沟通；逻辑架构强调组件职责、接口和依赖，适合设计评审；物理架构强调服务器、网络、存储和部署，适合实施和运维；实现架构进一步落实到代码包、框架和配置。抽象层次越低，细节越多，但越容易受具体实现影响。

高级考试中，题目常要求“给出系统架构设计方案”。此时不要一开始陷入类名和字段，而应先给出边界、组件、连接方式、数据流和部署关系，再补充关键技术实现。

四、4+1 视图模型

4+1 视图模型用逻辑视图、开发视图、进程视图、物理视图和场景视图描述软件架构。不同教材和工程实践中名称可能略有差异，但核心思想一致：通过多个互补视图覆盖系统的结构、开发、运行、部署和需求场景。

1. 逻辑视图

逻辑视图面向最终用户和功能需求，关注系统提供哪些职责以及这些职责如何组织。它可以使用类、对象、组件或领域模块表示。订单、库存、支付和会员等领域能力如何划分，属于逻辑视图关注的问题。

2. 开发视图

开发视图面向开发和构建，关注源代码目录、模块、组件、依赖、复用库、构建单元和团队边界。一个逻辑组件可能对应多个代码模块，也可能多个逻辑职责暂时位于一个工程中。开发视图有助于控制编译依赖、版本管理和团队协作。

3. 进程视图

进程视图面向运行时，关注进程、线程、并发、通信、同步、负载和故障。高并发下是否采用线程池，订单服务是否无状态，消息消费者如何扩展，某个进程崩溃后是否影响其他进程，都属于进程视图问题。

4. 物理视图

物理视图描述软件如何部署到硬件、虚拟机、容器、可用区、网络区域和外部设备。它要表达负载均衡、主备、集群、分区、容灾和安全边界。部署图不能只写“部署到云上”，要说明节点角色、流量路径、数据复制和故障切换。

5. 场景视图

场景视图使用关键用例验证其他视图是否能够协同工作。例如“用户下单”场景应穿过网关、订单服务、库存服务、支付服务、数据库和消息系统，并说明成功、超时、重复和回滚路径。场景视图是连接需求与架构的桥梁，也是案例题验证方案完整性的好方法。

五、UML 与架构建模

UML 是统一建模语言，不是某一种架构。类图适合表达类、属性、操作和关系；组件图适合表达组件及其接口；部署图适合表达节点和部署关系；时序图适合表达对象交互顺序；活动图适合表达流程；状态图适合表达对象状态变化；用例图适合表达角色和系统功能边界。

选图要从问题出发：如果要说明模块边界，使用组件图；如果要说明服务如何调用，使用时序图；如果要说明订单状态如何从待支付变成已支付或已关闭，使用状态图；如果要说明服务部署和故障转移，使用部署图。不要为了“画 UML”而画图，图必须能够支撑某个架构判断。

六、架构建模的抽象原则

第一是关注点分离，把业务职责、运行机制、安全边界和部署细节分开表达；第二是保持一致性，同一个组件在不同视图中名称、职责和边界不能互相矛盾；第三是可追踪，关键需求能够追踪到架构决策和验证场景；第四是适度详细，图要让读者看懂并能用于决策，而不是把所有代码细节都塞进架构图。

架构模型还应记录假设和未决问题。例如假设第三方支付支持幂等接口，未决问题是其回调是否保证顺序。假设没有被记录，后续团队可能把它误当成事实；未决问题没有负责人和截止时间，风险就可能一直隐藏。

七、从需求建立架构模型

可以采用以下步骤：

1. 识别干系人和关注点；
2. 列出业务目标、功能需求、质量属性和约束；
3. 划分系统边界和核心职责；
4. 选择适合的架构视图和建模语言；
5. 建立组件、连接件、数据和部署关系；
6. 使用关键场景验证正常和异常行为；
7. 记录架构决策、权衡、假设和风险；
8. 通过评审、原型和测试持续修订模型。

其中最容易被忽略的是第 6 步。很多架构图只画成功路径，案例题却会考超时、重复、断网、节点故障、数据不一致和权限错误。一个真正可用的架构模型必须能够表达失败路径。

八、案例分析

某在线教育平台包括课程、直播、作业、支付和数据分析功能。课程和作业由一个团队负责，支付由外部平台提供，直播需要低延迟，数据分析允许延迟十分钟。请说明应使用哪些架构视图描述系统，并说明每种视图的重点。

参考答案

逻辑视图描述课程、直播、作业、支付和分析等核心职责及其边界；开发视图描述课程团队、直播团队和平台团队的代码模块、接口和共享库，避免团队之间形成隐式依赖；进程视图描述直播连接、消息处理、作业提交和支付回调的并发关系，并说明超时、重试和限流；物理视图描述直播节点、应用节点、数据库、缓存、消息系统和分析平台的部署及网络分区；场景视图重点验证用户观看直播、提交作业、支付成功、支付超时和数据延迟等关键流程。

直播低延迟场景可能需要独立的连接和分发能力，不能简单套用普通同步接口；支付回调必须验签和幂等；分析数据通过消息或数据同步进入分析平台，不能让复杂报表直接压垮在线交易库。答案中的关键不是图的数量，而是每张图都围绕一个明确问题，并且不同视图之间保持一致。

九、综合知识练习

1. 为什么大型系统需要多个架构视图？
2. 逻辑视图和物理视图分别关注什么？
3. 时序图和部署图解决的问题有什么不同？
4. 4+1 视图中的“+1”通常指什么？
5. 架构模型为什么要记录假设和未决问题？

参考答案

1. 不同干系人关注结构、代码、运行、部署和业务场景的不同方面，单一视图无法完整表达。2. 逻辑视图关注职责和功能组织，物理视图关注软件到节点、网络和基础设施的映射。3. 时序图关注运行时交互顺序，部署图关注节点、网络和部署关系。4. 场景视图，用关键用例验证其他视图。5. 假设决定方案成立的前提，未决问题代表尚未确认的风险，记录后才能跟踪和验证。

十、论文素材

本节适合积累“基于多视图的复杂系统架构设计”主题。论文可以写项目干系人众多、系统复杂、团队协作困难，因此采用逻辑、开发、进程、物理和场景多视图方法；通过统一命名、架构评审和需求追踪保持模型一致；使用关键场景验证高并发、故障转移、支付回调和数据同步；最终用问题定位时间、变更影响范围、交付周期和故障恢复时间说明架构治理效果。

论文不要只列出 UML 图名称，要说明每类视图解决了什么沟通和设计问题，以及如何通过视图发现风险。

十一、今日复盘

请闭卷回答：为什么架构不是一张图？4+1 视图分别解决什么问题？一个“用户下单”场景应该如何穿过逻辑、进程和物理视图？如果三个视图中的组件名称不一致，会造成什么后果？

完成标准：能够根据一个系统场景主动选择视图，能同时说明正常路径和异常路径，并能把需求、架构图、技术决策和验证指标串起来。