二、核心内容详解
1. 4+1架构视图
- 定义
（1995年提出）：
从五个视角描述系统架构，覆盖不同角色需求： - 逻辑视图
：功能模块（类似UML类图/状态图），展示系统提供的核心能力。 - 处理视图
：动态流程（如活动图/序列图），描述系统如何处理请求。 - 开发视图
：程序员视角的代码组织（包图），关注模块划分和依赖。 - 物理视图
：硬件部署（部署图），展示服务器、网络、存储等物理资源。 - 场景视图
（用例图）：用户视角的需求实现，模拟典型操作场景。 - 现状与问题
：
国内企业较少使用，原因包括： - 系统复杂度高
：分布式架构难以用传统单体视图表达。 - UML局限性
：图形复杂、美观性差，与实际开发脱节。 - 视图混淆
：逻辑、开发、处理视图易重叠，导致理解成本高。
2. 大厂常见架构图类型及实践
- 业务架构
： - 定义
：聚焦业务功能模块（如电商的“商品管理”“订单支付”）。 - 场景
：产品规划、高管汇报、新员工培训。 - 技巧
：用颜色区分业务状态（如灰底表示未上线），分组管理功能模块。 - 客户端/前端架构
： - 定义
：领域逻辑分层（如MVC、MVVM），展示组件交互。 - 场景
：整体架构设计、技术评审。 - 技巧
：颜色标识角色（如蓝色为UI层，绿色为业务逻辑），连线表示依赖。 - 系统架构
（后端）： - 简单场景
：单张图展示核心模块（如“用户服务”“支付服务”）。 - 复杂场景
：拆分为功能示意图（模块功能）和交互示意图（服务间调用流程）。 - 命名争议
：因后端复杂性，“系统架构”常被直接称为“技术架构”。 - 应用架构
： - 定义
：描述系统由哪些独立应用组成（如微服务架构中的“用户中心”“订单中心”）。 - 场景
：开发、测试、部署、子域划分。 - 案例
：HBase应用架构图展示Master-Slave节点分工。 - 部署架构
： - 定义
：物理资源布局（如Kubernetes集群、数据库分片）。 - 场景
：运维监控、成本优化。 - 技巧
：用图标替代文字（如⚙️代表服务、📡代表网络），避免信息过载。
3. 系统序列图（System Sequence Diagram, SSD）
- 作用
：动态展示系统组件间的交互顺序（如用户发起请求→API网关→服务A→数据库）。 - 对比静态架构图
：
静态图（如类图）描述“结构”，序列图描述“行为”。 - 绘制要点
：
明确参与者（如用户、服务、数据库），按时间顺序排列消息，标注同步/异步调用。
4. 架构图绘制的核心原则
- 角色适配
：根据受众选择视图（如给高P用业务架构，给开发用系统架构）。 - 简洁直观
：避免过度细节，用颜色/图标辅助理解。 - 分层表达
：复杂系统需分层拆解（如业务架构→系统架构→部署架构）。
三、关键问题解析
- 为什么不用4+1视图？
分布式系统复杂性超出其设计初衷，UML工具颜值低，视图边界模糊。 - 能否用一种图表达所有架构？
不能。不同视图聚焦不同目标（如业务功能 vs. 物理部署），单一图会导致信息混乱。 - 应用架构 vs. 系统架构？
-
应用架构：关注系统由哪些应用组成（横向拆分）。 -
系统架构：关注单个应用的逻辑设计（纵向分层）。 -
联系：应用架构是系统架构的上层抽象。
四、随堂测验参考答案（思路）
- 判断题
： -
✖️ 4+1视图是规范，但非强制（国内企业多采用简化视图）。 -
✔️ UML可画架构图，但存在局限性。 -
✔️ 应用架构可能是系统架构的一部分（如微服务中每个服务既是应用也是系统）。 -
✖️ 高管汇报推荐业务架构而非技术细节的系统架构。 - 思考题
： -
不同架构图的目标不同（如业务图侧重需求，部署图侧重资源），单一图无法平衡抽象层级和细节。
五、总结
优秀架构图需结合业务目标、技术选型及团队习惯，灵活选择视图类型，优先保证清晰表达而非形式合规。大厂实践中，业务架构、系统架构、部署架构是核心，序列图用于关键交互场景。避免被UML规则束缚，注重可视化效果与沟通效率。
