Deployment Diagram 教學：UML 部署圖繪製完整指南【2025】
你設計的系統架構，別人看得懂嗎？
Deployment Diagram（部署圖）是 UML 標準中專門用來描述系統部署架構的圖形表示法。它清楚展示了硬體、軟體、網路之間的關係，是系統架構師、DevOps 工程師必備的溝通工具。
這篇文章將教你從零開始學會 Deployment Diagram，從基本元素到實際範例，讓你能夠繪製專業的系統部署圖。
什麼是 Deployment Diagram？
Deployment Diagram 是 UML（Unified Modeling Language，統一塑模語言）中的一種結構圖，專門用來描述系統的實體部署架構。
Deployment Diagram 的用途
展示實體架構
Deployment Diagram 回答這些問題：
- 系統運行在哪些硬體上？
- 各個軟體元件部署在哪裡？
- 元件之間如何通訊？
- 使用什麼網路協定？
溝通與文件化
在專案中，Deployment Diagram 用於：
- 向客戶說明系統架構
- 與維運團隊溝通部署需求
- 作為技術文件的一部分
- 規劃容量與成本
規劃與驗證
在設計階段，Deployment Diagram 幫助：
- 確認硬體需求
- 評估網路拓撲
- 識別單點故障
- 規劃擴展策略
Deployment Diagram vs 其他 UML 圖
UML 有多種圖形，各有不同用途：
| 圖形類型 | 關注重點 | 適合回答的問題 |
|---|---|---|
| Class Diagram | 軟體結構 | 類別之間的關係？ |
| Sequence Diagram | 互動流程 | 元件如何互動？ |
| Component Diagram | 元件組織 | 軟體如何組織？ |
| Deployment Diagram | 實體部署 | 軟體部署在哪裡？ |
Deployment Diagram 是唯一關注「實體世界」的 UML 圖，展示硬體與網路的配置。
想了解更多部署基礎知識，請參考我們的 程式部署完整指南。
Deployment Diagram 基本元素
讓我們認識 Deployment Diagram 中的核心元素。
Node（節點）
Node 是 Deployment Diagram 中最基本的元素，代表一個執行環境。
圖形表示：立方體（3D 方塊）
Node 類型
| 類型 | 說明 | 範例 |
|---|---|---|
| Device | 實體硬體 | 伺服器、PC、手機 |
| Execution Environment | 執行環境 | OS、Container、JVM |
| Node | 泛用節點 | 任何執行單元 |
表示方式
┌─────────────────┐
│ <<device>> │
│ Web Server │
│─────────────────│
│ Ubuntu 22.04 │
│ 8 CPU / 32GB │
└─────────────────┘
Node 可以包含其他 Node，表示執行環境的層次關係：
┌─────────────────────────────┐
│ <<device>> │
│ Physical Server │
│ ┌───────────────────────┐ │
│ │ <<executionEnv>> │ │
│ │ Docker Container │ │
│ │ │ │
│ └───────────────────────┘ │
└─────────────────────────────┘
Artifact（製品）
Artifact 代表可部署的軟體單元。
圖形表示：文件圖示（矩形加上折角）
常見 Artifact 類型
| 類型 | 範例 |
|---|---|
| 可執行檔 | app.exe、api-server |
| 程式庫 | libssl.so、node_modules |
| 設定檔 | nginx.conf、.env |
| 資料庫 Schema | schema.sql |
| 容器映像檔 | nginx:latest |
表示方式
┌─────────────────┐
│ <<artifact>> │
│ api-server.jar │
└─────────────────┘
Component（元件）
Component 代表軟體的邏輯單元，通常部署在 Artifact 中。
圖形表示：矩形加上元件符號（兩個小矩形）
┌─────────────────┐
│ ┌─┐ │
│ └─┤ Auth Module │
│ ┌─┐ │
└─────────────────┘
Association（關聯）
Association 代表 Node 之間的通訊關係。
圖形表示：連線
常見標註
| 標註 | 說明 |
|---|---|
| < |
HTTP 通訊 |
| < |
加密 HTTP |
| < |
TCP 連線 |
| < |
資料庫連線 |
| < |
gRPC 通訊 |
┌──────────┐ ┌──────────┐
│ Client │ <<HTTPS>> │ Server │
│ │─────────│ │
└──────────┘ └──────────┘
💡 需要專業的架構設計協助？讓 VibeFix 幫你規劃
Deployment Relationship（部署關係）
表示 Artifact 部署在哪個 Node 上。
圖形表示：虛線箭頭，從 Artifact 指向 Node，標註 <
或者直接將 Artifact 畫在 Node 內部。
繪製 Deployment Diagram 的步驟
讓我們透過一個實際範例，學習如何繪製 Deployment Diagram。
步驟一：確認系統範圍
首先，確認要繪製的系統範圍：
問題清單
- 系統包含哪些主要服務？
- 運行在什麼環境（雲端/地端/混合）？
- 有哪些外部系統需要整合？
- 使用者透過什麼方式存取？
範例情境
我們要繪製一個電商網站的部署圖，包含：
- 前端網站（React）
- 後端 API（Node.js）
- 資料庫（PostgreSQL）
- 快取（Redis）
- 檔案儲存（S3）
步驟二：識別 Node
根據系統需求，識別所有 Node：
硬體/雲端層級
- AWS 雲端環境
- EC2 Instance（Web Server）
- EC2 Instance（API Server）
- RDS Instance（Database）
- ElastiCache（Redis）
- S3 Bucket
軟體執行環境
- Web Server
- Nginx
- Node.js Runtime
- API Server
- Node.js Runtime
- PM2 Process Manager
- Database Server
- PostgreSQL 15
步驟三：識別 Artifact
列出所有需要部署的軟體：
| Node | Artifact |
|---|---|
| Web Server | React Build（靜態檔案） |
| Web Server | nginx.conf |
| API Server | api-server.js |
| API Server | package.json |
| Database | schema.sql |
步驟四：繪製關聯
確認 Node 之間的通訊方式：
Browser → Web Server : HTTPS (443)
Web Server → API Server : HTTP (3000)
API Server → Database : TCP (5432)
API Server → Redis : TCP (6379)
API Server → S3 : HTTPS
步驟五：組合完整圖形
將所有元素組合成完整的 Deployment Diagram。
實際範例：三種常見架構
讓我們看三種不同規模系統的 Deployment Diagram。
範例一：簡單 Web 應用
最基本的三層式架構：
┌─────────────────────────────────────────────────────────────┐
│ <<cloud>> │
│ AWS Cloud │
│ │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ <<device>> │ │ <<device>> │ │ <<device>> │ │
│ │ EC2 Web │ │ EC2 API │ │ RDS │ │
│ │ │ │ │ │ │ │
│ │ ┌─────────┐ │ │ ┌─────────┐ │ │ ┌─────────┐ │ │
│ │ │ Nginx │ │ │ │ Node.js │ │ │ │Postgres │ │ │
│ │ └─────────┘ │ │ └─────────┘ │ │ │ 15 │ │ │
│ │ ┌─────────┐ │ │ ┌─────────┐ │ │ └─────────┘ │ │
│ │ │ React │ │ │ │ API │ │ │ │ │
│ │ │ Build │ │ │ │ Server │ │ │ │ │
│ │ └─────────┘ │ │ └─────────┘ │ │ │ │
│ └──────┬──────┘ └──────┬──────┘ └──────┬──────┘ │
│ │ <<HTTPS>> │ <<TCP/5432>> │ │
│ └────────────────────┴────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────┘
▲
│ <<HTTPS>>
│
┌───┴───────┐
│ Browser │
│ (User) │
└───────────┘
範例二：高可用架構
加入負載平衡與備援的架構：
┌─────────────────────────────────────────────────────────────────────┐
│ <<cloud>> AWS Cloud │
│ │
│ ┌─────────────────┐ │
│ │ <<device>> │ │
│ │ ALB │ │
│ │ (Load Balancer) │ │
│ └────────┬────────┘ │
│ │ │
│ ┌────────────────┼────────────────┐ │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ ┌───────────────┐ ┌───────────────┐ ┌───────────────┐ │
│ │ <<device>> │ │ <<device>> │ │ <<device>> │ │
│ │ EC2 Web-1 │ │ EC2 Web-2 │ │ EC2 Web-3 │ │
│ │ (AZ-a) │ │ (AZ-b) │ │ (AZ-c) │ │
│ └───────┬───────┘ └───────┬───────┘ └───────┬───────┘ │
│ │ │ │ │
│ └─────────────────┼─────────────────┘ │
│ │ │
│ ▼ │
│ ┌────────────────────────┐ │
│ │ <<device>> │ │
│ │ RDS (Multi-AZ) │ │
│ │ ┌────────┐ ┌────────┐ │ │
│ │ │Primary │ │Standby │ │ │
│ │ │ (AZ-a) │ │ (AZ-b) │ │ │
│ │ └────────┘ └────────┘ │ │
│ └────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────┘
範例三：Kubernetes 微服務架構
容器化微服務的部署圖：
┌─────────────────────────────────────────────────────────────────────┐
│ <<cloud>> AWS EKS Cluster │
│ │
│ ┌────────────────────────────────────────────────────────────────┐ │
│ │ <<executionEnv>> │ │
│ │ Kubernetes Namespace: production │ │
│ │ │ │
│ │ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ │
│ │ │ <<pod>> │ │ <<pod>> │ │ <<pod>> │ │ │
│ │ │ api-gateway │ │ user-svc │ │ order-svc │ │ │
│ │ │ │ │ │ │ │ │ │
│ │ │ ┌─────────┐ │ │ ┌─────────┐ │ │ ┌─────────┐ │ │ │
│ │ │ │ Envoy │ │ │ │ Go API │ │ │ │ Node.js │ │ │ │
│ │ │ │ Proxy │ │ │ │ Server │ │ │ │ API │ │ │ │
│ │ │ └─────────┘ │ │ └─────────┘ │ │ └─────────┘ │ │ │
│ │ └──────┬──────┘ └──────┬──────┘ └──────┬──────┘ │ │
│ │ │ │ │ │ │
│ │ │ <<gRPC>> │ <<gRPC>> │ │ │
│ │ └────────────────┴────────────────┘ │ │
│ │ │ │
│ └─────────────────────────────────────────────────────────────────┘ │
│ │
│ ┌─────────────────────┐ ┌─────────────────────┐ │
│ │ <<device>> │ │ <<device>> │ │
│ │ RDS PostgreSQL │ │ ElastiCache Redis │ │
│ └─────────────────────┘ └─────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────┘
Deployment Diagram 繪製工具
選擇適合的工具可以提高繪製效率。
免費工具
Draw.io（diagrams.net）
最推薦的免費工具，特點：
- 完全免費
- 網頁版，無需安裝
- 支援 UML 符號
- 可匯出多種格式
- 支援 Google Drive / GitHub 整合
使用方式：
1. 前往 https://app.diagrams.net
2. 選擇儲存位置
3. 在左側面板選擇「UML」→「Deployment」
4. 拖拉元素到畫布
PlantUML
程式碼生成圖形的工具，適合工程師：
@startuml
node "Web Server" {
artifact "nginx.conf"
artifact "React Build"
}
node "API Server" {
artifact "api-server.js"
}
database "PostgreSQL" {
artifact "schema.sql"
}
[Web Server] --> [API Server] : HTTP
[API Server] --> [PostgreSQL] : JDBC
@enduml
優點：
- 可以版本控制
- 自動排版
- CI/CD 整合（自動生成文件）
缺點：
- 需要學習語法
- 複雜圖形排版較難控制
💡 想把架構圖變成真正的系統？讓 VibeFix 專家幫你實作
付費工具
Lucidchart
適合團隊協作的雲端工具：
- 即時協作
- 豐富的範本庫
- 與 Confluence、Jira 整合
- 價格：約 $7.95/月起
Microsoft Visio
企業常用的專業工具：
- 完整的 UML 支援
- 與 Office 整合
- 企業級功能
- 價格：約 $5/月起（Office 365）
Enterprise Architect
最專業的 UML 工具：
- 完整 UML 2.x 支援
- 程式碼生成
- 需求追蹤
- 價格：約 $229 起（買斷）
工具選擇建議
| 需求 | 推薦工具 |
|---|---|
| 快速繪製、個人使用 | Draw.io |
| 工程師、版本控制 | PlantUML |
| 團隊協作、非技術人員 | Lucidchart |
| 企業、完整 UML | Enterprise Architect |
最佳實踐與常見錯誤
繪製 Deployment Diagram 時，遵循這些原則可以提高圖的品質。
最佳實踐
保持適當抽象層次
不要把所有細節都放進一張圖，根據目的選擇抽象層次：
| 目的 | 抽象層次 | 包含內容 |
|---|---|---|
| 向客戶說明 | 高 | 主要服務、網路區域 |
| 與維運溝通 | 中 | 伺服器、服務、連接埠 |
| 除錯排查 | 低 | 詳細設定、版本 |
使用一致的符號
整個專案使用一致的符號系統：
- 統一 Stereotype（<
- 統一顏色編碼（例如：資料庫用藍色、應用程式用綠色）
- 統一命名規則
標註重要資訊
在圖上標註關鍵資訊：
- 通訊協定與連接埠
- 執行環境版本
- 資源規格（CPU、RAM）
- 可用區域（AZ）
維持圖的可讀性
- 避免線條交叉
- 相關元素放在一起
- 使用適當的間距
- 加入圖例說明
常見錯誤
錯誤一：混淆邏輯與實體架構
❌ 錯誤：把 Class 或 Interface 畫在 Deployment Diagram
✅ 正確：只包含實體元素（Node、Artifact）
錯誤二：過度簡化或過度複雜
❌ 過度簡化：只畫「Frontend」→「Backend」→「Database」
✅ 適當：包含執行環境、通訊方式、關鍵設定
❌ 過度複雜：包含每個設定檔、每個環境變數
✅ 適當：只包含架構上重要的元素
錯誤三：忽略網路邊界
❌ 錯誤：沒有標示哪些在公網、哪些在私網
✅ 正確：使用邊界框標示網路區域（VPC、Subnet）
錯誤四：圖與實際不符
❌ 錯誤：畫完就不更新，與實際系統脫節
✅ 正確：將圖納入版本控制，隨系統更新
從 Deployment Diagram 到實際部署
Deployment Diagram 畫好了，如何轉換成實際的系統？
轉換成 Infrastructure as Code
將 Deployment Diagram 的資訊轉換成 IaC 程式碼：
Terraform 範例
# 對應 Deployment Diagram 中的 Node
resource "aws_instance" "web_server" {
ami = "ami-xxx"
instance_type = "t3.medium" # 圖中標註的規格
tags = {
Name = "Web Server" # 圖中的 Node 名稱
}
}
resource "aws_instance" "api_server" {
ami = "ami-xxx"
instance_type = "t3.large"
tags = {
Name = "API Server"
}
}
resource "aws_db_instance" "database" {
engine = "postgres"
engine_version = "15" # 圖中標註的版本
instance_class = "db.t3.medium"
identifier = "production-db"
}
轉換成 Kubernetes Manifest
對於容器化架構：
# 對應 Deployment Diagram 中的 Pod
apiVersion: apps/v1
kind: Deployment
metadata:
name: api-gateway # 圖中的 Pod 名稱
spec:
replicas: 3
selector:
matchLabels:
app: api-gateway
template:
spec:
containers:
- name: envoy # 圖中的 Container
image: envoyproxy/envoy:v1.28
ports:
- containerPort: 8080
驗證部署
部署完成後，驗證實際架構是否符合 Deployment Diagram：
# 確認 Node（EC2 實例）
aws ec2 describe-instances --query 'Reservations[].Instances[].[Tags[?Key==`Name`].Value,State.Name]'
# 確認網路連通性
nc -zv api-server 3000
nc -zv database 5432
# 確認服務狀態
kubectl get pods -n production
VibeFix 架構設計服務
Deployment Diagram 只是架構設計的開始，真正的挑戰在於：
- 如何選擇最適合的架構？
- 如何確保高可用性？
- 如何控制成本？
- 如何實現架構圖中的設計？
VibeFix 團隊提供完整的架構設計與實作服務。
服務範圍：
- 系統架構評估與建議
- Deployment Diagram 繪製
- Infrastructure as Code 實作
- CI/CD Pipeline 設計
- 架構優化與成本控制
想了解更詳細的服務？查看 VibeFix 服務內容。
結語：用圖說話，讓架構清晰可見
Deployment Diagram 是系統架構師的重要工具，它幫助你：
- 清楚展示系統的實體架構
- 與團隊有效溝通部署需求
- 規劃與驗證系統設計
- 建立專業的技術文件
透過這篇教學，你已經學會：
- Deployment Diagram 的基本元素（Node、Artifact、Component）
- 繪製步驟與實際範例
- 各種繪製工具的選擇
- 最佳實踐與常見錯誤
- 從圖到實際部署的轉換
接下來，你可以學習 CI/CD 建置與部署流程，了解如何自動化你的部署流程。或者參考 部署伺服器架設指南，建立集中化的部署管理系統。
還是搞不定？讓 VibeFix 幫你
系統架構設計需要經驗與專業知識。如果你需要專業的架構設計協助，VibeFix 團隊可以幫你從規劃到實作。