部署图（Deployment Diagram）是UML中唯一面向物理架构的图，回答一个核心问题：软件部署在什么硬件上，它们之间如何通信。本文从核心概念到绘制方法，完整拆解部署图的每一步。
一、什么是部署图
部署图描述系统运行时的物理架构——哪些软件组件部署在哪些硬件节点上，节点之间通过什么方式通信。
它和组件图的区别在于：组件图画的是逻辑层面"模块怎么组合"，部署图画的是物理层面"软件放在哪台机器上"。一个管设计，一个管落地。
典型使用场景：
- 系统上线前确认部署方案
- 运维团队理解系统拓扑结构
- 新人入职快速掌握系统全貌
- 故障排查时定位节点间的通信链路
二、六大核心要素
| 要素 | 符号 | 含义 | 示例 |
|---|---|---|---|
| 节点（Node） | 三维方框 | 物理或虚拟的计算资源 | 应用服务器、数据库服务器 |
| 制品（Artifact） | 圆柱形或矩形+«artifact» | 可部署的软件单元 | user-service.jar、web-app.war |
| 组件（Component） | 矩形+«component» | 功能单元 | 用户服务组件、支付组件 |
| 通信路径 | 实线 | 节点间的物理或逻辑连接 | 网络连接、API调用 |
| 依赖关系 | 虚线箭头 | 一个元素依赖另一个才能运行 | 应用依赖数据库 |
| 部署规范 | 矩形附在路径上 | 部署的配置参数 | 协议=HTTPS, 端口=443 |
节点的两种类型
设备（Device）： 有形的物理硬件。
- 标记：«device»
- 示例：物理服务器、手机、IoT传感器、负载均衡器
执行环境（Execution Environment）： 软件容器，为制品提供运行环境。
- 标记：«executionEnvironment»
- 示例：JVM、Docker容器、Node.js运行时、应用服务器
两者可以嵌套：一个«device»里面可以包含多个«executionEnvironment»，每个执行环境里再部署具体的制品。
三、节点间通信关系
通信路径（Association）
用实线连接两个节点，表示它们之间存在物理或逻辑上的通信链路。
可以在路径上标注协议类型：
[Web Server] ——HTTP/HTTPS—— [Application Server]
[App Server] ——TCP/IP—— [Database Server]
[Mobile App] ——REST API—— [API Gateway]
依赖关系（Dependency）
用虚线箭头表示一个节点或组件依赖另一个才能正常工作。
[Order Service] - - -> [Payment Service]
（订单服务依赖支付服务的接口）
关联与部署
制品放在节点内部，表示"部署在"该节点上。如果需要明确部署方式，用«deploy»标注。
四、五步绘制法
第一步：确定系统范围
画部署图最忌讳的是"什么都画"。先回答三个问题：
- 这张图给谁看？（运维 / 架构评审 / 新人）
- 覆盖哪些子系统？（全量 / 某个微服务集群）
- 粒度到什么程度？（服务器级别 / 容器级别 / 进程级别）
给运维看，粒度到容器和端口；给新人看，粒度到服务器和服务名即可。
第二步：列出所有节点
按从外到内的顺序梳理：
示例（电商系统）：
- 用户设备：浏览器、App
- CDN节点
- 负载均衡器
- Web服务器（Nginx）
- 应用服务器（Spring Boot × 3）
- 数据库服务器（MySQL主从）
- 缓存服务器（Redis）
- 消息队列（RabbitMQ）
- 文件存储（OSS）
第三步：确定节点层级与嵌套
物理设备包含执行环境，执行环境包含制品：
«device» 应用服务器
└── «executionEnvironment» JVM
└── «artifact» user-service.jar
└── «artifact» order-service.jar
如果用容器化部署，结构调整为：
«device» 物理服务器
└── «executionEnvironment» Docker
└── «artifact» user-service容器
└── «artifact» order-service容器
└── «artifact» nginx容器
第四步：连接通信路径
用实线连接有通信关系的节点，并标注协议：
- 浏览器 → CDN：HTTPS
- CDN → Nginx：HTTP
- Nginx → 应用服务：HTTP（内网）
- 应用服务 → MySQL：JDBC
- 应用服务 → Redis：Redis Protocol
用虚线箭头标注依赖关系：
- 订单服务 - - -> 支付服务
- 用户服务 - - -> 缓存服务
第五步：审查与精简
部署图完成后，逐项检查：
- 每个节点的构造型标注是否清晰（«device» / «executionEnvironment»）
- 通信路径上的协议是否标注
- 制品是否正确放在所属节点内
- 是否存在孤立节点（没有连接任何路径）
- 图的复杂度是否匹配目标读者
精简原则： 如果一张图超过15个节点，考虑拆分为多张子图。先画总览图，再分模块画详细图。
五、五个常见错误
错误1：把部署图画成了架构图
部署图的核心是"物理部署"，不是"逻辑设计"。如果图里全是组件间的调用关系，没有节点和硬件，那画的是组件图不是部署图。
判断标准： 图里有没有三维方框（节点）？没有就不是部署图。
错误2：节点层级混乱
设备、执行环境和制品的嵌套关系必须清晰。常见错误是把制品直接放在设备上，跳过了执行环境层。
正确做法： 设备 → 执行环境 → 制品，三层嵌套。
错误3：通信路径不标协议
画一条实线连接两个节点，但不标注协议类型。运维拿到图后不知道端口怎么开、防火墙怎么配。
规范： 每条通信路径至少标注协议（HTTP/HTTPS/TCP/JDBC等），有条件的话加上端口号。
错误4：粒度不一致
有些节点画到服务器级别，有些画到容器级别，有些画到进程级别。读者不知道该按哪个粒度理解。
规范： 一张图保持统一粒度。如果需要多粒度，用多张图分层展示。
错误5：忽略网络分区
生产环境通常分DMZ区、内网区、数据库区，不同区域之间的网络策略不同。部署图不体现网络分区，运维就无法判断哪些连接需要经过防火墙。
规范： 用分组框或不同颜色区分网络区域，标注跨区域连接的防火墙策略。
六、部署图与其他UML图的配合
部署图很少孤立使用，通常与其他UML图组合形成完整的系统文档：
| 配合图 | 作用 | 组合效果 |
|---|---|---|
| 组件图 | 描述逻辑组件 | 从设计到部署的完整链路 |
| 时序图 | 描述跨节点调用流程 | 理解节点间如何协作 |
| 用例图 | 描述用户场景 | 确认每个用例由哪些节点支撑 |
| 活动图 | 描述业务流程 | 定位流程涉及哪些部署节点 |
推荐组合： 部署图 + 时序图。部署图回答"部署在哪"，时序图回答"怎么调用"，两张图组合就是完整的运行时文档。
七、工具选择
| 工具 | 定位 | 部署图支持 | 适合谁 |
|---|---|---|---|
| singcheng.com | 一站式在线画图 | 支持UML节点、组件、制品符号，模板库可复用 | 团队协作、快速出图 |
| Draw.io | 免费在线画图 | 内置UML部署图模板，符号齐全 | 个人快速绘制 |
| Lucidchart | 在线协作画图 | UML形状库完整，支持实时协作 | 团队协作 |
| PlantUML | 代码生成图表 | 用文本描述生成部署图，版本可控 | 偏好代码的开发者 |
| StarUML | 桌面建模工具 | 支持完整UML 2.5规范 | 专业建模 |
如果需要快速画一张部署图用于评审或文档，singcheng.com 提供了现成的UML部署图模板，拖拽即可完成，省去从零搭建符号库的时间。更多画图教程和模板，尽在 singcheng.com。
八、自检清单
绘制完成后，逐项核对：
- 图的标题是否明确（系统名称 + "部署图" + 版本号）
- 每个节点是否标注构造型（«device» / «executionEnvironment»）
- 设备和执行环境的嵌套关系是否正确
- 每个制品是否标注了«artifact»构造型
- 通信路径是否标注协议和端口
- 依赖关系是否用虚线箭头
- 粒度是否统一（全服务器级 / 全容器级 / 全进程级）
- 网络分区是否体现
- [] 图中节点数量是否在可读范围（建议≤15个/张）
- 是否有图例说明符号含义
总结
部署图是UML中唯一聚焦"物理部署"的图。它回答的不是"系统怎么设计"，而是"系统怎么落地"。
掌握部署图的核心在于三点：理清节点层级（设备→执行环境→制品）、标注通信协议、保持统一粒度。画好一张部署图，运维团队拿到手就知道每台机器跑什么、端口怎么开、防火墙怎么配。
对于需要画部署图的团队，建议在 singcheng.com 上使用UML模板快速绘制，支持在线协作和模板复用，更多画图教程尽在 singcheng.com。